C++ haters handbook :-)

[pal]

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

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

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

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

Следующий этап.
vg показал мне все ошибки с ДП которые были при выполнении. Но он не покажет те ошибки которые могут возникнуть. Для того, чтобы он показал нам их мы делаем вот такой трюк. Блок кода (или весь файл) который мы хотим исследовать на потенциальные ошибки ДП мы заключаем в следующие скобки:

#define if(x) if(if_handler(x, __func__,__FILE__,__LINE__))
...
#undef if

Что делает if_handler? Да что угодно. Например если мы дадим return (rand()%2) || x; то получим тестирование методом Монте-Карло. Более практичным является методика, когда эта функция перебирает или генерирует нужные тестовые последовательности, нужные для гарантированного покрытия всего множества возможных ветвлений. Алгоритм давать надеюсь не надо. :- )
После этого гоняем прогу под valgrindom с разными последовательностями, а пока она так гоняется, топчем клаву здесь на форуме. Это пока жители Виллабаджо пишут юнит-тесты и изучают RAII.

ну, это просто не смешно. если у вас есть 1000 условий, приводящих к завершению программы, то сколько раз ее надо запустить, чтобы таким методом пройти дальше всех этих условий и проверить что-то после них ?
я уж не говорю о таком маразме, как во что превратится
int abs ( int a ) {
if(a<0) return -a;
return a;
}
или о том, что это не работает с условиями в выражениях, без оператора if. т.е. return is_error()?false:more_work();

Метод с переопределением if на самом деле не найдет всех ошибок памяти. Для полного перебора надо еще переопредлять malloc - на тот случай если где-то он (или функция которая его вызывает) вернет 0 и проверки этого if-ом нет в коде. Делается по похожей схеме, но уже не макросами, что создает намного больше проблем, но тоже решается.

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

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

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

Вот собственно и обещанный пример...

это просто антипример получился

[pal]

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

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

Вот тот умник, который бросал string, он рассуждал ТОЧНО ТАК ЖЕ КАК ТЫ.
Он говорил, примерно так: Ну я же нигде неписал throw (). Т.е как бы он задокументировал в коде, что бросаю любые обьекты. Так что же вы хотите?
Пишите catch (...)... Вы с ним случаем не в одной школе учились?

ну, он был в праве бросать все, что угодно. но бросать не потомок std::exception - плохой стиль.
я в прошлом посте сказал не бросать, а если бросать, то документировать. в моем примере я _ничего_ не бросаю. бросают std::string и std::vector, остается рассчитывать на их вменяемость. а вы что предлагаете мне делать ?
1 - ловить ... и бросать что-то взамен ? занимайтесь извращениями в main и оставьте в покое мой правильный модуль
2 - ловить ... и ничего не бросать ? а что делать ? возвращать код ошибки ? - пишите на с и не мешайте

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

вызывающий код не на с++ не сможет вызвать ваши функции, т.к. они не объявлены extern "C".

Вполне получится, пишите например new (std::nothrow).

не получится, вся стандартная библиотека бросает исключения. замена стандартной библиотеки не подходит под определение "писать на стандартном с++"

Да но бросая, эксепшн непредупредив, бы лонаете мои ресурсы, мой код становится в неработоспособном состоянии.
И не надо мне говорить, что ненаписав throw(), ты меня предупредил.
из-за такого умника, который меня так "предупредил", код имел уродливый
catch(...). И главное он так и непонял, почему его уволили. все бубнил, что
раз ненаписано throw(), it means alles ok.

lol ?
смотрим в std::string
basic_string(const basic_string& __str);
с аллокатором по умолчанию она точно может бросать std::bad_alloc.
уволить c++ standards committee ?
прошу обратить внимание, у меня такое же объявление и такие же бросаемые исключения.
уволить надо вас, если функция, не объявленная throw() ломает ваши ресурсы, и ваш код становится в неработоспособном состоянии.
а вот у меня не сломалось ни одного ресурса и код работоспособен, и мне совершенно не надо знать, что бросают std::string и std::vector
я думаю, это потому, что я знаю, как надо работать с исключениями в с++

[Ull9]

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

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

откуда мы вообще что-то знаем о _вышестоящем_ модуле ??

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

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

проблемы? подходяще действие, это вызов unexpected затем abort.

ну, он был в праве бросать все, что угодно. но бросать не потомок std::exception - плохой стиль.

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

