Здравствуйте, Roman Odaisky, Вы писали:

RO>Здравствуйте, s.ts, Вы писали:

AG>>>Сюда же то, что деструктор не вызовется для недоделаных объектов (в Delphi — вызовется), что требует не только помещать ресурсы в классы, но и помещать кажды ресурс в свой класс.

RO>А как, по-твоему, деструктор мог бы вызываться для объекта, который никогда не существовал?!

Что значит "никогда не существовал" ?

Я имел в виду следующее.

Память уже выделена до вызова конструктора, так что там есть что проинициализировать и что деинициализировать.
Что и происходит с членами класса из списка инициализации.

Если бы была инициализация по умолчанию до вызова конструктора, то можно было бы просто звать деструктор в случае исключения.
Почему нет ?

Здравствуйте, NikeByNike, Вы писали:

NBN>Здравствуйте, StevenIvanov, Вы писали:

SI>>6) По сравнению с С# нет вкусностей типа делегатов и потрясающе мощного рефлекшна.

NBN>По поводу делегатов — не соглашусь.

Почему ?

Здравствуйте, Pasternak, Вы писали:

P>В общем случае — что угодно, а в данном случае что-то типа DocumentSaveError. Пускай плагины смотрят за тем, что они выбрасывают и подстраиваются под требования функции Document::save. В Jave такая проблема ведь как-то решается.

Если мне не изменяет память , то в JAVA давно хотят от этого избавиться

Здравствуйте, s.ts, Вы писали:

ST>Если бы была инициализация по умолчанию до вызова конструктора, то можно было бы просто звать деструктор в случае исключения.
ST>Почему нет ?

Паттерн «Zombie Object»?

class SomeClass: boost::noncopyable
{
public:
    SomeClass():
        m_something(42), // бросает исключение
        m_fd(open(somePath, O_RDONLY))
    {
    }

   ~SomeClass()
    {
        close(m_fd);
    }

private:
    AnotherClass m_something;
    int m_fd;
};

Чем здесь инициализировать m_fd? Нулем? Тогда деструктор недоделанного объекта закроет нулевой дескриптор, т. е., stdin, а это совсем не то, что нужно. (В WinAPI была бы аналогичная ситуация, потому что HANDLE() != INVALID_HANDLE_VALUE.)

Суть в том, что для многих классов нет приличного дефолтного конструктора. Когда конструктор создал один объект, второй не смог (исключение) и до третьего так и не добрался, то третий объект еще не существует, и вызывать какие бы то ни было его функции, в т. ч. деструктор, лишено смысла.

Можно было бы попытаться реализовать это на уровне языка. Но это нарушило бы принцип «платишь только за то, что используешь», и нарушился бы баланс между конструкторами и деструкторами.

Мораль сей басни такова: или класс управляет ровно одним ресурсом и, соответственно, закрывает его в деструкторе (std::*stream, std::tr1::unique_ptr), или все члены класса сами заботятся об освобождении своих ресурсов.

Здравствуйте, <Аноним>, Вы писали:

А>Не хватает:
А>1. Делегатов на уровне языка;
Вобще говоря делегат (если мы говорим про те что в .NET) тот еще мутант.
Просто функции должны быть первокласными функциями как во всех нормальных функциональных языка. Правда для этого нужен GC.
Кстати boost::function + лямбды гораздо точнее эмулируют первокласные функции чем делегаты в .NET.

Здравствуйте, merk, Вы писали:

M>сборка мусора чрезвычайно нехороша тем, что ею трудно управлять. это некий процесс идущий параллельно, и горе тому боингу, бортовая аппаратура которого займется сборкой мусора, во время посадки. когда у него вдруг отнимутся шасси и элероны — никому мало не покажется.
Только есть алгоритмы работающие с гарантиями жесткого реального времени...
А если еще будет небольшая поддержка со стороны железа то он будет работать ваще паралельно.

Здравствуйте, minorlogic, Вы писали:

M>Здравствуйте, Pasternak, Вы писали:

P>>В общем случае — что угодно, а в данном случае что-то типа DocumentSaveError. Пускай плагины смотрят за тем, что они выбрасывают и подстраиваются под требования функции Document::save. В Jave такая проблема ведь как-то решается.

