C++ haters handbook :-)

[Ull9]

неопределенность, конечно, есть. но совсем другого плана: может в этом промежутке произойти исключение или нет.
ответ на этот вопрос можно получить, посмотрев на прототипы вызываемых функций. если лень - считайте, что может. но вам почти никогда не надо знать тип исключения. например:
catch ( ... ) { delete p; throw; }

Новы же сами, признавали, несколкими постами выше что это дурной стил.
catch (...)
Что поменялос?
я например, делая проверку кода других (частенко делат приходится), сразу отнечаю это как признак плохого дизайна! точно так же как и dynamic_cast, const_cast, void* и тд и тп.

зачем вводить имя и тип переменной, которая вас не интересует? а еще лучше - использовать raii и тогда ловить вообще _ничего_ не надо и даже задумываться о наличии исключений не надо.

Да краеуголный камен с++ жесткая проверка типов. И почему мне от этого отказыватся?
а как же я пойму что за ошибка? что мне нехватает - памяти? или БД недоступно? или файловая система капут. И не надо мне говорит, что бросай эксепшн далше. может нет никого далше. может далше код фортран!

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

Вот это и слишком общее место, что значит бросающее что то? мне этого мало!
я должен принимат решение, что за эксепшн я получил, и вообще. понимат возможен ли эксепшн вообще теоретически из какойто функции, а у мнея этого нет!
Спрошу так тебе нравится работат с void*? мне нет, я считаю это злом, и признаком плохого дизайна. а ты предлагаеш по сути его.

спецификация типов исключений является не самым удачным свойством с++ и использовать ее рекомендуется пореже

Так я и говорю, что не толко спецификация, но и сама идея не реализована до конца.
так как например в ява, там компилятор НЕПОЗВОЛИТ, игнорироват эксепшн. И точно надо знат тип. в с++ пожалуйста, так можно делат.что ест дыра в безопасности

ПС. пардон мягкий знак пропал

[pal]

Новы же сами, признавали, несколкими постами выше что это дурной стил.
catch (...)
Что поменялос?

я явно признавал дурным стилем что-то другое.
catch (...){/*release*/; throw; } это самый часто применяемый вариант

я например, делая проверку кода других (частенко делат приходится), сразу отнечаю это как признак плохого дизайна!

быстрый grep '\bcatch\b' /usr/include/c++/4.1.1/*{,/*} возвращает _один_ catch (const bad_weak_ptr&) и полторы сотни catch(...)

Да краеуголный камен с++ жесткая проверка типов. И почему мне от этого отказыватся?
а как же я пойму что за ошибка? что мне нехватает - памяти? или БД недоступно? или файловая система капут.

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

И не надо мне говорит, что бросай эксепшн далше. может нет никого далше. может далше код фортран!

фортран не сможет вызвать функции с с++ линковкой

Вот это и слишком общее место, что значит бросающее что то? мне этого мало!
я должен принимат решение, что за эксепшн я получил, и вообще.

еще раз, какое решение вы примете в примере с { delete p; throw; } ? по другому удалите ? или не удалите совсем ?

понимат возможен ли эксепшн вообще теоретически из какойто функции, а у мнея этого нет!

ответ содержится в прототипе. как я уже говорил, если лень смотреть в прототип, считайте, что может

Спрошу так тебе нравится работат с void*? мне нет, я считаю это злом, и признаком плохого дизайна. а ты предлагаеш по сути его.

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

Так я и говорю, что не толко спецификация, но и сама идея не реализована до конца.
так как например в ява, там компилятор НЕПОЗВОЛИТ, игнорироват эксепшн. И точно надо знат тип. в с++ пожалуйста, так можно делат.что ест дыра в безопасности

можете привести пример, демонстрирующий преимущество явы ?

[Ull9]

я явно признавал дурным стилем что-то другое.
catch (...){/*release*/; throw; } это самый часто применяемый вариант

обьясните мне, в чем разница
catch ( ... ) { delete p; throw; }
catch (...){/*release*/; throw; }
первое вы называете дурным стилем, а второе хорошим стилем?

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

