QtD 0.1

А D может дефайны СИ использовать?

Как таковые нельзя, но там есть очень похожие заменители static_if, и для аналогичных дефайнам целей, но типизированные template mixin и ленивые аргументы функций.

Имхо, типичные дефайны из С в Д можно транслировать без проблем. Правда не помню как там с ({ }), спроси у naryl.

В смысле, потенциально можно транслировать программно без проблем, или сейчас -- руками. Про автоматическую трансляцию не знаю.

> обязательные условия: 1) возможность написания драйверов, работающих с железом

За драйвера на плюсах надо отрывать лапы. Для драйверов есть С.

> Так вот, недавно тут был тред, в котором на много страниц писали, что плюсы гавно. Меня это коробило

Это потому что кроме плюсов ты нихера не знаешь? так? в институте только плюсы начали проходить. Так вот все что ты понаписал может понаписать любой делфист, который нихера кроме делфи не знает. и библиотеки и (о дада, и такое далеют) драйвера на делфи пишут.

для каждой задачи есть свои инструменты. У нас сидел штат плюсистов 2 года писали серверную задачу и что? а то что пришел один ерлангист и переписал годичную работу целого штата сотрудников за месяц. А потом еще часть переписали на окамле. Все. Работает, расширяется, легко поддерживается. То есть пока плюсисты роятся в коде друг друга с кучей шаблонов другие люди просто решают задачи. И решают хорошо правильно и быстро. так что, плюсы вещь хорошая когда-то была, но увы устарела и должна отправиться на покой.

>> Так вот, недавно тут был тред, в котором на много страниц писали, что плюсы гавно. Меня это коробило

>для каждой задачи есть свои инструменты.

D это вроде как прямая замена С++ с целью разобраться с его "design flaws". Тут и быстрая+читаемая метапрограммилка, и сложные примитивы типа строк, и делегаты, и gc. Так что насчет "каждой задаче - свои инструменты" не в этот тред.

>У нас сидел штат плюсистов 2 года писали серверную задачу и что? а то что пришел один ерлангист и переписал годичную работу целого штата сотрудников за месяц.

Угу круто, а можно по подробнее? Что за серверная задача и сколько было в штате плюсистов?

> Кстати, я "ушёл" с Си++ раньше, чем появились массовые решения с STL

Я, в общем, тоже, хотя сам STL пользовался. ИМХО, STL - это худшее, что случилось с Си++. Потом пришли фокусники Boost и Александреску, и поговорка "благими намерениями вымощена дорога в ад" получила еще одно блестящее подтверждение. И судя по тому, как развивается D, меня терзают смутные сомнения по поводу его будущего. Слишком мало математики в фундаменте, слишком велик простор для самовыражения.

Эх, кто бы взялся допиливать Cyclone...

> У нас сидел штат плюсистов 2 года писали серверную задачу и что? а то что пришел один ерлангист и переписал годичную работу целого штата сотрудников за месяц. А потом еще часть переписали на окамле.

При том, что Эрланг и Окамл языки более высокого уровня, _переписывать_ всегда проще.

>> Так вот, недавно тут был тред, в котором на много страниц писали, что плюсы гавно. Меня это коробило

> Это потому что кроме плюсов ты нихера не знаешь? так? в институте только плюсы начали проходить. Так вот все что ты понаписал может понаписать любой делфист, который нихера кроме делфи не знает. и библиотеки и (о дада, и такое далеют) драйвера на делфи пишут.

> для каждой задачи есть свои инструменты. У нас сидел штат плюсистов 2 года писали серверную задачу и что? а то что пришел один ерлангист и переписал годичную работу целого штата сотрудников за месяц. А потом еще часть переписали на окамле. Все. Работает, расширяется, легко поддерживается. То есть пока плюсисты роятся в коде друг друга с кучей шаблонов другие люди просто решают задачи. И решают хорошо правильно и быстро. так что, плюсы вещь хорошая когда-то была, но увы устарела и должна отправиться на покой.

так значит это ВЫ сделали ejabberd ??? O__o

> Я, в общем, тоже, хотя сам STL пользовался. ИМХО, STL - это худшее, что случилось с Си++

какое странное мнение. По моему, обобщенные алгоритмы и набор удобных контейнеров - это отличная идея.