M>Если мне не изменяет память , то в JAVA давно хотят от этого избавиться
Да, вроде ходят споры на эту тему. Тут немного об этом можно почитать.
Я не предлагаю клонировать реализацию поддержки исключений из Javы, мне просто в С++ не хватает инструмента который бы мог определить, что какое-то исключение оставлено без внимания. Об этом я пытался написать. Как это будет реализовано, большой разници нет, но мне кажется, если бы это было встроено в язык — было бы не плохо.

Здравствуйте, remark, Вы писали:

R>По поводу того, что компилятору требуется просматривать на несколько символов вперёд, вообще совсем не понятно. Как это связано с вопросом?
Усложнение и замедление компилятора.

M>>3. нет четкого понятия модуля с импортом и экспортом. хидеры — чисто инклудные файлы для обработки препроцессором.
R>Как часто у тебя это приводит к ошибкам или к существенному увеличению времени разработки?
Постоянно.
Начиная с очень долгой компиляции заканчивая DLL hell'ом.

Тот же немерле не смотря на то что языковых возможностей там куда как больше и компилируется много быстрее и DLL-hell'а там нет.

Здравствуйте, remark, Вы писали:

R>...

извините за оффтопик.

здесь

Автор(ы): Ivan Bodyagin
Дата: 14.11.2007
С выходом третьей версии C# появляется новая сущность — LINQ (Language Integrated Query) и данная статья посвящена как раз описанию места, которое занимает LINQ во всей дотнетной кухне, что во что integrated и как этим можно пользоваться...

чего пока (к сожалению) нет в С++ или возможности С# 3.0

Список впечатляет

— Вывод типа (Type Inference)
— Анонимные типы (Anonymous Type)
— Расширяющие методы (Extension Methods)
— Лямбда-выражения (Lambda Expression)
— Вывод типов и лямбда-выражения
— Дерево выражений (Expression Tree)
— Ленивые вычисления (Lazy Evaluation)
— Auto Properties

Здравствуйте, StevenIvanov, Вы писали:

SI>здесь

Автор(ы): Ivan Bodyagin
Дата: 14.11.2007
С выходом третьей версии C# появляется новая сущность — LINQ (Language Integrated Query) и данная статья посвящена как раз описанию места, которое занимает LINQ во всей дотнетной кухне, что во что integrated и как этим можно пользоваться...

чего пока (к сожалению) нет в С++ или возможности С# 3.0

SI>- Вывод типа (Type Inference)
Это будет в C++09.

SI>- Анонимные типы (Anonymous Type)
В C++09 можно будет сделать с помощью макросов и decltype, хоть и не так красиво (что-нибудь вроде ANON((a, 42)(b, 'b')(c, someExpr()))).

SI>- Расширяющие методы (Extension Methods)
Это только сахар. Меня сильно смущает, как же быть с конфликтами имен.

SI>- Лямбда-выражения (Lambda Expression)
Будут в C++09.

SI>- Вывод типов и лямбда-выражения
Будут в C++09.

SI>- Дерево выражений (Expression Tree)
Вот рефлексии не хватает...

SI>- Ленивые вычисления (Lazy Evaluation)
Это и в C++98 можно сделать, это не свойство языка.

SI>- Auto Properties
А свойства — это зло :-)

Здравствуйте, remark, Вы писали:

R>А ну да, понял. Проблема, если компилятор *не* инлайнит инлайн функцию.
R>Особая засада для дебаг сборки, когда компилятор вообще ничего не инлайнит, просто тупо кладёт каждую функцию в каждый объектный файл.

Эта беда в первую очередь от хреновой модульности, когда слишком много всего приходится класть в хедеры. Те же шаблоны, например.
Опять-таки, это связано с единым форматом объектных файлов, в которых всё должно быть уже скомпилировано. Без этого не получится дешёвая интеграция с другими языками.

R>А какой промышленный язык справляется с этой задачей лучше? Т.е. какой язык способен быстро сгенерировать эквивалент 40Мб нативного кода?

Вот такую нетривиальную задачу поставили разработчики промышленного языка перед разработчиками промышленных компиляторов