да в том то и дело, если недоступна база я обязан закрыть свои сокеты и стучатся в нее (БД) пока она не откроется, а если не могу прочесть файл конфигурации, то мне нужно вежливо закрыть приложение, не только в ресурсах дело.

еще раз, какое решение вы примете в примере с { delete p; throw; } ? по другому удалите ? или не удалите совсем ?

По обстоятельствам, мне нужно знать обстоятельства! может и не буду. мне черно-белого флажка недостаточно. а вообще я бы смарт поинтеры для ресурсов применял, дались они вам. не только в ресурсах дело. может например мне без этого ресурса можно продолжеть работу, а может и нет.

ответ содержится в прототипе. как я уже говорил, если лень смотреть в прототип, считайте, что может

Так, в том и дело, что мне недостаточно знать что может, мне нужно знать тип.
это как функхия возвращает void*. какой ит нее толк? и с++, здесь терят свою строгость и однозначность. позволяет думать и предпологать что угодно. это мне и не нравится.

можете привести пример, демонстрирующий преимущество явы ?

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

[homo ludens]

особенно в свете "Не нравится - не пиши. Я пишу себе инструментарий сам, ты - пользуешься чужим."

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

Вы ссылаетесь на чужой?

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

но всех перечисленных тобою проблем в с++ при правильном дизайне просто нет.

Назови мне программу, которая получая на вход исходный код говорит - правильный у нее дизайн или нет. Если такой программы нет - то твоя команда программистов зависит от мнения старших товарищей. Которе резко меняется при смене
1. товарищей
2. фирмы
3. команды.
4. идеологии
и т.п.
Если нет формального критерия "правильного дизайна" то все о чем ты говоришь - спекуляции на всеобщей убежденности, что такой критерий есть. А его нет.

для С ты вынужден пиосать доморощеные макросы.

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

Ну а если не в пределах блока. Что так редки у тебя сличай, когда в одном блоке даешь малок а в другом фри? Почему так сузил проблему?

Подумай еще раз и почитай мой пост внимательней. Если в одном блоке есть выделение памяти а в другом освобождение, то где-то в коде обязательно найдется блок, вызывающий оба. В худшем случае это будет main() {};
В этом блоке кода будет найдена ошибка, точнее номер строки кода внутри блока где эта ошибка возникает. Скорее всего там будет вызов другой функции, ее блок тоже можно проверить. В С нет связности кода по определению, простым последовательным пересмотром всех блоков кода можно все найти.
Для С++ это неверно, например глобальные объекты, определенные до main вообще не имеют вызывающих блоков, а отследить граф вызова с перегрузками, конструктароми временных объектов и т.п. вообще нельзя.

ну а разве в С нет виртуальных вызовов? Ты когда нибудь поинтерами на функции пользовался? Это не есть ли прямой аналог виртуальной функции в с++?

нет, не аналог. В С есть индиректный вызов функции и программисты им пользуются, но только тогда, когда это действительно надо. В большистве случаев для С это другой вариант конструкций switch/case, не более того. Динамический объект который содержит динамический адрес функции - вещь намного более редкая, чем в С++.
В С++ это обычная практика потому проблемы этого вида происходят намного чаще.
варианты когда в С возможна ошибка - это два основных варианта. Прямой вызов указателя на функцию при нулевом или неопределенном значении указателя. Ловится за 5 минут, большинство случаев даже без рантайма.
Вызов "метода" - есть указатель на структуру, членом которого есть указатель на функцию. Родительский указатель 0 или неопределен. Ловится так же.

Ты вообще знаешь что такое класс, а что такое обьект? что можно делать с классами, что с обьектами?

извини, опечатался. Ты рад, что нашел у меня ошибку? Спроси меня еще, что такое метакласс, я правда знаю.
втречный вопрос - а ты знаешь что можно делать с классами с помощью метаобъектного протокола?

То что с++ позволяет делаТъ ПРИ ПРАВИЛъНОМ ДИЗАЙНЕ, ты должен писать свои макросы.