// сам программирую не столько на ++, сколько именно на STL (: ну и в планах постепенная эволюция до boost.

>ИМХО, STL - это худшее, что случилось с Си++.

А что, надо было продолжать славную традицию копипаста тех же самых долбаных template<class T> class YetAnotherStupidDynamicArray {T* _arr; /* ...same cruft again and again.. */}; в каждом фреймворке?

>> ИМХО, STL - это худшее, что случилось с Си++.

> А что, надо было продолжать славную традицию копипаста тех же самых долбаных template<class T> class YetAnotherStupidDynamicArray {T* _arr; /* ...same cruft again and again.. */}; в каждом фреймворке?

Я не знаю такой традиции. Нужна была стандартная библиотека контейнеров и стандартный строковый класс. Но Степанов был слишком хорош для таких простых вещей.

>>> ИМХО, STL - это худшее, что случилось с Си++.

>> А что, надо было продолжать славную традицию копипаста тех же самых долбаных template<class T> class YetAnotherStupidDynamicArray {T* _arr; /* ...same cruft again and again.. */}; в каждом фреймворке?

>Я не знаю такой традиции. Нужна была стандартная библиотека контейнеров и стандартный строковый класс. Но Степанов был слишком хорош для таких простых вещей.

а ещё помню традицию (Qt и MFC в подтверждение) -- каждому нада созданить своего строкогого класса...

>>> ИМХО, STL - это худшее, что случилось с Си++.

>> А что, надо было продолжать славную традицию копипаста тех же самых долбаных template<class T> class YetAnotherStupidDynamicArray {T* _arr; /* ...same cruft again and again.. */}; в каждом фреймворке?

>Я не знаю такой традиции. Нужна была стандартная библиотека контейнеров и стандартный строковый класс.

Ну в теории что_я_хочу_сделать_с_секвенцией(срез_секвенции, параметры_возможно_функциональные) читаемей for(int i=0; i<arr.size; i++) { ...какое-то дрочерство...}. Это как если sql заменить циклами по таблицам.

>Есть такое. Однако возникает другой вопрос. За сколько времени ты сможешь набрать команду из 20 разработчиков способных понимать C++ как его понимает Александреску? Упростим задачу. Хотя бы таких же как ты сам?

эхе... давайте перефразируем: за сколько времени можно набрать команду профессиональных разработчиков на <подставьте_любой_язык> в количестве 20 человек, имеющих глубокое понимание данного языка и солидный опыт написания приложений на нём, умеющих работать в команде и знающие соответствующие средства разработки.

Вообще это зависит.... от бюджета, от компании, от экономической ситуации в стране и т.д. Сейчас, к примеру, с учётом того что многие компанию поджимают персонал да и кризис вокруг - это сделать попроще.

Не думаю, что действительно опытных разрабов, к примеру, на Java, C# или Python найти серьёзно легче. :)

>Уровень вхождения в C# растет с каждым новым релизом языка. Хотя как показывает опыт набирания кандидатов даже C# 1.0 осиливает один из 50.

Вот-вот... только если в C# они хотя бы могут не лажать с распределением памяти (хотя и на C# можно легко организовать утечку памяти :)), то в С++ всё куда печальнее...

>>А Вы бы как ответили на этот вопрос???

>На какой конкретно? Ветка там была длинная...

Вот на этот:

"- Да, сложно на нём писать код без ошибок.

- Ну так зачем тогда мучиться? :) "

>А, вообще, вопрос в том, что трактора несравнимо более востребованы, чем болиды F1. И пользы куда как больше приносят :)

Не нравятся гоночные машины - давай рассмотрим самолёты... Они тоже весьма востребованы и пользы приносят даже побольше тракторов... :)

> Не нравятся гоночные машины - давай рассмотрим самолёты... Они тоже весьма востребованы и пользы приносят даже побольше тракторов... :)

При помощи самолетов можно пахать землю? строить дома? перевозить кирпичи от завода за углом до стройки? ну начали уж метафорами говорить дтак давайте дальше это бредовое сравнение. Так вот писать ВСЕ на плюсах это такой же бред как и пахание земли самолетами.

> При помощи самолетов можно пахать землю? строить дома? перевозить кирпичи от завода за углом до стройки? ну начали уж метафорами говорить дтак давайте дальше это бредовое сравнение. Так вот писать ВСЕ на плюсах это такой же бред как и пахание земли самолетами.