1 - ловить ... и бросать что-то взамен ? занимайтесь извращениями в main и оставьте в покое мой правильный модуль
2 - ловить ... и ничего не бросать ? а что делать ? возвращать код ошибки ? - пишите на с и не мешайте

Ну вот ты сам же и пишешь (пункт 1), что при твоем "правильном" подходе, как минимум один модуль, ДОЛЖЕН заниматься изврашениями
Теперь пункт 2. В постановке задачи, сказано что делать, возвращать 0. еще раз почитай пример на С. там все четко написано. Я так и зделал. ты - нет. ненадо никакой отсебятины.
В нормальной жизни тебе говорит архитектор, что делать.

вызывающий код не на с++ не сможет вызвать ваши функции, т.к. они не объявлены extern "C".

не получится, вся стандартная библиотека бросает исключения. замена стандартной библиотеки не подходит под определение "писать на стандартном с++"

lol ?
смотрим в std::string
basic_string(const basic_string& __str);
с аллокатором по умолчанию она точно может бросать std::bad_alloc.
уволить c++ standards committee ?
прошу обратить внимание, у меня такое же объявление и такие же бросаемые исключения.
уволить надо вас, если функция, не объявленная throw() ломает ваши ресурсы, и ваш код становится в неработоспособном состоянии.
а вот у меня не сломалось ни одного ресурса и код работоспособен, и мне совершенно не надо знать, что бросают std::string и std::vector
я думаю, это потому, что я знаю, как надо работать с исключениями в с++

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

Удачи

[homo ludens]

счастливы люди пишущие раз за разом программы не сложнее хеллоу ворлд

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

Компилятор должен компилировать. это так, Но если он еще и может отлавливать ошибки логики разве это плохо? Разве плохо, что он поможет предотвратить ошибли бизнесс-логики? Краш? О чем спор? ЗАЧЕМ ОТКАЗЫВАТСЯ ОТ ТОГО ЧТО ДАЕТ БЕСПЛАТНО ЛЮБОЙ КОМПИЛЯТОР С++?

Потому что кроме того, что он дает, он еще много забирает. Например возможности автоматической обработки исходного кода.
Плюс еще много чего.

Теперь по поводу твоего тула. Ну а если нет у меня этого тула? на моей платформе его нет вообще. AIX. И не говори мне про другие тулы. нельзя мне ничего ставить на машину заказчика. Дальше что? Что мне делать с твоими советами?
Надо пользоватся компилятором с++. его вполне хватит чтоб писать правильные проги.

Я сам писал на HPUX, потому завидую хорошему железу и сочуствую плохому софту (блин на моей версии даже threads не было в природе).
Когда ничего нельзя ставить на машину заказчика - у разработчика ставиться аналогичная машина с идентичным софтом и версией ОС вплоть до патчей (кстати, никому не нужна PA-RISC E-шка 10-летней давности? Дома только пыль собирает : -).
Тулза здесь не главное. Тулзу можно сэмулировать malloc hooks либо просто подменой malloc. Хотя это конечно гемор тот еще, плюс большие тормоза в отладке, но это работа одноразовая и на всю жизнь.
Главное здесь возможность синтаксического анализа исходного кода и концентрация анализа ошибок в том блоке, где они возникают. С++ размазывает источник ошибки по всей программе, С- нет.
Опять таки, мой метод упрощен и примитивен. Даже такая софтина как http://opera.cs.uiuc.edu/~zli4/paper/PRMiner.pdf отлавливавшая ошибки в коде ядра Линукс на С++ может на порядки меньше. Хотя никакой тулзы не требует.
С++ не ловит все ошибки, он не может например ловить ошибки рантайма - это может только интерпретатор. Есть рабочий минимум контроля который должен делать компилер - например непонятки в семантике ( ++x=x++ ? --x :x--; : -), есть ошибки которые он должен ловить для программеров, которые пишут прямо на экран, есть ошибки которые возникают при портировании.
Но доращивать его до полноценного ловщика ошибок - глупо, особенно если знать, что это в принципе невозможно. Разумнее написать отдельный полноценный ловщик ошибок, который ловит все. А компилятору оставить компиляторово.

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