В С++ не формального алгоритма отличия правильного дизайна от неправильного. Это порождает кучу хлебных мест для людей, которые решают что правильно, а что - нет.
Макросы свои я не должен писать. Я их уже написал и забыл когда это сделал. Это разовая работа, которая дала мне преимущество перед правильным кодом С++ - вы раз за разом вынуждены писать "правильно" убеждая себя в том, что это не в напряг. Мне уже не надо ничего писать.

ну и так далее по тексту...

так все-таки что разумнее - требовать от компилятора невозможного, компенсируя его недостатки неформальными критериями "правильности" прораммы или пойти по Unix way - компилятор компилит, стайл чекер проверяет стили, ран-тайм чекер - проверяет выполнение, а статический чекер - исходный код?

[homo ludens]

особенно с макросами

как ни странно - даже с ними.
Тем более что если они не нравятся - легко можно работать с выходом gcc -E.

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

или не находится. пример неопределенности - ваш спор с Ull9.

это еще почему он должен читать всю ? делаете каждый отдельный кусок exception-safe и typesafe и все отлично работает. тогда как в с даже неизвестно, надо ли проверять возвращаемое значение функции х

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

это не проблема с++. это даже не проблема ооп. это проблема либо дизайна, либо прикладной области.

если бы это было так, то эта проблема наблюдалась бы и в других языках. Это неправда.

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

мой цикл имеет то, чего нет у вас - стабильность кода. Функция, которая прогоняет этот цикл никогда и никем не правится. Программист, который придет после меня вставит свою подсистему в одном единственном файле - с определением массива. Если требуется раздельный вариант инициализации для однопоточной и многопоточной системы - у меня это сделать просто, у вас - нельзя.
Мой вариант гибче вашего и повышает стабильность кода.

вы показали что-то другое. glibc поддерживает _только_один_ компилятор. и как вы не выкручивайтесь, буст поддерживает его же и больше

Мне кажется, мы просто не синхронизировали терминологию.
Когда мы говорим "портировано под платформу" - мы понимаем разные вещи.
1. хардвер
2. Ос
3. Компилер.
Сравнивая по первому пункту, получаем что boost отдыхает.
Сравнивая по второму отдыхает glibc.
Сравнивая по третьему получаем тоже - glibc компилится только gcc.
Последние два пункта вполне понятны, во первых glibc является составной частью ОС линукс, а воторых поддержка ansi С здесь выгод практически не дает - одни минусы, учитывая высокий уровень портируемости самого gcc.
Интерфейсы однако, которые мы обсуждали, являются частью не glibc а POSIX+ISO C. Они по прежнему имеют более высокую портируемость, чем boost - причем по всем трем параметрам.

гарантированно все выловит только строгое доказательство, что выловлено гарантированно все

Вы valgrind-ом когда послений раз пользовались?

[Ull9]

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

Раширят, еще как раширяет, с помошэ враппера, я могу переименовать функцию, добавить новую, или убрать существующую. легко

Назови мне программу, которая получая на вход исходный код говорит - правильный у нее дизайн или нет. Если такой программы нет - то твоя команда программистов зависит от мнения старших товарищей. Которе резко меняется при смене
1. товарищей
2. фирмы
3. команды.
4. идеологии
и т.п.
Если нет формального критерия "правильного дизайна" то все о чем ты говоришь - спекуляции на всеобщей убежденности, что такой критерий есть. А его нет.

Как ты ловко подменил тему спора. Я не утверждал что с++ должен распозновать плохой дизайн. Я не утверждал, что само наличие с++ компилятора освобждает программиста писатъ правильный дизайн. А правильный дизайн, яето вешь довольно обьективная, и даже мой спор с Пал. если нам дать четкие условия на задачу, мы породим приблизительно один дизайн.

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

например, что. конкретно? с++ & правильный дисайн против твоих макросов. Давай конкретный пример, когда твой макрос справится с тем, с чем с++ не справится.
У меня естьпару примеров когда твой макрос не справится, но я подожду для начала твои.

Подумай еще раз и почитай мой пост внимательней. Если в одном блоке есть выделение памяти а в другом освобождение, то где-то в коде обязательно найдется блок, вызывающий оба. В худшем случае это будет main() {};

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