Да ладно с метафорами. Сейчас реально НУЖНА замена плюсам. Я рад, что развивается D, но чую развиваться он будет очень долго. Почему? А потому что его MS не двигает. У MS нет поддержки этого языка. Вот как пример: за сколько развился .net? Он младше D не так ли? А потом mono. вот на моно уже пишут, потому что мс устами мигеля и крупными капиталовливаниями сказало что это круто и это прогесс.

или вот еще один пример: Ocaml. О нем мало кто слышал, пока MS не толкнула идею всраиванися F# в студию. Сейчас зато книг по F# больше чем по окамл (у последнего даже форума толкового нет, кроме яху рассылок :( ) и уже встречал куча раз "Ocaml - убогий клон F#". бабло решает все ...

> Не должно быть такой ситуации в языке. Вот и все.

Да-да-да, а мужики-то не знают, только укуренные перфекционисты, как всегда, всё знают лучше всех. 8))))))))))))))))))))))))))))))))

>При помощи самолетов можно пахать землю?

Можно, но только один раз и на неболшом участке.

>строить дома?

Можно сносить :)

пощупал я D, в целом неплохо, есть плюсы и минусы, но дополнительная алтернатива не помешает

вот только возник вопрос:

class A {

...

private void f() { }

}

и при таком объявлении в main удаётся вызвать A a; a.f(); я что-то не дочитал в спеках или "так надо"?

A a = new A(); конечно же

> А D может дефайны СИ использовать?

Нет. Препроцессора в D нет. Как всё, что делалось препроцессором реализовывать на D описано здесь: http://www.digitalmars.com/d/2.0/pretod.html и здесь: http://www.digitalmars.com/d/2.0/cppdbc.html

> я что-то не дочитал в спеках или "так надо"?

И то и то. :) private означает "можно вызвать только из данного модуля", а не "... класса".

то есть здесь схема, как в Аде? собственно, как и с inout

Ключевое слово inout переименовано в ref. :)
in означает, что ты не будешь менять аргумент функции и выводить его из функции.
out - что аргумент при вызове функции считается неинициализированным и передаётся по ссылке.
ref - аргумент передаётся по ссылке.

(Про ada знаю только название)

ясно, в точности как в аде, спасибо за подсказки

PS: Ada - неудачная попытка сделать универсальный язык (83 год), язык сложнее даже С++

Странно, почему каждая тема про D сваливается во флейм о плюсах

>Нет. Препроцессора в D нет. Как всё, что делалось препроцессором реализовывать на D описано здесь: http://www.digitalmars.com/d/2.0/pretod.html и здесь: http://www.digitalmars.com/d/2.0/cppdbc.html

Получается что и у D терпимая совместимость с C.

Можно ли в D сэмулировать поведение деструктора C++?

{
MyClass cl;
} <- здесь будет вызван деструктор

Да. Реализуем в MyClass метод ~this(). Далее есть много вариантов:

auto cl = new MyClass;
cl = null;
GC.collect;

{
scope cl = new MyClass;
}

auto cl = new MyClass;
delete cl;

Где вызывается деструктор очевидно.

Во втором случае память выделяется на стеке.

И еще вопрос если в ~this() кинется исключение, когда GC будет собирать мусор то что произойдет?

> если в ~this() кинется исключение, когда GC будет собирать мусор то что произойдет?

auto cl = new MyClass;
cl = null;
GC.collect; <- Exception вылетает здесь

{
scope cl = new MyClass;
} <- здесь

auto cl = new MyClass;
delete cl; <- здесь

В случае незапланированной сборки скорее всего из того вызова new, который спровоцировал сборку. (Сборщик мусора вызывается когда у программы нет требуемой new памяти.)

>В случае незапланированной сборки скорее всего из того вызова new, который спровоцировал сборку. (Сборщик мусора вызывается когда у программы нет требуемой new памяти.)

Но если так то это очень плохо. Тоесть везде где мы будем вызывать new возможно будет сгенерированно незапланированное исключение.

Везде где мы будем вызывать new и так возможно будет сгенерированно OutOfMemoryException. В D к этому прибавляются Exception из деструкторов.

>Везде где мы будем вызывать new и так возможно будет сгенерированно OutOfMemoryException. В D к этому прибавляются Exception из деструкторов.