Здесь есть внутренне противоречие. Большинство крупных проектов ООП (на С++ , не джава) можно условно разделить на три компоненты - сеть, база и бизнес-логика. При этом первые две компоненты стандартны и только неумный человек будет их писать заново для каждого нового проекта. Говорю так, потому что сам имел глупость этим заниматься.
Бизнес-логика уникальна для каждого проекта.
Баз объектных в природе не существует. Нет в реляционной модели понятия наследования. Также как и полиморфизма. Инкапсуляция возможна через крайне примитивный механизм грантов, но грантами для инкапсуляции пользоваться только мазохист.
Сетевая часть объектная есть - CORBA, еще один мертвец из OMG. Пользоваться им может тоже только мазохист - я например пользовался. Большинство предпочитают хорошо зарекомендовавшие себя сокеты.
В результате получаем странную вещь. Две из трех компоненты, которые стабильны - никогда не пишутся в ООП-стиле. Хотя исходя из элементарной логики - это первое, что должно было бы быть переписано под ООП и разойтись по всему миру. Вам в этом ничего не кажется странным?

[homo ludens]

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

Вы С99 когда послений раз читали?
В С такая проверка не выполняется, а производится обычное преобразование типов. С доверяет программисту и считает, что программист знает что делает.
С++ не выловит всех таких ошибок, он выловит только то, что идет в функции с явным несовпадением типов, но он ничего не скажет, если вы напишете b = abs ( (short)b );. Иесли вы мне возразите - непишите такой код, то я вам отвечу - а вы не пишите такой как у вас. Ни один из методов не дает больше сохранности, просто один говорит программисту, что если ты будешь писать так - то это будет ошибка, а другой метод говорит прямо противоположное. Размер множества потенциальных ошибок не меняется.
Это синтаксический сахар, не более того.
А вот хороший синтаксический парсер + рантайм среда поддержки - выловит гарантированно все.