можно проверить. В С нет связности кода по определению, простым последовательным пересмотром всех блоков кода можно все найти.

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

Для С++ это неверно, например глобальные объекты, определенные до main вообще не имеют вызывающих блоков

Хмм. а в С значит глобальных переменных нет? глобальные обьекты кстати, вешь нехорошая, и в правольном дизайне их быть недолжно, или сведено к самому минимуму. А С без них не может. наличие глобальных обьектов это наследие от С. вот ты и вынужден писать свои макросы. но у с++, при правильном дизайне их просто нет.

а отследить граф вызова с перегрузками, конструктароми временных объектов и т.п. вообще нельзя.

так и не надо его следить. Вот в чем фишка, С++ с правильным дизайном все сам красиво отследит и память не утечет.

нет, не аналог. В С есть индиректный вызов функции и программисты им пользуются, но только тогда, когда это действительно надо. В большистве случаев для С это другой вариант конструкций switch/case, не более того. Динамический объект который содержит динамический адрес функции - вещь намного более редкая, чем в С++.

Редкая, но означет ли что ее нет вообще? и что делает твой макрос если она таки есть?
Все? перестает работать?

В С++ это обычная практика потому проблемы этого вида происходят намного чаще.

при правильном дизайне, (смарт-поинтер) никогда.

варианты когда в С возможна ошибка - это два основных варианта. Прямой вызов указателя на функцию при нулевом или неопределенном значении указателя. Ловится за 5 минут, большинство случаев даже без рантайма.

без рантайма, без тестов, которые покроют все возможные варианты входных данных это отследить невозможно. На то она и динамика.

извини, опечатался. Ты рад, что нашел у меня ошибку? Спроси меня еще, что такое метакласс, я правда знаю.
втречный вопрос - а ты знаешь что можно делать с классами с помощью метаобъектного протокола?

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

В С++ не формального алгоритма отличия правильного дизайна от неправильного.

я никгда этого неговорил, ты споришь сам с собой.

Макросы свои я не должен писать. Я их уже написал и забыл когда это сделал. Это разовая работа, которая дала мне преимущество перед правильным кодом С++ - вы раз за разом вынуждены писать "правильно" убеждая себя в том, что это не в напряг. Мне уже не надо ничего писать.

Еше раз пример! давай пример, когда твои макросы круче с++. Пример! я устал от слов.

так все-таки что разумнее - требовать от компилятора невозможного, компенсируя его недостатки неформальными критериями "правильности" прораммы или пойти по Unix way - компилятор компилит, стайл чекер проверяет стили, ран-тайм чекер - проверяет выполнение, а статический чекер - исходный код?

компилятор комилит, согласен
стайл чекер проверятет стили? отчасти комилятор проверит стиль. окончательно стильможет проверить только человек. А что ты называешь стилем?
ран-тайм чекер? это тесты? ну так что должны быть тесты? никто не спорил.
статический чекер? не спавится,
давай примеры, голословный ты наш.

[homo ludens]

Раширят, еще как раширяет, с помошэ враппера, я могу переименовать функцию, добавить новую, или убрать существующую.

wrapper на IP сокет не добавит тебе функциональность TCP. И, кстати, использование таких оболочек в большинстве своем означает процедурное мышление под ОО-маской.

Как ты ловко подменил тему спора. Я не утверждал что с++ должен распозновать плохой дизайн. Я не утверждал, что само наличие с++ компилятора освобждает программиста писатъ правильный дизайн. А правильный дизайн, яето вешь довольно обьективная, я невстречал двух разных мнений. и даже мой спор с Пал. если нам дать четкие условия на задачу, мы породим приблизительно один дизайн.

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

например, что. конкретно? с++ & правильный дисайн против твоих макросов. Давай конкретный пример, когда твой макрос справится с тем, с чем с++ не справится.
У меня естьпару примеров когда твой макрос не справится, но я подожду для начала твои.

Рантайм (в моем случае valgrind) проверят ошибки рантайма. Компилятор рантайм не проверяет.
Макрос + рантайм проверят ошибки рантайма в тех ветвлениях, которые при нормальной работе программы достижимы редко.
Примеры, когда макрос не справится у меня тоже есть. Опять-таки, синтаксический препроцессор эти проблемы решит. Я могу подменять макросами if и while но не могу подменить for. Однако С++ не решит ни одну проблему, которую решают макрос+рантайм.

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

