| 1 2 3 4 5 6 7 8 9 10 11 … 17 |
| Re[4]: Что Вам мешает в С++? | |
| От: | s.ts | ||
| Дата: | 23.06.08 10:20 |
| Здравствуйте, Roman Odaisky, Вы писали: RO>Здравствуйте, s.ts, Вы писали: AG>>>Сюда же то, что деструктор не вызовется для недоделаных объектов (в Delphi — вызовется), что требует не только помещать ресурсы в классы, но и помещать кажды ресурс в свой класс. RO>А как, по-твоему, деструктор мог бы вызываться для объекта, который никогда не существовал?! Что значит "никогда не существовал" ? Я имел в виду следующее. Память уже выделена до вызова конструктора, так что там есть что проинициализировать и что деинициализировать. Что и происходит с членами класса из списка инициализации. Если бы была инициализация по умолчанию до вызова конструктора, то можно было бы просто звать деструктор в случае исключения. Почему нет ? |
| Re[3]: Что Вам мешает в С++? | |
| От: | s.ts | ||
| Дата: | 23.06.08 10:22 |
| Здравствуйте, NikeByNike, Вы писали: NBN>Здравствуйте, StevenIvanov, Вы писали: SI>>6) По сравнению с С# нет вкусностей типа делегатов и потрясающе мощного рефлекшна. NBN>По поводу делегатов — не соглашусь. Почему ? |
| Re[4]: Что Вам мешает в С++? | |
| От: | minorlogic | ||
| Дата: | 23.06.08 10:48 |
| Здравствуйте, Pasternak, Вы писали: P>В общем случае — что угодно, а в данном случае что-то типа DocumentSaveError. Пускай плагины смотрят за тем, что они выбрасывают и подстраиваются под требования функции Document::save. В Jave такая проблема ведь как-то решается. Если мне не изменяет память , то в JAVA давно хотят от этого избавиться |
| Re[5]: Что Вам мешает в С++? | |
| От: | Roman Odaisky | ||
| Дата: | 23.06.08 10:57 | ||
| Оценка: | +1 | ||
| Здравствуйте, s.ts, Вы писали: ST>Если бы была инициализация по умолчанию до вызова конструктора, то можно было бы просто звать деструктор в случае исключения. ST>Почему нет ? Паттерн «Zombie Object»?
Чем здесь инициализировать m_fd? Нулем? Тогда деструктор недоделанного объекта закроет нулевой дескриптор, т. е., stdin, а это совсем не то, что нужно. (В WinAPI была бы аналогичная ситуация, потому что HANDLE() != INVALID_HANDLE_VALUE.) Суть в том, что для многих классов нет приличного дефолтного конструктора. Когда конструктор создал один объект, второй не смог (исключение) и до третьего так и не добрался, то третий объект еще не существует, и вызывать какие бы то ни было его функции, в т. ч. деструктор, лишено смысла. Можно было бы попытаться реализовать это на уровне языка. Но это нарушило бы принцип «платишь только за то, что используешь», и нарушился бы баланс между конструкторами и деструкторами. Мораль сей басни такова: или класс управляет ровно одним ресурсом и, соответственно, закрывает его в деструкторе (std::*stream, std::tr1::unique_ptr), или все члены класса сами заботятся об освобождении своих ресурсов. status=sent (delivered to file: /dev/null) |
| Re[4]: Что Вам мешает в С++? | |
| От: | WolfHound модератор | ||
| Дата: | 23.06.08 10:58 |
| Здравствуйте, <Аноним>, Вы писали: А>Не хватает: А>1. Делегатов на уровне языка; Вобще говоря делегат (если мы говорим про те что в .NET) тот еще мутант. Просто функции должны быть первокласными функциями как во всех нормальных функциональных языка. Правда для этого нужен GC. Кстати boost::function + лямбды гораздо точнее эмулируют первокласные функции чем делегаты в .NET. ... << RSDN@Home 1.2.0 alpha rev. 745>> Пусть это будет просто: просто, как только можно, но не проще. (C) А. Эйнштейн |
| Re[6]: Что Вам мешает в С++? | |
| От: | WolfHound модератор | ||
| Дата: | 23.06.08 10:58 |
| Здравствуйте, merk, Вы писали: M>сборка мусора чрезвычайно нехороша тем, что ею трудно управлять. это некий процесс идущий параллельно, и горе тому боингу, бортовая аппаратура которого займется сборкой мусора, во время посадки. когда у него вдруг отнимутся шасси и элероны — никому мало не покажется. Только есть алгоритмы работающие с гарантиями жесткого реального времени... А если еще будет небольшая поддержка со стороны железа то он будет работать ваще паралельно. ... << RSDN@Home 1.2.0 alpha rev. 745>> Пусть это будет просто: просто, как только можно, но не проще. (C) А. Эйнштейн |
| Re[5]: Что Вам мешает в С++? | |
| От: | Pasternak | ||
| Дата: | 23.06.08 11:00 | ||
| Оценка: | +1 | ||
| Здравствуйте, minorlogic, Вы писали: M>Здравствуйте, Pasternak, Вы писали: P>>В общем случае — что угодно, а в данном случае что-то типа DocumentSaveError. Пускай плагины смотрят за тем, что они выбрасывают и подстраиваются под требования функции Document::save. В Jave такая проблема ведь как-то решается. M>Если мне не изменяет память , то в JAVA давно хотят от этого избавиться Да, вроде ходят споры на эту тему. Тут немного об этом можно почитать. Я не предлагаю клонировать реализацию поддержки исключений из Javы, мне просто в С++ не хватает инструмента который бы мог определить, что какое-то исключение оставлено без внимания. Об этом я пытался написать. Как это будет реализовано, большой разници нет, но мне кажется, если бы это было встроено в язык — было бы не плохо. |
| Re[3]: Что Вам мешает в С++? | |
| От: | WolfHound модератор | ||
| Дата: | 23.06.08 11:10 | ||
| Оценка: | ![]() | ||
| Здравствуйте, remark, Вы писали: R>По поводу того, что компилятору требуется просматривать на несколько символов вперёд, вообще совсем не понятно. Как это связано с вопросом? Усложнение и замедление компилятора. M>>3. нет четкого понятия модуля с импортом и экспортом. хидеры — чисто инклудные файлы для обработки препроцессором. R>Как часто у тебя это приводит к ошибкам или к существенному увеличению времени разработки? Постоянно. Начиная с очень долгой компиляции заканчивая DLL hell'ом. Тот же немерле не смотря на то что языковых возможностей там куда как больше и компилируется много быстрее и DLL-hell'а там нет. ... << RSDN@Home 1.2.0 alpha rev. 745>> Пусть это будет просто: просто, как только можно, но не проще. (C) А. Эйнштейн |
| Re: маленький оффтопик | |
| От: | StevenIvanov | ||
| Дата: | 23.06.08 11:29 | ||
| Оценка: | 13 (1) | ||
| Здравствуйте, remark, Вы писали: R>... извините за оффтопик. здесь Автор(ы): Ivan Bodyagin чего пока (к сожалению) нет в С++ или возможности С# 3.0Дата: 14.11.2007 С выходом третьей версии C# появляется новая сущность — LINQ (Language Integrated Query) и данная статья посвящена как раз описанию места, которое занимает LINQ во всей дотнетной кухне, что во что integrated и как этим можно пользоваться... Список впечатляет — Вывод типа (Type Inference) — Анонимные типы (Anonymous Type) — Расширяющие методы (Extension Methods) — Лямбда-выражения (Lambda Expression) — Вывод типов и лямбда-выражения — Дерево выражений (Expression Tree) — Ленивые вычисления (Lazy Evaluation) — Auto Properties |
| Re[2]: маленький оффтопик | |
| От: | Roman Odaisky | ||
| Дата: | 23.06.08 11:43 |
| Здравствуйте, StevenIvanov, Вы писали: SI>здесь Автор(ы): Ivan Bodyagin чего пока (к сожалению) нет в С++ или возможности С# 3.0Дата: 14.11.2007 С выходом третьей версии C# появляется новая сущность — LINQ (Language Integrated Query) и данная статья посвящена как раз описанию места, которое занимает LINQ во всей дотнетной кухне, что во что integrated и как этим можно пользоваться... 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 А свойства — это зло :-) status=sent (delivered to file: /dev/null) |
| Re[5]: Что Вам мешает в С++? | |
| От: | Кодт модератор | ||
| Дата: | 23.06.08 11:57 |
| Здравствуйте, remark, Вы писали: R>А ну да, понял. Проблема, если компилятор *не* инлайнит инлайн функцию. R>Особая засада для дебаг сборки, когда компилятор вообще ничего не инлайнит, просто тупо кладёт каждую функцию в каждый объектный файл. Эта беда в первую очередь от хреновой модульности, когда слишком много всего приходится класть в хедеры. Те же шаблоны, например. Опять-таки, это связано с единым форматом объектных файлов, в которых всё должно быть уже скомпилировано. Без этого не получится дешёвая интеграция с другими языками. R>А какой промышленный язык справляется с этой задачей лучше? Т.е. какой язык способен быстро сгенерировать эквивалент 40Мб нативного кода? Вот такую нетривиальную задачу поставили разработчики промышленного языка перед разработчиками промышленных компиляторов ... << RSDN@Home 1.2.0 alpha rev. 655>> Перекуём баги на фичи! |
| Re[6]: Что Вам мешает в С++? | |
| От: | s.ts | ||
| Дата: | 23.06.08 13:47 |
| Здравствуйте, 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), или все члены класса сами заботятся об освобождении своих ресурсов. Беда в том, что есть еще сырые указатели и т.п., которые сами о себе позаботиться не могут. Речь об этом:
Одной из причин того, что при исключениях в конструкторе не вызывается деструктор является отсутствие начальной инициализации членов класса. Потому пришлось придумывать списки инициализации и т.д., чтобы дать пользователям языка общий механизм освобождения ресурсов при ошибках конструирования. Это мое утверждение вроде бы не противоречит ни одному из твоих. Спор какой-то ни о чем. Или я чего-то не понимаю ? |
| Re: Что Вам мешает в С++? | |
| От: | strcpy | ||
| Дата: | 23.06.08 13:53 | ||
| Оценка: | 13 (1) +2 -1 ![]() | ||
| Здравствуйте, remark, Вы писали: R>Регулярно можно слышать критику в адрес С++, что дескать язык морально устаревший, что время разработки на С++ неприлично большое, что в С++ постоянно приходится сражаться с ветряными мельницами. Посему хочется провести следующий опрос среди коллег С++ программистов. R>Что Вам мешает в С++? Нет рефакторинга Удвой число ошибок, если не получается добиться цели. |
| Re[2]: Что Вам мешает в С++? | |
| От: | OCTAGRAM | ||
| Дата: | 23.06.08 14:09 |
| EyeOfHell пишет: > > 2. Отсутствие полиморфизма времени компиляции в макросах. В С99 конечно > вариадики ввели, но все равно не айс > 3. Невозможность вложенного препроцессора. Школа m4? Мб, лучше вообще без препроцессора? -- ISO/IEC 8652:1995/Amd 1:2007 Posted via RSDN NNTP Server 2.1 beta |
| Re[2]: Что Вам мешает в С++? | |
| От: | s.ts | ||
| Дата: | 23.06.08 14:33 | ||
| Оценка: | +1 | ||
| Здравствуйте, strcpy, Вы писали: S>Здравствуйте, remark, Вы писали: R>>Регулярно можно слышать критику в адрес С++, что дескать язык морально устаревший, что время разработки на С++ неприлично большое, что в С++ постоянно приходится сражаться с ветряными мельницами. Посему хочется провести следующий опрос среди коллег С++ программистов. R>>Что Вам мешает в С++? S>Нет рефакторинга Ну да, приличных IDE нет. |
| Re[6]: Что Вам мешает в С++? | |
| От: | Sergey | ||
| Дата: | 23.06.08 15:10 | ||
| Оценка: | +1 | ||
| Кодт пишет: > R>А ну да, понял. Проблема, если компилятор *не* инлайнит инлайн функцию. > R>Особая засада для дебаг сборки, когда компилятор вообще ничего не > инлайнит, просто тупо кладёт каждую функцию в каждый объектный файл. > > Эта беда в первую очередь от хреновой модульности, когда слишком много > всего приходится класть в хедеры. Те же шаблоны, например. > Опять-таки, это связано с единым форматом объектных файлов, в которых > всё должно быть уже скомпилировано. Без этого не получится дешёвая > интеграция с другими языками. Это надуманная причина — никто не запрещает ввести еще один формат объектников, подразумевающий наличие центрального репозитария. Поддерживает же в конце концов VC одновременно и COFF и OMF. Posted via RSDN NNTP Server 2.1 beta |
| Re[4]: Что Вам мешает в С++? | |
| От: | Аноним 145 | ||
| Дата: | 23.06.08 16:35 | ||
| Оценка: | ![]() | ||
| M>>>3. нет четкого понятия модуля с импортом и экспортом. хидеры — чисто инклудные файлы для обработки препроцессором. R>>Как часто у тебя это приводит к ошибкам или к существенному увеличению времени разработки? WH>Постоянно. WH>Начиная с очень долгой компиляции заканчивая DLL hell'ом. Казалось бы причем тут С++ к dll hell'у, который является чисто виндовым явлением как и сама dll. C++ про нее не в курсе. И боротьяс с ним надо средствами предусмотренными на платформе — юзать SxS с ее манифестами, это, (сорприз?) не исключительно .нетная штука, а вообще для любых длл предусмотрено в венде. |
| Re[2]: Что Вам мешает в С++? | |
| От: | Аноним 145 | ||
| Дата: | 23.06.08 17:40 |
| TB>Первое, что приходит в голову -- работа с памятью. Указатели, преобразование указателей, выделение и освобождение памяти... За delete и голвые в С++ коде воще по рукам бить надо. TB>Еще, пожалуй, обилие диалектов. Когда при обновлении Visual Studio перестает компилироваться код, это очень огорчает. Думаю, ни в одном другом языке эта проблема не цветет таким махровым цветом. Правда, неужели переход с .net 1.1 на 2.0 был совершенно безболезненным?) |
| Re[5]: Что Вам мешает в С++? | |
| От: | WolfHound модератор | ||
| Дата: | 23.06.08 17:49 | ||
| Оценка: | 1 (1) ![]() | ||
| Здравствуйте, <Аноним>, Вы писали: А>Казалось бы причем тут С++ к dll hell'у, который является чисто виндовым явлением как и сама dll. dll-hell явление повсемесное, а не только виндовое. Ибо аналоги dll есть практически везде. А>C++ про нее не в курсе. По тому dll-hell и есть что не в курсе. А>И боротьяс с ним надо средствами предусмотренными на платформе — юзать SxS с ее манифестами, это, (сорприз?) не исключительно .нетная штука, а вообще для любых длл предусмотрено в венде. Единственный надежный способ бороться с dll-hell это грамотная поддержка dll на уровне языка. ... << RSDN@Home 1.2.0 alpha rev. 745>> Пусть это будет просто: просто, как только можно, но не проще. (C) А. Эйнштейн |
| Re[6]: Что Вам мешает в С++? | |
| От: | Аноним 145 | ||
| Дата: | 23.06.08 18:06 | ||
| Оценка: | +2 | ||
| А>>Казалось бы причем тут С++ к dll hell'у, который является чисто виндовым явлением как и сама dll. WH>dll-hell явление повсемесное, а не только виндовое. Ибо аналоги dll есть практически везде. Везде==Windows&UNIX? А знаете почему в С++ нету стандартных средств для работы со структурой каталогов? Потому что не везде есть каталоги. Знаете почему в С++ существуют триграфы? Потому что не везде есть { и } Знаете почему в RFC на сетевые протоколы байты называются странным словом октеты? А потому что не везде байт — это 8 бит. А вы тут про какието dll.... А>>C++ про нее не в курсе. WH>По тому dll-hell и есть что не в курсе. Потрудитесь настроить генерацию манифестов для своих проектов в студии. А>>И боротьяс с ним надо средствами предусмотренными на платформе — юзать SxS с ее манифестами, это, (сорприз?) не исключительно .нетная штука, а вообще для любых длл предусмотрено в венде. WH>Единственный надежный способ бороться с dll-hell это грамотная поддержка dll на уровне языка. .нет боретьяс в dll hell средством платформы. Но ибо это язык для одной платформы, то мона значит сказать что это сделано на уровне языка? |
| 1 2 3 4 5 6 7 8 9 10 11 … 17 |