Здравствуйте, Roman Odaisky, Вы писали:

RO>Здравствуйте, s.ts, Вы писали:

ST>>Если бы была инициализация по умолчанию до вызова конструктора, то можно было бы просто звать деструктор в случае исключения.
ST>>Почему нет ?

RO>Паттерн «Zombie Object»?

RO>

RO>class SomeClass: boost::noncopyable
RO>{
RO>public:
RO>    SomeClass():
RO>        m_something(42), // бросает исключение
RO>        m_fd(open(somePath, O_RDONLY))
RO>    {
RO>    }

RO>   ~SomeClass()
RO>    {
RO>        close(m_fd);
RO>    }

RO>private:
RO>    AnotherClass m_something;
RO>    int m_fd;
RO>};
RO>

RO>Чем здесь инициализировать m_fd? Нулем? Тогда деструктор недоделанного объекта закроет нулевой дескриптор, т. е., stdin, а это совсем не то, что нужно. (В WinAPI была бы аналогичная ситуация, потому что HANDLE() != INVALID_HANDLE_VALUE.)

Ну да. Одно другое за собой и тянет.
Чем требовать конструктор по умолчанию, тогда уж заставить создавать объекты в куче.
Тогда членами классов будут только указатели/ссылки, которые нулем инициализируются на раз.
Еще ничего не напоминает ?

RO>Суть в том, что для многих классов нет приличного дефолтного конструктора. Когда конструктор создал один объект, второй не смог (исключение) и до третьего так и не добрался, то третий объект еще не существует, и вызывать какие бы то ни было его функции, в т. ч. деструктор, лишено смысла.

Если он был проинициализирован изначально, то можно и вызвать деструктор.

RO>Можно было бы попытаться реализовать это на уровне языка. Но это нарушило бы принцип «платишь только за то, что используешь», и нарушился бы баланс между конструкторами и деструкторами.

Ну а вот разработчики таких языков как Delphi, Java, С# пошли другим путем.
Нарушили, конечно, принцип.
Но не факт, что их путь не правильный.

RO>Мораль сей басни такова: или класс управляет ровно одним ресурсом и, соответственно, закрывает его в деструкторе (std::*stream, std::tr1::unique_ptr), или все члены класса сами заботятся об освобождении своих ресурсов.

Беда в том, что есть еще сырые указатели и т.п., которые сами о себе позаботиться не могут.
Речь об этом:

class raw_data
{
  int *m1;
  int *m2;
  int *m3;
  int *m4;
  void clear()
  {
    delete[] m1;
    delete[] m2;
    delete[] m3;
    delete[] m4;
  }
public:
  raw_data()
    : m1(0) // если это делать автоматом, а при исключениях звать деструктор, то и ловить исключения не надо.
    , m2(0)
    , m3(0)
    , m4(0)
  {
    try
    {
      m1 = new int[100];
      m2 = new int[100];
      m3 = new int[100];
      m4 = new int[100];
    }
    catch(...)
    {
      clear();
    }
  }
  ~raw_data()
  {
    clear();
  }
};

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

Это мое утверждение вроде бы не противоречит ни одному из твоих.
Спор какой-то ни о чем. Или я чего-то не понимаю ?

Здравствуйте, remark, Вы писали:

R>Регулярно можно слышать критику в адрес С++, что дескать язык морально устаревший, что время разработки на С++ неприлично большое, что в С++ постоянно приходится сражаться с ветряными мельницами. Посему хочется провести следующий опрос среди коллег С++ программистов.

R>Что Вам мешает в С++?

Нет рефакторинга

EyeOfHell пишет:
>
> 2. Отсутствие полиморфизма времени компиляции в макросах. В С99 конечно
> вариадики ввели, но все равно не айс
> 3. Невозможность вложенного препроцессора.

Школа m4?

Мб, лучше вообще без препроцессора?

--
ISO/IEC 8652:1995/Amd 1:2007

Здравствуйте, strcpy, Вы писали:

S>Здравствуйте, remark, Вы писали:

R>>Регулярно можно слышать критику в адрес С++, что дескать язык морально устаревший, что время разработки на С++ неприлично большое, что в С++ постоянно приходится сражаться с ветряными мельницами. Посему хочется провести следующий опрос среди коллег С++ программистов.