Библиотека состоит из функций, каждая из которых есть блок. Для качественной библиотеки пишутся юнит тесты, где есть main и вызов всех методов библиотеки со всеми use case. Я во всяком случае в своих либах так делаю.
Для многопоточных приложений race condition так не отлавливаются, но это и не ставится в задачу. Хотя были техники, основанные на статическом анализе кода, но там много ложных срабатываний. Race conditions требует действительно полного анализа кода, а не только блока. Там я работаю чуть по другому - в зависимости от требований приложения. Здесь универсальных рецептов пока нет.
В valgrind входит тулза для отлова race conditions однако ей пользоваться тяжело - с ее точки зрения надо лочить мютексы на каждую функцию, в т.ч. на те, которые атомарны по определению (например printf - атомарен).

ну а сли строк много? скажем 500 тыс? не проще ли компилятор заставить правильно работать?

O(n) для С, намного больше для С++. Компилятор не установит соответствия между блоками компилирующимися отдельно. Плюс еще много все. Поймите. Компилятор не может по определению отловить все ошибки. Следовательно пытаться его в этом направлении улучшать - бесполезное дело. Статический чекинг+рантйм чекинг сделают это лучше и в теории способны на абсолютное решение основных проблем.

Хмм. а в С значит глобальных переменных нет? глобальные обьекты кстати, вешь нехорошая, и в правольном дизайне их быть недолжно, или сведено к самому минимуму. А С без них не может. наличие глобальных обьектов это наследие от С.

Нет конструкторов и деструкторов глобальных переменных.
А тот, кто тебе сказал, что С без них не может - соврал.
Есть устаревшие библиотечные функции, которые привязаны к глобальным переменным. В большинстве своем есть их непортируемые реентрантные аналоги.

так и не надо его следить. Вот в чем фишка, С++ с правильным дизайном все сам красиво отследит и память не утечет.

Нереально. Плюс правильный дизайн без формальных спецификаций правильного дизайна.
Полный анализ такой фигни - это задаче больше чем O(n). А если компилятор работает не в O(n) - то это я просто не знаю как называется. Забудьте про ночные билды. Как минимум.
Статический чекинг не связан этими ограничениями.

Блин, я никак не пойму, если все так хорошо, откуда ты знаешь тогда слова креш-дамп?

Редкая, но означет ли что ее нет вообще? и что делает твой макрос если она таки есть?
Все? перестает работать?

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

прогоняя чужой код С++ через valgrind вижу два постоянных глюка - вызовы виртуальных методов дестроенных объектов и pvc. Наверное программисты хреновые, в дизайн не въезжают.

при правильном дизайне, (смарт-поинтер) никогда.

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

Ближайший аналог смарт-пойтеров в С - хендлы, пример которых можно увидеть в pthread.h

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

brainbench'ами по ООП и С++ померяемся? Мои кажется еще не истекли.
Как знаток ООП - расскажи нам что такое метаобъектные протоколы и компиляторы на С++. Более функциональным аналогом которых являются синтаксические парсеры, за которые я говорю.
Не знаешь принципов ООП ты, если называешь объектными реализациями враппер над сокетами. Под CORBA писал? Напиши и сравни.

я никгда этого неговорил, ты споришь сам с собой.

я не спорю, а утверждаю. Без формальной спецификации все разговоры о правильности дизайна - туфта.
Формальной спецификации нет (и кстати не может быть).

Еше раз пример! давай пример, когда твои макросы круче с++. Пример! я устал от слов.

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

компилятор комилит, согласен
стайл чекер проверятет стили? отчасти комилятор проверит стиль. окончательно стильможет проверить только человек. А что ты называешь стилем?

выход astyle например. Проверяется элементарно. Или проверка идентации - настолько интеллектуальная техника?

ран-тайм чекер? это тесты? ну так что должны быть тесты? никто не спорил.

