Здравствуйте, 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>Почему нет ?
Чем здесь инициализировать m_fd? Нулем? Тогда деструктор недоделанного объекта закроет нулевой дескриптор, т. е., stdin, а это совсем не то, что нужно. (В WinAPI была бы аналогичная ситуация, потому что HANDLE() != INVALID_HANDLE_VALUE.)
Суть в том, что для многих классов нет приличного дефолтного конструктора. Когда конструктор создал один объект, второй не смог (исключение) и до третьего так и не добрался, то третий объект еще не существует, и вызывать какие бы то ни было его функции, в т. ч. деструктор, лишено смысла.
Можно было бы попытаться реализовать это на уровне языка. Но это нарушило бы принцип «платишь только за то, что используешь», и нарушился бы баланс между конструкторами и деструкторами.
Мораль сей басни такова: или класс управляет ровно одним ресурсом и, соответственно, закрывает его в деструкторе (std::*stream, std::tr1::unique_ptr), или все члены класса сами заботятся об освобождении своих ресурсов.
Здравствуйте, <Аноним>, Вы писали:
А>Не хватает: А>1. Делегатов на уровне языка;
Вобще говоря делегат (если мы говорим про те что в .NET) тот еще мутант.
Просто функции должны быть первокласными функциями как во всех нормальных функциональных языка. Правда для этого нужен GC.
Кстати boost::function + лямбды гораздо точнее эмулируют первокласные функции чем делегаты в .NET.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, merk, Вы писали:
M>сборка мусора чрезвычайно нехороша тем, что ею трудно управлять. это некий процесс идущий параллельно, и горе тому боингу, бортовая аппаратура которого займется сборкой мусора, во время посадки. когда у него вдруг отнимутся шасси и элероны — никому мало не покажется.
Только есть алгоритмы работающие с гарантиями жесткого реального времени...
А если еще будет небольшая поддержка со стороны железа то он будет работать ваще паралельно.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, Pasternak, Вы писали:
P>>В общем случае — что угодно, а в данном случае что-то типа DocumentSaveError. Пускай плагины смотрят за тем, что они выбрасывают и подстраиваются под требования функции Document::save. В Jave такая проблема ведь как-то решается.
M>Если мне не изменяет память , то в JAVA давно хотят от этого избавиться
Да, вроде ходят споры на эту тему. Тут немного об этом можно почитать.
Я не предлагаю клонировать реализацию поддержки исключений из Javы, мне просто в С++ не хватает инструмента который бы мог определить, что какое-то исключение оставлено без внимания. Об этом я пытался написать. Как это будет реализовано, большой разници нет, но мне кажется, если бы это было встроено в язык — было бы не плохо.
Здравствуйте, remark, Вы писали:
R>По поводу того, что компилятору требуется просматривать на несколько символов вперёд, вообще совсем не понятно. Как это связано с вопросом?
Усложнение и замедление компилятора.
M>>3. нет четкого понятия модуля с импортом и экспортом. хидеры — чисто инклудные файлы для обработки препроцессором. R>Как часто у тебя это приводит к ошибкам или к существенному увеличению времени разработки?
Постоянно.
Начиная с очень долгой компиляции заканчивая DLL hell'ом.
Тот же немерле не смотря на то что языковых возможностей там куда как больше и компилируется много быстрее и DLL-hell'а там нет.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
чего пока (к сожалению) нет в С++ или возможности С# 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>Чем здесь инициализировать 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. Невозможность вложенного препроцессора.
Здравствуйте, strcpy, Вы писали:
S>Здравствуйте, remark, Вы писали:
R>>Регулярно можно слышать критику в адрес С++, что дескать язык морально устаревший, что время разработки на С++ неприлично большое, что в С++ постоянно приходится сражаться с ветряными мельницами. Посему хочется провести следующий опрос среди коллег С++ программистов.
R>>Что Вам мешает в С++?
S>Нет рефакторинга
Кодт пишет:
> R>А ну да, понял. Проблема, если компилятор *не* инлайнит инлайн функцию. > R>Особая засада для дебаг сборки, когда компилятор вообще ничего не > инлайнит, просто тупо кладёт каждую функцию в каждый объектный файл. > > Эта беда в первую очередь от хреновой модульности, когда слишком много > всего приходится класть в хедеры. Те же шаблоны, например. > Опять-таки, это связано с единым форматом объектных файлов, в которых > всё должно быть уже скомпилировано. Без этого не получится дешёвая > интеграция с другими языками.
Это надуманная причина — никто не запрещает ввести еще один формат
объектников, подразумевающий наличие центрального репозитария.
Поддерживает же в конце концов VC одновременно и COFF и OMF.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[4]: Что Вам мешает в С++?
От:
Аноним
Дата:
23.06.08 17:35
Оценка:
M>>>3. нет четкого понятия модуля с импортом и экспортом. хидеры — чисто инклудные файлы для обработки препроцессором. R>>Как часто у тебя это приводит к ошибкам или к существенному увеличению времени разработки? WH>Постоянно. WH>Начиная с очень долгой компиляции заканчивая DLL hell'ом.
Казалось бы причем тут С++ к dll hell'у, который является чисто виндовым явлением как и сама dll. C++ про нее не в курсе. И боротьяс с ним надо средствами предусмотренными на платформе — юзать SxS с ее манифестами, это, (сорприз?) не исключительно .нетная штука, а вообще для любых длл предусмотрено в венде.
Re[2]: Что Вам мешает в С++?
От:
Аноним
Дата:
23.06.08 18:40
Оценка:
TB>Первое, что приходит в голову -- работа с памятью. Указатели, преобразование указателей, выделение и освобождение памяти...
За delete и голвые в С++ коде воще по рукам бить надо.
TB>Еще, пожалуй, обилие диалектов. Когда при обновлении Visual Studio перестает компилироваться код, это очень огорчает. Думаю, ни в одном другом языке эта проблема не цветет таким махровым цветом.
Правда, неужели переход с .net 1.1 на 2.0 был совершенно безболезненным?)
Здравствуйте, <Аноним>, Вы писали:
А>Казалось бы причем тут С++ к dll hell'у, который является чисто виндовым явлением как и сама dll.
dll-hell явление повсемесное, а не только виндовое. Ибо аналоги dll есть практически везде.
А>C++ про нее не в курсе.
По тому dll-hell и есть что не в курсе.
А>И боротьяс с ним надо средствами предусмотренными на платформе — юзать SxS с ее манифестами, это, (сорприз?) не исключительно .нетная штука, а вообще для любых длл предусмотрено в венде.
Единственный надежный способ бороться с dll-hell это грамотная поддержка dll на уровне языка.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
А>>Казалось бы причем тут С++ к 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 контексты и прочая лабуда которая кстати весьма и весьма коряво устроена.