Здравствуйте, okman, Вы писали:
O>Вот, например, такая ситуация — разрабатывается системный драйвер (на С++) и O>все функции, работающие с ресурсами, оборачиваются в RAII-обертки. O>Такой вопрос — а нужно ли (и безопасно ли) это вообще ? O>На первый взгляд нужно, потому что это позволило бы закрыть всякие потенциальные O>бреши и предотвратить возможные утечки памяти. С другой стороны, что если в коде O>возникает фатальное исключение и системе лучше всего сразу выбросить синий экран, чтобы O>предотвратить возможную дальнейшую порчу данных, а не выполнять раскрутку стека и O>вызов деструкторов ? В общем, неоднозначный вопрос.
Однозначный.
Исключение в драйвере это вообще особая тема. Как правило исключение == BSOD и никто и не пытается что то там разматывать.
А RAII там нужны для того, чтоб не было утечки ресурсов по вине программиста. С RAII не получится "забыть" дописать освобождение.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>-исключения PD>>-полиморфизм. PD>>-STL CC>+ templates без фанатизма.
А я их не исключал. А вот с фанатизмом — да, стоит исключить
Здравствуйте, Cyberax, Вы писали:
C>Floating point. Бросок асинхронного исключения может оставить FP в невнятном состоянии.
И в чём проблема его нормально сохранить/восстановить?!
AS>>А если немного, на минуточку, представить, что можно делать как-то иначе чем в С++?! C>Можно. GTK вон целую объектную систему на макросах построила, даже с рефлексией. Проблем-то никаких нет. C>Но зачем?!?!?
Э... как бы GObject фактически то же самое что в С++, но вид сбоку. В этом смысле я тоже не очень понимаю зачем =)
CC>PS. *_cast<> не люблю за многословность. C-style cast достаточно для 99.9% случаев.
Значит, ты неправильно понял, зачем эта многословность. Она же неспроста. Это сигнал разработчику: задумайся, а нужно ли тебе вообще преобразование типа здесь? Надо не скрывать проблему, используя C-style, а улучшать архитектуру. Если это пока невозможно, то пусть тут торчит _cast, как заноза.
В некотором смысле жаль, что в C++ так лелеют обратную совместимость. Отказ от многих фич C (начиная с преобразования типов) резко бы улучшил язык. Резко сократив сообщество пользователей, конечно .
Re[11]: Потому что одинаковый результат требует больших труд
Здравствуйте, CreatorCray, Вы писали:
Pzz>>Я обычно пишу геттеры/сеттеры даже на чистом Си. Это, во-первых, позволяет очертить публичный интерфейс, потому что как правило не все поля в структуре предназначены для того, чтобы их все подряд трогали. А во-вторых, позволяет позже, не трогая прочего кода, добавить, скажем, вычисление полей on demand, или привязать какое-нибудь действие к изменению какого-нибудь поля и т.п.
CC>Вот оно, premature pessimization в чистом виде.
Ну нет, конечно. Инлайновые функции ничего не стоят.
С-программер (Олег К.) и С++ программер (Vain) солидарно считают что программирование на С — мазохизм.
Почему ты мне присваиваешь свои слова? Я не говорил что программирование на Си — мазохизм.
За Vain`a говорить не буду, скажу за себя. Мне одинаково нравятся и С и С++. Конкретно в той ветке, тебе сказали сказали что ты пихаешь в программу на Си парадигмы которые так естественны для плюсов но абсолютно неестественны для Си. Эти самые парадигмы идут Сишной программе как корове седло. Поэтому тебе предложили отказаться думать как С++ программист когда пишешь программу на Си. Если ты этого сделать не можешь, то сменить инструмент. Все!
Здравствуйте, Alexéy Sudáchen, Вы писали:
C>>Floating point. Бросок асинхронного исключения может оставить FP в невнятном состоянии. AS>И в чём проблема его нормально сохранить/восстановить?!
В том и проблема.
AS>>>А если немного, на минуточку, представить, что можно делать как-то иначе чем в С++?! C>>Можно. GTK вон целую объектную систему на макросах построила, даже с рефлексией. Проблем-то никаких нет. C>>Но зачем?!?!? AS>Э... как бы GObject фактически то же самое что в С++, но вид сбоку. В этом смысле я тоже не очень понимаю зачем =)
Ну вот и возникает вопрос — нафиг всё было делать, если можно взять С++.
Здравствуйте, Kswapd, Вы писали:
K>Значит, ты неправильно понял, зачем эта многословность. Она же неспроста.
Спасибо, кэп!
K>Надо не скрывать проблему, используя C-style, а улучшать архитектуру. Если это пока невозможно, то пусть тут торчит _cast, как заноза.
Не, всё не так понято.
У меня приведение используется ровно там, где без него просто никак. Просто длинной записи *_cast<TYPE> я предпочитаю короткую (TYPE).
Ну а dynamic_cast вообще за всё время ни разу не понадобился.
K>В некотором смысле жаль, что в C++ так лелеют обратную совместимость.
Это кому как.
K>Отказ от многих фич C (начиная с преобразования типов) резко бы улучшил язык. Резко сократив сообщество пользователей, конечно .
Улучшил ли?
ИМХО получился бы ещё один язык непонятного назначения, интересный лишь группе фанатов.
Здравствуйте, Cyberax, Вы писали:
C>>>Floating point. Бросок асинхронного исключения может оставить FP в невнятном состоянии. AS>>И в чём проблема его нормально сохранить/восстановить?! C>В том и проблема.
Ну дык раскрой проблемность сего действия, для меня она как-то не очевидна.
AS>>Э... как бы GObject фактически то же самое что в С++, но вид сбоку. В этом смысле я тоже не очень понимаю зачем =) C>Ну вот и возникает вопрос — нафиг всё было делать, если можно взять С++.
Ну, спроси об этом авторов GTK+ меня то чего спрашивать? Я этого не знаю.
Здравствуйте, Олег К., Вы писали:
ОК>За Vain`a говорить не буду, скажу за себя. Мне одинаково нравятся и С и С++. Конкретно в той ветке, тебе сказали сказали что ты пихаешь в программу на Си парадигмы которые так естественны для плюсов но абсолютно неестественны для Си.
Гы, обажаю людей которые хорошо знаю чёрное, и уверены что белое тоже. А вот между этим если что и замечают, то только отенки серого. Их так забавно троллить =)
ОК>Эти самые парадигмы идут Сишной программе как корове седло. Поэтому тебе предложили отказаться думать как С++ программист когда пишешь программу на Си. Если ты этого сделать не можешь, то сменить инструмент. Все!
Ты знаешь какие-нить ещё фразы кроме 'вон из нашего двора'? Я не собираюсь отказваться думать, и делать как все, просто по тому что так все делают — тоже не собираюсь. Благо имею достаточно мозгов и воли чтобы себе это позволить. Так что спасибо, но я буду делать так как считаю нужным.
Здравствуйте, Alexéy Sudáchen, Вы писали:
AS>Относительно утечки ресурсов не всё так просто. В С есть свои техники аналогичные идеоме умных указателей и RAII. К тому же, на доступных версиях компилятора С++ до определённого момента (где-то в середине 90-ых если мне склероз не изменяет) было крайне тяжело контролировать ресурсы.
Склероз тебе изменяет. Исключения в С++ появились практически сразу, так же как и техника RAII. Собсно, из-за этой техники отсутствует ключевое слово finally.
AS>Но и в С вобщем-то тоже =)
Можно пример в пару строк, как это автоматизировать на С?
AS>Является ли минусом слабая типизация — это вообще сложный вопрос. Именно для С — это гигантский плюс, ИМХО =)
Э, нет. С++ предоставляет все ср-ва для нарушения типобезоасности. Так что, если очень надо стукнуть молотком по пальцам — ради бога. Тебя раздражает, что эти намерения нужно выражать явно? Это как в "дружелюбной" программе: "вы точно хотите стукнуть себе молотком по пальцам?" [Да] [Нет] [Не знаю С++]
Здравствуйте, vdimas, Вы писали:
V>Склероз тебе изменяет. Исключения в С++ появились практически сразу, так же как и техника RAII. Собсно, из-за этой техники отсутствует ключевое слово finally.
Да шо вы говорите! Я вообще-то пишу на плюсах ещё с тех времён когда в них не было ни исключений ни шаблонов =)))) Давай расскажи мне за RAII без шаблонов =)
AS>>Но и в С вобщем-то тоже =) V>Можно пример в пару строк, как это автоматизировать на С?
Управление ресурсами? Ну напишу как время будет. Если хочшь пару строк, пожалуйста —
int buildno;
__Auto_Unwind
buildno = strtol(Str_Trim(Oj_Read_Line(File_Open("textfile","r")),0,10);
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Отмечу и один недостаток. Деструктор. В С закрывающая фигурная скобка у меня абсолютно никаких эмоций не вызывает, код ей не соответствует. В С++ на закрывающую фигурную может оказаться повещенным такое количество действий, что мало не покажется. Иными словами, в С для выполнения чего бы то ни было надо именно в этом месте написать код, а в С++ он вызовется, хотя именно в этой строке ничего не написано.
Недавно пришла в голову идея специально для тех, кто волнуется, что при выходе из scope-а в С++ производятся какие-то дополнительные действия.
#define CALL_DESTRUCTOR(X) __noop /* define for your compiler appropriately */void foo()
{
MyClass a;
MyClass b;
// ...
CALL_DESTRUCTOR(b); // must be in reverse order!
CALL_DESTRUCTOR(a);
}
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Конечно. В сущности вопрос — нужен этот полиморфизм или нет. Если не нужен — то без него можно обойтись (Сейчас набегут здешние специалисты и объяснят, что деструктор должен быть виртуальным . Можно этот полиморфизм смоделировать и на чистом С, но писать придется все самому.
И в качестве побочного эффекта при ручной реализации компилятор не сможет проводить спекулятивную оптимизацию.
А она может дать весьма существенную экономию по сравнению с гарантированно виртуальным вызовом.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Конечно. В сущности вопрос — нужен этот полиморфизм или нет. Если не нужен — то без него можно обойтись (Сейчас набегут здешние специалисты и объяснят, что деструктор должен быть виртуальным . Можно этот полиморфизм смоделировать и на чистом С, но писать придется все самому. S>И в качестве побочного эффекта при ручной реализации компилятор не сможет проводить спекулятивную оптимизацию. S>А она может дать весьма существенную экономию по сравнению с гарантированно виртуальным вызовом.
Я же не предлагаю так делать на С++
Ну а если на С все же эмулировать (конечно, вопрос — зачем ?), то придется.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Alexéy Sudáchen, Вы писали:
AS>>Сколько однако возможностей в одном языке С++! И нифига это не серьёзное ограничение что его сложность (библиотеки то на С++ писаны, и часто весьма зубодробильном) делает практически нереальным поиск программеров способных с такой сложностью справиться. =)
FR>C++ реально переусложнен, те же, и даже большие возможности вполне доступны и на гораздо более простом языке, например FR>D практически полностью может все то что и новый C++0x плюс много FR>чего дополнительно (GC, иммутабельность, чистые функции и CTFE, замыкания, более мощные шаблоны) но писать на нем проще FR>чем на C++, неожиданностей гораздо меньше и в этом он как раз ближе к Си.
Вы лучше скажите когда выйдет стабильный компилятор для D ?
А еще я хочу с бекэндом GCC или LLVM, а еще лучше бекэнд VC
И еще нормальные средства отладки, а еще лучше интеграция с VisualStudio.
Ну можно и не студия, но на том же уровне как с С++.
Здравствуйте, Alexéy Sudáchen, Вы писали:
AS>Да шо вы говорите! Я вообще-то пишу на плюсах ещё с тех времён когда в них не было ни исключений ни шаблонов =)))) Давай расскажи мне за RAII без шаблонов =)
При чем тут шаблоны и RAII? И в каких это годах в C++ не было исключений? Это до начала 90-х разве что. Уже в 91-м исключения были.
AS>
Здравствуйте, vdimas, Вы писали:
AS>>Да шо вы говорите! Я вообще-то пишу на плюсах ещё с тех времён когда в них не было ни исключений ни шаблонов =)))) Давай расскажи мне за RAII без шаблонов =) V>При чем тут шаблоны и RAII? И в каких это годах в C++ не было исключений? Это до начала 90-х разве что. Уже в 91-м исключения были.
Да шо вы говорите?! =))) В 92-ом я писал на Borland C++ 2.0, в 94-ом на тройке. Может у вас был какой-то другой компилер? И хде вы его интересно взяли?! Шаблоны же тут при том что писать на каждый чих обёртки управляющие ресурсами не сильно удобнее чем управлять руками.
AS>>
Это как в "дружелюбной" программе: "вы точно хотите стукнуть себе молотком по пальцам?" [Да] [Нет] [Не знаю С++] 