если у тебя есть друзья с линуксом, попроси их запустить за тебя valgrind. Пусть они тебе расскажут. Тесты, блин...

Нет разумнее не писать ловщик ошибок, а использовать компилятор на все 100%, и здесь с++ выгоднее с. причина та же, ловщик ошибок не покроет весь код при прогонах. во всяком случае это далеко не тривиальная задача. Так зачем это надо?

Твои слова?
Мне трудно спорить с человеком, который говорит, что ему ненужно штуки баксов, потому что купить яхту все равно не хватит. С логикой что-то у тебя не то.

статический чекер? не спавится,

сравни выход splint с выходом С++. второй раз говорю, не позорься.
Повторяю - все нормальные компиляторы работают в O(n). Статическому чекеру эти неувязочки пофиг. Ты не в академии "Шаг" учился? Это имхо на младших курсах проходят.

давай примеры, голословный ты наш.

мне кажется тебе хочется поругаться?
примеры ты видел, но по прежнему утверждаешь:
1. Никому не нужна система отлова ошибок - С++ + правильный дизайн делают все необходимые проверки.
2. Никому не нужна система отлова ошибок - она все равно не может поймать все, поэтому надо пользоваться С++, так как С++ + правильный дизайн делают все необходимые проверки.
3. Никому не нужна связность кода, С++ + правильный дизайн решают все вопросы.
4. Статический чекер не справится, потому он не нужен, С++ + правильный дизайн делают все необходимые проверки.
5. Рантайм чекер не пройдет всех веток, потому он не нужен. С++ + правильный дизайн делают все необходимые проверки.

Подтверди это или опровергни в следующем посте.
Или я буду думать, что говорю с ботом.
Цитаты из твоих сентенций могу привести. Если забыл.

[Ull9]

wrapper на IP сокет не добавит тебе функциональность TCP.

я же сказал легко. например я ввожу хартбиты. и если соединение оборвалось. я сразу вижу что ТСП оборвался. Или ввожу авторизацию и аутонтетикацию, да мало ли что э делал с сокетами.
И так далее по всему тексту на все твои высказывания у меня есть ответы устал тебе возражать и устал по клаве стучать
ПРИМЕРЫ сэр, ПРИМЕРЫ когда будут?
Вот на примерах и продолжим.

[homo ludens]

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

[Ull9]

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

Ну а стобой действительно говорить не очем кроме слов ни одного примера.
да и трепешся ты неряшливо. кроме твоего "удаленного класса" у тебя полно других ляпов. устал я от твоей словесной

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

[Guffy]

в спор Ц и Ц++ влазить не буду
лень, да не люблю я Ц. надеюсь, товарищи в силах сами отбиться, да и буде уже 3е на 1го

а вот по поводу ексепшинов вставлю 5 копеек

я во делаю так

пусть есть Ц++ функция

std::string foo()

и надо ее вызывать из Ц, фортрана и хз знает еще чего
пишеться обертка flat-API

extern C {
 int flat_foo(char* buffer, int capacity){
   if(!buffer)
    return -1;
   try {
      std::string res=foo();
      if(capacity<=res.size())
        return-2;
      strcpy(buffer, res.c_str());
   }
   catch(std::bad_alloc ex)
   {
     return -3;
   }
   catch(...)
   {
     return -4;
   }
   return 0;
 }
}

т.е. пока вы остаетесь в пределах Ц++ - смело руководствуйтесь рекомендациями pal - ловить конкретные екзепшины там где знаете что с ними делать. а ловить для освобождения ресурсов - так я предпочитал смарт-обертки с деструкторами.
когда же вам надо из Ц++ выходить - там и танцуйте с бубном.


ЗЫ: за правильность названий типа std::bad_alloc и т.п. не ручаюсь, по памяти, на Ц++ плотно сидел, да уж больше года на ЦШарп

[lexar]

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

бред это все.
на С в большом проекте можно наделать больше ошибок
только по причине процедурно-ориентированной концепции
и разработка будет тянуться дольше

все течет развивается и меняется
На C#, к примеру, проекты при аналогичной
функциональности продвигаются быстрее чем на С++