не более, чем /usr/include/*

Взял какой-то man в котором было написано что abs в algorithm. Очевидно старый или неправильный. Все мои С++ проекты сегодня находятся в поддержке, потому нормальный комплект доки на компе не держу.
С cstdlib действительно оверхед всего в полтора раза, что вполне допустимо и проблемой не является.
Признаю свою ошибку в данном случае. Хотя подозреваю, что если мне придется юзать что-то темплейтное ситуация может измениться в мою сторону.

специально для вас имеется в наличии std::string::append, все остальные могут использовать более интуитивный +

C++'s biggest problem is its size. People will tell you that this is no big deal; just subset C++ down to whatever part of it you're willing to use; that can be a C subset or something a little larger, or the whole thing.

This logic can be used to justify an infinitely complex language, so one should hesitate to accept it at face value.
...
Another significant problem is that it requires an investment of effort to select an appropriate subset. Moreover, you will have difficulty finding books that teach this subset; and, indeed, if you acquire a C++ algorithms book, the odds that the subset chosen for that book matches that of yours is low.

In other words, subsetting is the same as fragmenting the language into lots of separate dialects; it has all the same problems as that, with the added cost of none of those dialects having unique names. What does it mean to say "I've used C++ for six years" on a resume?

http://www.nothings.org/computer/cpp.html
выделено мной.

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

Проблема в том, что в С семантическая близость почти всегда кореллирует с синтаксической близостью. Это означает, что для разбора и понимания блока кода мне кроме этого блока кода практически ниего больше и не надо, кроме может быть прототипов. В С++ семантика размазана по всей программе. Проверка на malloc у меня происходит только там, где она нужна. catch - в любом месте программы. Это означает что любой синтаксический чекер должен читать всю программу у вас, а у меня - только нужный блок и h-файлы. Кроме того, программист - это такой же чекер и yo-yo problem - это его точка зрения на то, что я написал.
Кстати, большинство С-компиляторов не юзают грамматику С в формальном виде, парсер пишется ручками, без yacc/bison. Для С++ это невозможно.

и что, в эти сокеты вставляются grep, sort и т.п. ?

Даже это можно сделать, хотя имхо это мазохизм. Тем не менее, два стандартных интерфейса, которые есть практически в любой базе - socket и shared memory. Второй правда больше для hi-end.

я всего видел две базы данных. mysql написан на с++, postgresql сам себя называет object-relational dbms.

mysql - обычная реляционка. Postgress - часть очень амбициозного проекта (рухнувшего) по приведению БД к ООП. Насколько я помню (могу ошибаться, а гуглить лень) автор Postgress был одним из авторов Второго манифеста, в котором заявлялось, что ООП порвет реляционки как тузик грелку. Результатом стало то, что он возглавил это направление в Информиксе. Я человек невезучий, я как раз писал тогда под Информикс.
До его назначения Информикс входил в тройку ведущих производителей БД вместе с Oracle и Sybase. После - был продан IBM. В самом Postgress ООП реализован на зачаточном уровне и таким увы и останется. Называть его объектным нельзя, даже сам автор его так не называет, его любимое название - постреляционная БД.

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

Читал и "месяц" и "пулю". Кроме того как я уже и рассказывал, автоматическая генерация кода в отдельно взятой предметной области у меня уже реализована. И не только у меня.

не правильный ответ. массив то у вас общий все равно, вот и ставьте ifdef вокруг его элементов

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

т.е. msvc, sunpro и tru64cxx - это все компиляторы под linux или hurd ?

нет, это компиляторы под свои ОС. Кроме них есть еще компиляторы, под них тоже надо портировать... В отличие от libc которая портируется под ОС а не под компилятор. Что я и хотел показать. Портировать библиотеку под компилятор, имхо противоречие в терминах. Тут или компилятор какой-то нестандартный или библиотека очень уж извращенная.

Готов правда признать, что похоже вы правы и живых портов glibc под другие ОС нет. Хотя Posix все равно никто не отменял и на тех системах h-файлы будут отличаться, но интерфейсы должны быть достаточно похожими, чтобы гарантировать портируемость.

[homo ludens]

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

тогда зачем вам проверка ошибок в С++?

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

причем здесь программа? Благодаря изоляции проверок в одном блоке я запускаю только этот блок. Это именно то, чего не получится при try-catch.
Запускаю, не я а скрипт, написанный раз и навсегда.
если у меня функция возвращает не то значение, то это проблема вызывающей функции, которая тестируется отдельно. Нет экспоненциального взрыва.
Концентрация кода против размазывания. Семантическая метрика должна быть максимально близка к синтаксической, иначе приходится вместо работы с участком кода работать со всей программой. Что и происходит в С++.

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

а 1000 условий в одной функции редко когда бывают...

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

[Ull9]

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

Не понял твоего креасноречия, но прошу тебя не надо ничего обьяснять. А то тебя унесет не туда. Это тема все таки программирование.

Потому что кроме того, что он дает, он еще много забирает. Например возможности автоматической обработки исходного кода.
Плюс еще много чего.

А вот здесь, поконкретнее, что забирает с++ компилятор, от с компилятора?

Я сам писал на HPUX, потому завидую хорошему железу и сочуствую плохому софту (блин на моей версии даже threads не было в природе).
Когда ничего нельзя ставить на машину заказчика - у разработчика ставиться аналогичная машина с идентичным софтом и версией ОС вплоть до патчей (кстати, никому не нужна PA-RISC E-шка 10-летней давности?

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

Тулзу можно сэмулировать malloc hooks либо просто подменой malloc. Хотя это конечно гемор тот еще, плюс большие тормоза в отладке, но это работа одноразовая и на всю жизнь.
Главное здесь возможность синтаксического анализа исходного кода и концентрация анализа ошибок в том блоке, где они возникают.

не позволит тебе такой тул поймать ошибку пока через него тред не пройдет.
Понял? А теперь представь, что тебе нужно проверить все if/then/switch/case ветки.
Вот здесь начнется твой геморр. Спасибо, не катит твой подход в реальном мире.

С++ размазывает источник ошибки по всей программе, С- нет.

поясни, я не понял, может мы говорим о разных вещах

Опять таки, мой метод упрощен и примитивен. Даже такая софтина как http://opera.cs.uiuc.edu/~zli4/paper/PRMiner.pdf отлавливавшая ошибки в коде ядра Линукс на С++ может на порядки меньше. Хотя никакой тулзы не требует.
С++ не ловит все ошибки, он не может например ловить ошибки рантайма - это может только интерпретатор.

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


Есть рабочий минимум контроля который должен делать компилер - например непонятки в семантике ( ++x=x++ ? --x :x--; : -), есть ошибки которые он должен ловить для программеров, которые пишут прямо на экран, есть ошибки которые возникают при портировании.
Но доращивать его до полноценного ловщика ошибок - глупо, особенно если знать, что это в принципе невозможно. Разумнее написать отдельный полноценный ловщик ошибок, который ловит все. А компилятору оставить компиляторово.
[/QUOTE]
Нет разумнее не писать ловщик ошибок, а использовать компилятор на все 100%, и здесь с++ выгоднее с. причина та же, ловщик ошибок не покроет весь код при прогонах. во всяком случае это далеко не тривиальная задача. Так зачем это надо?

Здесь есть внутренне противоречие. Большинство крупных проектов ООП (на С++ , не джава) можно условно разделить на три компоненты - сеть, база и бизнес-логика. При этом первые две компоненты стандартны и только неумный человек будет их писать заново для каждого нового проекта. Говорю так, потому что сам имел глупость этим заниматься.
Бизнес-логика уникальна для каждого проекта.
Баз объектных в природе не существует. Нет в реляционной модели понятия наследования. Также как и полиморфизма. Инкапсуляция возможна через крайне примитивный механизм грантов, но грантами для инкапсуляции пользоваться только мазохист.
Сетевая часть объектная есть - CORBA, еще один мертвец из OMG. Пользоваться им может тоже только мазохист - я например пользовался. Большинство предпочитают хорошо зарекомендовавшие себя сокеты.
В результате получаем странную вещь. Две из трех компоненты, которые стабильны - никогда не пишутся в ООП-стиле. Хотя исходя из элементарной логики - это первое, что должно было бы быть переписано под ООП и разойтись по всему миру. Вам в этом ничего не кажется странным?

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

[homo ludens]

не позволит тебе такой тул поймать ошибку пока через него тред не пройдет.
Понял? А теперь представь, что тебе нужно проверить все if/then/switch/case ветки.
Вот здесь начнется твой геморр. Спасибо, не катит твой подход в реальном мире.

так в том то все и дело, что с помощью второго шага (переопределения if) я могу гарантировать обход всех вариантов.
Я не могу так поймать case, не могу поймать ?: но все варианты прохождения программы по if' ам в этом блоке я выловлю.
См. пример.
В реальной жизни я юзаю не препроцессор а перл-скрипт для конверсии сырцов, там case ловится.

поясни, я не понял, может мы говорим о разных вещах

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

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

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

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

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

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

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

В том то и дело, что они писались очень часто. Ни одна из реализаций не живая. Все дохлые. Написать оо-обвертку вокруг сокета можно, а триггеры БД тоже обвертками делать?. оо-вытаскиватель сырых данных из БД - это не оо-БД.
Если мы видим, что из трех компонент ООП- проекта только одна закрытая часть декларируется как ОО, то это наводит на подозрения. Это как выбирать из трех девушек-сестер, две из которых уродины а третья в парандже, но ее родственники говорят, что она красивая. А под паранджу заглянуть не разрешают.

[Ull9]

так в том то все и дело, что с помощью второго шага (переопределения if) я могу гарантировать обход всех вариантов.
Я не могу так поймать case, не могу поймать ?: но все варианты прохождения программы по if' ам в этом блоке я выловлю.
См. пример.
В реальной жизни я юзаю не препроцессор а перл-скрипт для конверсии сырцов, там case ловится.

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

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

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

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

что такое pvc?
что такое убитый класс?
нафик мне нужен синтаксический анализатор если у меня есть с++ компилер?
Конкретно, чем мне поможет синтаксически анализатор, и не поможет компилятор? Пример?

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

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

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

слова.... ПРИМЕР, когда интерпретатор даст больше чем анализ креаш дампа.

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

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

В том то и дело, что они писались очень часто. Ни одна из реализаций не живая. Все дохлые. Написать оо-обвертку вокруг сокета можно, а триггеры БД тоже обвертками делать?. оо-вытаскиватель сырых данных из БД - это не оо-БД.
Если мы видим, что из трех компонент ООП- проекта только одна закрытая часть декларируется как ОО, то это наводит на подозрения. Это как выбирать из трех девушек-сестер, две из которых уродины а третья в парандже, но ее родственники говорят, что она красивая. А под паранджу заглянуть не разрешают.

[/QUOTE]
не говори, прости глупостей, прекрасно все оболочки и вокруг оракла и вокруг сокетов работают. Твое выражение что они дохлые,,, это твое выражение.

Прости пустые слова. и про пример который ты не дал, и о похороненой КОРБЕ, и о мертвых ооп оболочках вокруг БД.
И что в остатке, ты предлагаеш. самому писать какие то ловщики, причем сам же признаешь, что геморр.

И еще я не понял, повторю:
А вот здесь, поконкретнее, что забирает с++ компилятор, от с компилятора?

Примеры сэр, примеры, а то запишите сабя в пустозвоны

[homo ludens]

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

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

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

для отлова неосвобождения/непроверки на ноль динамической памяти в пределах блока мне гарантированно хватает информации в пределах блока. При условии соблюдения зоны ответственности за эту память. Это означает что для каждого куска динамической памяти всегда можно найти минимальный блок между скобками {} где эта память создается и удаляется, либо должна это делать. Информации между этими скобками достаточно для отлова глюка (на С). Для отлова глюка не требуется информация о всех вызываемых внутри блока функциях. Я могу точно получить точку в пределах блока где
а. память удаляется повторно
б. точка где выделялась неосвобожденная память
в. точка где память не проверялась на 0.
Для этого мне не требуются сырцы никаких других блоков. Опять таки на С.

что такое pvc?
что такое убитый класс?
нафик мне нужен синтаксический анализатор если у меня есть с++ компилер?
Конкретно, чем мне поможет синтаксически анализатор, и не поможет компилятор? Пример?

Pure virtual function call
индиректный вызов метода класса уже освобожденного деструктором.
эти вещи на уровне синтаксиса не ловятся, они вообще хз как ловятся. Нафик тебе надо - решай сам. Наверное у тебя компилятор находит все твои ошибки? Тогда откуда ты знаешь что такое креш-дамп?
Пример - сравни вывод splint с выводом С++.

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

Я не говорю о стеке потока. Я говорю об исходном коде. Для локализации проблемы в исходниках С мне нужна лишь небольшая окрестность в области ошибки. В С++ мне нужен весь код.

слова.... ПРИМЕР, когда интерпретатор даст больше чем анализ креаш дампа.

memory leak. Особенно когда он накапливается в системе 24x7x365 - я с этим работал. У меня серваки мной написанные аптаймы по пять лет имеют.
Плюс куча вещей когда структура памяти нарушается а креша нет. Плюс куча вариантов тихих race condition, когда все в порядке, только переменные путаются.

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

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

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

я говорил не про оболочки, а про объектные базы данных и объектно ориентированные сетевые интерфейсы. Напиши что нибудь на CORBA а потом сравни с оо- оболочками вокруг сокетов. ООБД промышленного класса сегодня нет. Не реализуется полиморфизм и наследование на реляционной модели.

Прости пустые слова. и про пример который ты не дал, и о похороненой КОРБЕ, и о мертвых ооп оболочках вокруг БД.
И что в остатке, ты предлагаеш. самому писать какие то ловщики, причем сам же признаешь, что геморр.

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

И еще я не понял, повторю:
А вот здесь, поконкретнее, что забирает с++ компилятор, от с компилятора?

я уже сказал. Локальность кода, позволяющая быстро найти проблему. Простота синтаксиса, позволяющая писать синтаксические анализаторы и чекры. Отсутствие обратной совместимости. Низкое повторное использование кода. Единство языка - нет С++ программистов, есть С++ программисты собственного любимого диалекта-подмножества языка. Ты когда последний раз mutable в коде писал? Ограничения в типизации которые ничего не ограничивают, так как те, кто хочет ее перешагнуть с легкостью перешагивают, а остальных заставляет бороться с компилятором. Усложнение отладки и понимания логики чужого кода прошитого перегрузками. Мертвая привязка библиотек к языку. Общая агрессивность сторонников ООП в сочетании с маниакальным желанием переписать собственную версию всего, что уже давно есть, а если не переписать, то хоть обернуть в ОО-интерфейсы.
C++ is the iMac of computing languages (с)

Примеры сэр, примеры, а то запишите сабя в пустозвоны

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

[Ull9]

я понял что наибольшие проблемы у тебя с....
>>>>
Для других вещей (например выход за границы массива или вызов функции через нулевой указатель) нет. Тем не менее то, что контролирует мой вариант не контролирует (и никогда не будет этого делать) С++.
Если нужен детальный код макросов - могу дать.
<<<<
но всех перечисленных тобою проблем в с++ при правильном дизайне просто нет.
еше раз проблемы с динамической памятью, выход за рамки массива, вызов нулевых указателей. это все решается на уровне кода/компиляции.
для С ты вынужден пиосать доморощеные макросы.

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

>>>>Pure virtual function call
индиректный вызов метода класса уже освобожденного деструктором.
эти вещи на уровне синтаксиса не ловятся, они вообще хз как ловятся. Нафик тебе надо - решай сам. Наверное у тебя компилятор находит все твои ошибки? Тогда откуда ты знаешь что такое креш-дамп?
Пример - сравни вывод splint с выводом С++.
<<<<
ну а разве в С нет виртуальных вызовов? Ты когда нибудь поинтерами на функции пользовался? Это не есть ли прямой аналог виртуальной функции в с++?
Что такое класс освобожденный деструктором? Ты вообще знаесь с++?
В С++ нет возможности класс освобождать! НЕТ! кто тебе сказал такую глупость?
Ты вообще знаешь что такое класс, а что такое обьект? что можно делать с классами, что с обьектами?
Еще раз, при правильном дизайне у меня нет проблем с динамической памятью вообще.
вызовов методов уничтоженных ОБьЕКТОВ (НЕ КЛАССОВ) нет. То что с++ позволяет делаТъ ПРИ ПРАВИЛъНОМ ДИЗАЙНЕ, ты должен писать свои макросы.

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

[pal]

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

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

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

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

проблемы? подходяще действие, это вызов unexpected затем abort.

ну, так если это подходящее действие, то и напрягаться не стОит, верно ?

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

логика очень проста. этот плохой стиль исправляется грепом, в отличие от не exception-safe программы

Ну вот ты сам же и пишешь (пункт 1), что при твоем "правильном" подходе, как минимум один модуль, ДОЛЖЕН заниматься изврашениями

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

Теперь пункт 2. В постановке задачи, сказано что делать, возвращать 0. еще раз почитай пример на С. там все четко написано. Я так и зделал. ты - нет. ненадо никакой отсебятины.

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

В нормальной жизни тебе говорит архитектор, что делать.

как архитектор, я вам говорю: бросаться может любое исключение, если вам надо вызывать .what(), ловите std::exception, если надо просто освобождать ресурсы, ловите ... и пробрасывайте его дальше в неизменном виде.
ловить конкретный тип надо только, если вы знаете, что с ним делать. если в задаче ничего о конкретных типах не сказано, то и ловить их смысла нет.

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

разве философия известных компаний позволяет ломать ресурсы при возникновении исключения ?

[TechInsightJobs]

гы

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

особенно при любви к лонгджампу


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


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


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

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

[Ull9]

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

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

И тут вы правы, что неизвестно кто и как будет вызывать этот код. ничего не сказано об этом. я даже добавлю. НИЧЕГО НЕ СКАЗАНО, ЧТО БУДЕТ С++ ЕГО ВЫЗЫВАТь.
этот код мог вызывать, скажем фортран код. мог? мог. фортран линкуется с С библиотеками? легко.

вот такое тех задание. повторить С код, но на С++.

дале смотрим, итак некая финкция возвращает поинтер. ок? ок
и в случае нехватки памяти возврашается 0.

а теперь посмотрим, что написали вы. что проиcxодит, если нехватит памяти?

А теперь вопрос. ВНИМАНИЕ.
является ли ваш код полностью эквивалентным С коду?
Не нарушили ли вы тех задание?

У вас два варианта ДА и НЕТ, Скажу сразу, если вы говорите НЕТ, я с вами закончу разговор. Если да, то мы продолжим о философии компании где я работаю.

[pal]

Вы С99 когда послений раз читали?

не думаю, что я его вообще читал

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

программист просто очепятался. доверяет программисту с++, а с ему при этом еще и не помогает.

С++ не выловит всех таких ошибок, он выловит только то, что идет в функции с явным несовпадением типов, но он ничего не скажет, если вы напишете b = abs ( (short)b );.

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

Иесли вы мне возразите - непишите такой код, то я вам отвечу - а вы не пишите такой как у вас.

я возражу по другому - используйте static_cast, его грепить проще

Ни один из методов не дает больше сохранности

в приведенном примере с++ дал больше сохранности от глупой ошибки

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

как же не меняется, если с проглатывает все ошибки, а с++ только нетривиальные ?

Это синтаксический сахар, не более того.

теперь compile-time проверки так называются ?

А вот хороший синтаксический парсер + рантайм среда поддержки - выловит гарантированно все.

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

http://www.nothings.org/computer/cpp.html
выделено мной.

мне нравится первый пункт "The Big Mistake: C Compatibility"

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

всю ссылку я не осилил, т.к. автор просто болен

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

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

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

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

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

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

Кроме того, программист - это такой же чекер и yo-yo problem - это его точка зрения на то, что я написал.

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

Кстати, большинство С-компиляторов не юзают грамматику С в формальном виде, парсер пишется ручками, без yacc/bison. Для С++ это невозможно.

вообщето для с++ невозможно как раз обратное, т.к. его грамматика не lalr(1)
и какое это имеет значение ?

Даже это можно сделать, хотя имхо это мазохизм. Тем не менее, два стандартных интерфейса, которые есть практически в любой базе - socket и shared memory. Второй правда больше для hi-end.

и как большие монолитные базы данных вообще относятся к unix-way ? или у вас "есть сокет==unixway" ? в с++ тоже есть сокеты

mysql - обычная реляционка. Postgress - часть очень амбициозного проекта (рухнувшего) по приведению БД к ООП. Насколько я помню (могу ошибаться, а гуглить лень) автор Postgress был одним из авторов Второго манифеста, в котором заявлялось, что ООП порвет реляционки как тузик грелку. Результатом стало то, что он возглавил это направление в Информиксе. Я человек невезучий, я как раз писал тогда под Информикс.
До его назначения Информикс входил в тройку ведущих производителей БД вместе с Oracle и Sybase. После - был продан IBM. В самом Postgress ООП реализован на зачаточном уровне и таким увы и останется. Называть его объектным нельзя, даже сам автор его так не называет, его любимое название - постреляционная БД.

не знаю, как его называет автор (разве у него есть один автор ?), но первая строчка описания пакета "PostgreSQL is an advanced Object-Relational database management system"
я все еще не понимаю, из чего мне делать выводы о недостатках с++

Читал и "месяц" и "пулю". Кроме того как я уже и рассказывал, автоматическая генерация кода в отдельно взятой предметной области у меня уже реализована. И не только у меня.

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

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

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

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

в некоторых случаях достаточно и такого определения

нет, это компиляторы под свои ОС. Кроме них есть еще компиляторы, под них тоже надо портировать... В отличие от libc которая портируется под ОС а не под компилятор. Что я и хотел показать.

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

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

первое. почему для вас новость, что msvc - нестандартный компилятор ?

Готов правда признать, что похоже вы правы и живых портов glibc под другие ОС нет. Хотя Posix все равно никто не отменял и на тех системах h-файлы будут отличаться, но интерфейсы должны быть достаточно похожими, чтобы гарантировать портируемость.

осталось признать, что буст представляет собой документацию интерфейса + reference implementation.

[pal]

тогда зачем вам проверка ошибок в С++?

затем, что проверка на стадии компиляции это как раз и есть "не допускать ошибок" ?

причем здесь программа? Благодаря изоляции проверок в одном блоке я запускаю только этот блок. Это именно то, чего не получится при try-catch. .....

все отлично получится. дальше поскипано, т.к. вообще непонятно, как можно рассуждать о том, может быть 1000 условий или нет ( как будто, если их только 100, то будет легче ), в то же время игнорируя примеры абсолютного маразма с изменением семантики и работоспособности только с операторами if

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

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

[pal]

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

это вы зря

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

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

А теперь вопрос. ВНИМАНИЕ.
является ли ваш код полностью эквивалентным С коду?

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

Не нарушили ли вы тех задание?

нет

Если да, то мы продолжим о философии компании где я работаю.

спасибо, но пока не надо

[Ull9]

спасибо, но пока не надо

так зачем было ерничатъ и спрашивать? привести цитату?

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

Понять его сложно, но почитайте его конкретно пост,
он просит написать код на с++. И здесь ваш код не эквивалентен

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

Ну чтож, значит вы согласны, что код ваш НЕ СЛЕДУЕТ его коду, а значит вы закладывайте серьезную ошибку, если ставить ваш код вместо его кода. что и требовалось доказать.

Ну а теперь к другой теме.

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

например возьмем функцию
void* foo();

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

Конечно можно договорится что бросать, что нет, но это согласитесь совсем другое. а именно с++ не гарантирует проверку типов.
остается что ?
catch (...)?
это уродливо.

Конечно можно писать
void* foo() throw MyException,
НО, язык, не считает ошибкой, если этот throw отсутствует.
налицо неопределенность, это то мне и не нравится.

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

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

[pal]

так зачем было ерничатъ и спрашивать? привести цитату?

вопрос был риторический

Ну чтож, значит вы согласны, что код ваш НЕ СЛЕДУЕТ его коду, а значит вы закладывайте серьезную ошибку, если ставить ваш код вместо его кода. что и требовалось доказать.

дык, никто и не собирался ставить этот код вместо
спор сводился к вопросу "кому легче живется, программистам на с или на с++?"

Ну а теперь к другой теме.

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

например возьмем функцию
void* foo();

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

Конечно можно договорится что бросать, что нет, но это согласитесь совсем другое. а именно с++ не гарантирует проверку типов.
остается что ?
catch (...)?
это уродливо.

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

Конечно можно писать
void* foo() throw MyException,
НО, язык, не считает ошибкой, если этот throw отсутствует.

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

[pal]

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

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