Если будет так как ты говоришь то может возникнуть трудно улавливаемые ошибки напримар(напишу на C++):

class ExceptionA {};
class ExceptionB {};

class A
{
  public:
    A() { if (!ok) throw ExceptionA; }
    ~A() { if (!ok) throw ExceptionA; }
};

class B
{
  public:
    B() { if (!ok) throw ExceptionB; }
};

void test()
{
  try
  {
     lock_resource1();

     A a = new A;

     lock_resource2();

     B b = new B; // здесь возможно сгенерируется исключение ExceptionA и мы потеряем resource2
     lock_resource3();

     ....
     
     unlock_resource3();
     unlock_resource2();
     unlock_resource1();
   }
   catch (ExceptionA &e)
   {
     unlock_resource1();
   }
   catch (ExceptionB &e)
   {
     unlock_exception2();
     unlock_exception1();
   }
}

void main()
{
  for (int i = 0; i < 100000; i++)
    new A;

  test();
}



  
   

class ExceptionA : Exception {}
class ExceptionB : Exception {}

class A
{
    public:
        this() { if (!ok) throw new ExceptionA; }
        ~this() { if (!ok) throw new ExceptionA; }
}

class B
{
    public:
        this() { if (!ok) throw new ExceptionB; }
}

void test()
{
    lock_resource1();
    scope(exit) unlock_resource1;

    A a = new A;

    lock_resource2();
    scope (exit) unlock_resource2;

    B b = new B; // здесь возможно сгенерируется исключение ExceptionA но мы ничего не потеряем

    lock_resource3();
    scope (exit) unlock_resource3;

    ....
}

void main()
{
    foreach (i; 0 .. 100000)
        new A;

    test();
}

Если при успешном выполнении и в исключительной ситуации нужно как-то по разному unlock'ать ресурсы, можно использовать scope(success) и scope(failure), вместо scope(exit).

> Везде где мы будем вызывать new и так возможно будет сгенерированно OutOfMemoryException. В D к этому прибавляются Exception из деструкторов.

И как тогда будет выглядеть код??? (пишу в синтаксисе С)

try{

A* a = new A();

}catch( OutOfMemoryException& e ) {

/* ну это понятно */

} catch( Exception& e ) {

// а вот тут нам надо уметь обрабатывать *любое* исключение,
// которое может сгенерить один из многочисленных классов в своем деструкторе
// что самое прикольное -- если мы либа, то эти классы мы знать не можем!

}


А как этот вопрос решается в яве и С# ?

s/в синтаксисе С/в синтаксисе С++/

>Так вот писать ВСЕ на плюсах это такой же бред как и пахание земли самолетами.

А кто об этом говорит??? Вы невнимательны уважаемый.

>А как этот вопрос решается в яве и С# ?

В шарпе синтаксис будет похожий.

типа

try{

//blah-blah...

}

catch(Exception e)

{ }

>Я рад, что развивается D, но чую развиваться он будет очень долго. Почему? А потому что его MS не двигает...

Ну, это у Вас уж очень апокалиптично получилось... Lisp, Erlang, Python, Perl и ещё куча языков - ни один из них не двигает "мелкий софт"... что-то в модели развития событий не так?

Вот scope мне нравится. Как я понял можно сделать так:

int fd = open("cool_file");
scope(exit) close(fd);

А насчет исключений то OutOfMemoryException ожидаемое исключение, а вот со всеми остальные не задокументированными исключения для класса прийдется чтото делать.

Надо еще подумать на данным вариантом обработки йсключений. И кстати посоветуй литературу по D.

> Как я понял можно сделать так:

> int fd = open("cool_file");
> scope(exit) close(fd);
Да.

> И кстати посоветуй литературу по D.
Собственно книг всего 4. Одна на японском. Вторая на немецком. :) Третью Александреску ещё не дописал. Четвёртая - http://www.amazon.com/Learn-Tango-D-Kris-Bell/dp/1590599608

Кстати говоря как я понял в Китае немаленькое сообщество D(относительно конечно).

> Кстати, я "ушёл" с Си++ раньше, чем появились массовые решения с STL.

Тогда понятно почему говоришь про низкий уровень вхождения. C++ и C++ без STL и шаблонов - это разные языки.