А в хвосте прогресса остаются ниши для каждого из языков.
Более узкие, специализированные.

[lexar]

А кому не нравятся эксепшены
возвращайте коды возврата и выставляйте глобальные переменные.
Как в виндах: взял GetLastError и читай себе, что за хреновена у тебя не получилась.

Но это от лукавого.

[homo ludens]

имхо глобальные переменные - абсолютное зло, так как при переводе под мультипоточность вынуждают полностью переписывать код.
Можно потом выкрутиться привязкой глобальных переменных к потоку, но это мазохизм. Лучше сразу писать реентрантный код.

На С# проекты обязательно будут продвигаться быстрее. Когда-то скорость разработки на дельфи и VB уверенно обгоняла С и С++.
Имхо PHP здесь может быть еще лучше.
Просто есть ниша RAD, в которой ни С++ ни С делать нечего по определению - у них другое предназначение.
А спор (пока он не превратился в холивор) я пытался перевести на фундаментальные недостатки дизайна С++ и самое главное - причины их появления (например design by committee - термин Струдструпа). Увы не получилось.
Каждый новый язык кажется лучшим, но потом приходит следующее поколение и споры начинаются опять. Мне кажется, что интересно было бы представить следующее поколение языков и инструментария, то которое еще не появилось и не рекламируется в журналах и не раскручивается производителями.
С моей точки зрения в этом новом мире С++ уйдет и уйдет не как Pascal (сохранив свою нишу), а как COBOL. Т.е. практически полностью. Возможно что я не прав, предсказывать вообще дурацкое занятие, но некоторые основания для таких выводов у меня есть.

PS
In IEEE Computer, February 95, Prof. Wirth labeled C++ as "a language that discourages structured thinking and disciplined programming construction".
(c) http://www.eptacom.net/pubblicazioni/pub_eng/stroustr.html
давно это было...

[THRESHE]

С моей точки зрения в этом новом мире С++ уйдет и уйдет не как Pascal (сохранив свою нишу), а как COBOL. Т.е. практически полностью. Возможно что я не прав, предсказывать вообще дурацкое занятие, но некоторые основания для таких выводов у меня есть.

скорее дурацкое предсказание

и какая ниша у Паскаля интересно ?

[homo ludens]

Паскаль и дельфи долгое время рулил на рынке RAD (Rapid application development) и никакой С и С++ их оттуда вышибить не мог. Время разработки на Дельфи было меньше, чем на С и С++, так же как время разработки на TurboPascal было меньше чем на TurboC во времена 8-дюймовых дисковводов.
Во многом это было обусловлено простым синтаксисом и скоростью компиляции (опять таки из-за простого синтаксиса).
Сейчас Дельфи вытесняеся новыми языками, возможно Сшарп его убьет окончательно, однако количество одесских программеров-дельфинов по прежнему велико и есть фирмы, работающие только на Дельфи.
Так что ниша осталась до сих пор и еще будет какое-то время.
Другой вопрос - куда денутся потом все эти VCL библиотеки написанные годами дельфистами - в канализацию, вслед за tpu?
После фортрана и С остались огромные блоки кода, которые можно юзать в любом языке, после лиспа - алгоритмы с той же универсальностью, а после Дельфи?
И, кстати, что останется от С++ в аналогичной ситуации?

[THRESHE]

Паскаль и дельфи долгое время рулил на рынке RAD (Rapid application development) и никакой С и С++ их оттуда вышибить не мог. Время разработки на Дельфи было меньше, чем на С и С++, так же как время разработки на TurboPascal было меньше чем на TurboC во времена 8-дюймовых дисковводов.
Во многом это было обусловлено простым синтаксисом и скоростью компиляции (опять таки из-за простого синтаксиса).
Сейчас Дельфи вытесняеся новыми языками, возможно Сшарп его убьет окончательно, однако количество одесских программеров-дельфинов по прежнему велико и есть фирмы, работающие только на Дельфи.
Так что ниша осталась до сих пор и еще будет какое-то время.
Другой вопрос - куда денутся потом все эти VCL библиотеки написанные годами дельфистами - в канализацию, вслед за tpu?
После фортрана и С остались огромные блоки кода, которые можно юзать в любом языке, после лиспа - алгоритмы с той же универсальностью, а после Дельфи?
И, кстати, что останется от С++ в аналогичной ситуации?