R>>Что Вам мешает в С++?

S>Нет рефакторинга

Ну да, приличных IDE нет.

Кодт пишет:

> R>А ну да, понял. Проблема, если компилятор *не* инлайнит инлайн функцию.
> R>Особая засада для дебаг сборки, когда компилятор вообще ничего не
> инлайнит, просто тупо кладёт каждую функцию в каждый объектный файл.
>
> Эта беда в первую очередь от хреновой модульности, когда слишком много
> всего приходится класть в хедеры. Те же шаблоны, например.
> Опять-таки, это связано с единым форматом объектных файлов, в которых
> всё должно быть уже скомпилировано. Без этого не получится дешёвая
> интеграция с другими языками.

Это надуманная причина — никто не запрещает ввести еще один формат
объектников, подразумевающий наличие центрального репозитария.
Поддерживает же в конце концов VC одновременно и COFF и OMF.

M>>>3. нет четкого понятия модуля с импортом и экспортом. хидеры — чисто инклудные файлы для обработки препроцессором.
R>>Как часто у тебя это приводит к ошибкам или к существенному увеличению времени разработки?
WH>Постоянно.
WH>Начиная с очень долгой компиляции заканчивая DLL hell'ом.
Казалось бы причем тут С++ к dll hell'у, который является чисто виндовым явлением как и сама dll. C++ про нее не в курсе. И боротьяс с ним надо средствами предусмотренными на платформе — юзать SxS с ее манифестами, это, (сорприз?) не исключительно .нетная штука, а вообще для любых длл предусмотрено в венде.

TB>Первое, что приходит в голову -- работа с памятью. Указатели, преобразование указателей, выделение и освобождение памяти...
За delete и голвые в С++ коде воще по рукам бить надо.

TB>Еще, пожалуй, обилие диалектов. Когда при обновлении Visual Studio перестает компилироваться код, это очень огорчает. Думаю, ни в одном другом языке эта проблема не цветет таким махровым цветом.
Правда, неужели переход с .net 1.1 на 2.0 был совершенно безболезненным?)

Здравствуйте, <Аноним>, Вы писали:

А>Казалось бы причем тут С++ к dll hell'у, который является чисто виндовым явлением как и сама dll.
dll-hell явление повсемесное, а не только виндовое. Ибо аналоги dll есть практически везде.

А>C++ про нее не в курсе.
По тому dll-hell и есть что не в курсе.

А>И боротьяс с ним надо средствами предусмотренными на платформе — юзать SxS с ее манифестами, это, (сорприз?) не исключительно .нетная штука, а вообще для любых длл предусмотрено в венде.
Единственный надежный способ бороться с dll-hell это грамотная поддержка dll на уровне языка.

А>>Казалось бы причем тут С++ к dll hell'у, который является чисто виндовым явлением как и сама dll.
WH>dll-hell явление повсемесное, а не только виндовое. Ибо аналоги dll есть практически везде.
Везде==Windows&UNIX?
А знаете почему в С++ нету стандартных средств для работы со структурой каталогов? Потому что не везде есть каталоги.
Знаете почему в С++ существуют триграфы? Потому что не везде есть { и }
Знаете почему в RFC на сетевые протоколы байты называются странным словом октеты? А потому что не везде байт — это 8 бит.
А вы тут про какието dll....

А>>C++ про нее не в курсе.
WH>По тому dll-hell и есть что не в курсе.
Потрудитесь настроить генерацию манифестов для своих проектов в студии.

А>>И боротьяс с ним надо средствами предусмотренными на платформе — юзать SxS с ее манифестами, это, (сорприз?) не исключительно .нетная штука, а вообще для любых длл предусмотрено в венде.
WH>Единственный надежный способ бороться с dll-hell это грамотная поддержка dll на уровне языка.
.нет боретьяс в dll hell средством платформы. Но ибо это язык для одной платформы, то мона значит сказать что это сделано на уровне языка? А ведь используются все те же application&module манифесты, activation контексты и прочая лабуда которая кстати весьма и весьма коряво устроена.