Я думаю вы намного лучше знаете что С++ это не RAD язык. Так что тут и сравнивать нечего. Понятно что на С# и Java писать можно быстрее, но вот проекты на С++ все равно намного качественней и быстрей (но соответственно и дороже). Так что для серьезных приложений думаю у С++ пока нет конкурентов. И по всей видимости в ближайшее время не будет

[lexar]

После фортрана и С остались огромные блоки кода, которые можно юзать в любом языке, после лиспа - алгоритмы с той же универсальностью, а после Дельфи?
И, кстати, что останется от С++ в аналогичной ситуации?

Куча ActiveX-ов, которые можно юзать даже из HTML

[homo ludens]

Проекты на С++ бывают качественней, бывают быстрее, тут к сожалению много зависит и от архитекторов. Однако в скорости разработки они все-таки проигрывают VM-языкам. Очевидно, что на С++ нет смысла писать вещи, которые должны быть быстро проданы, а есть смысл писать что-то, что требует эффективности. Однако здесь он начинает конкурировать с С плюс к тому, что многие техники С++ не поощряют эффективность.

По поводу постоянно звучащего высказывания о том, что все современные крупные проекты пишутся на С++.
Прикол в том, что два крупных проекта выполненных на С++ обычно на самом деле используют разные языки, между собой плохо совместимые.
Например в стайлинг гайде одного крупного проекта в пункте с 4-х значным номером вы можете найти категорический запрет использования exceptions в любых ситуациях.
А в другом проекте - что-то совершенно другое, например запрет множественного наследования, использования mutable и обязательные виртуальные деструкторы в соответствующих классах.
Наверное все это С++, но один ли это язык на самом деле?
camel is a horse designed by committee (с)
А лишние горбы (explicit или mutable) каждый обтачивает напильником сам.

2 lexar
OCX после VB оставалось куча. И сколько людей сегодня использует тот VB-код?

[THRESHE]

С++ — язык, который изучается постепенно. Лишь после того, как будет сделан последний шаг,
разрозненные приемы и фрагменты синтаксиса начинают складываться в общую картину. По-моему,
изучение С++ чем-то напоминает подъем на лифте.

Дзынь! Второй этаж. С++ — это
усовершенствованный вариант С, с сильной типизацией (которую, впрочем, при желании можно
обойти) и удобными комментариями //. Любой программист на С, если он не хочет подаваться в
менеджеры, должен двигаться дальше… а Бьярн Страуструп (Господи, благослови его) придумал для
этого отличную возможность.

Дзынь! Третий этаж. С++ — хороший, хотя и не потрясающий объектно-ориентированный язык
программирования. Не Smalltalk, конечно, но чего ожидать от языка, работающего с такой
головокружительной скоростью? С++ — это Cobol 90-х, политически выдержанный язык, которые
гарантирует финансирование вашего проекта высшим руководством. А уж если С++ достаточно часто
упоминается в плане, можно надеяться на удвоение бюджета. Это тоже хорошо, потому что никто
толком не умеет оценивать проекты на С++ и управлять ими. А что касается инструментария — глаза
разбегаются, не правда ли?

Дзынь! Последний этаж, все выходят. Но позвольте, где же «все»? Лифт почти пуст. С++ — это на
самом деле не столько язык, сколько инструмент для создания ваших собственных языков. Его
элегантность заключается отнюдь не в простоте (слова С++ и простота режут слух своим явным
противоречием), а в его потенциальных возможностях. За каждой уродливой проблемой прячется
какая-нибудь умная идиома, изящный языковой финт, благодаря которому проблема тает прямо на
глазах. Проблема решается так же элегантно, как это сделал бы настоящий язык типа Smalltalk или
Lisp, но при этом ваш процессор не дымится от напряжения, а на Уолл-Стрит не растут акции
производителей чипов памяти. С++ — вообще не язык. Это мировоззрение или наркотик, меняющий
способ мышления.