Re[8]: MSVC2010 + C99 - C/C++

Здравствуйте, Alexéy Sudachén, Вы писали:

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

Дык STL -- редкий урод. Это весьма распространённый взгляд. Впрочем, если не страдать и свести использование STL к контейнерам и простейшим алгоритмам, вроде sort и merge, то стоны по неподдерживаемости кода мне не ясны...

AS>От собственно это в реализации STL у меня и вызывает затруднения.
Ну его можно вообще не использовать...

Обычно, когда говорят о "С-подобном подмножестве С++", туда шаблоны не включают, так что STL точно в пролёте...

AS>Причём никакой скрытой логики я в общем-то не добавил.
Ну логики не добавил, а запутанности добавил... Это большой шаг в сторону write-only плюсов от сурового, но справедливого С! бойся, комрад! Программисты уже один раз ошиблись, отойдя от православного FORTRAN в сторону всяких богомерзких MODULA, PASCAL и С... Не повторяй ошибок прошлого! Стойко держись С! И выкини все эти макросы, они делают из твоего С жалкое подобие С++. Истина состоит в том, что автоматический RAII не нужен, а не в том, что путём кучи трюков его можно воспроизвести в С1

AS>С++ же такое сделать в принципе невозможно, в силу концепции языка, а если бы и можно было это пошло бы в разрез с Единственным Истинно Верным Способом Программировать. )))

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

AS>>Причём никакой скрытой логики я в общем-то не добавил.
E>Ну логики не добавил, а запутанности добавил... Это большой шаг в сторону write-only плюсов от сурового, но справедливого С! бойся, комрад! Программисты уже один раз ошиблись, отойдя от православного FORTRAN в сторону всяких богомерзких MODULA, PASCAL и С... Не повторяй ошибок прошлого! Стойко держись С! И выкини все эти макросы, они делают из твоего С жалкое подобие С++. Истина состоит в том, что автоматический RAII не нужен, а не в том, что путём кучи трюков его можно воспроизвести в С1

Аминь, камрад.

AS>>С++ же такое сделать в принципе невозможно, в силу концепции языка, а если бы и можно было это пошло бы в разрез с Единственным Истинно Верным Способом Программировать. )))
E>Тут ты не прав. Как учит самый главный страус-гуру, С++ -- он мультипарадигменный, там нет единственно-верного способа. Это один из его недостатков. Менеджер проекта должен ещё и парадигму выбрать, и как-то отследить, что кодеры ей следуют

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

Здравствуйте, Piko, Вы писали:
P>Конкретно я имею ввиду, что C++ позволяет писать более абстрактный, более безопасный, и более быстрый код — и всё это одновременно.

Но очень мало кто умеет это делать. Кроме того, если вернуться к реальности, то кодер. который хреначит тысячи строк простого С-подобного кода в день и выдаёт приемлемое качество, намного дешевле мегаперца, который вам всё супер-пупер спроектирует и реализует, так, что это будет более абстрактный, безопасный и быстрый код одновременно, и не write-only при этом

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

Здравствуйте, Piko, Вы писали:

P>синтаксический онанизм/не онанизм — это сугубо субъективные оценки, поэтому я и сделал опрос.
AS>>Кстати, показательно что 3 человека язык таки знают.
P>Знают? или просто не считают это синтаксическим онанизмом?

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

То есть мне код вида

void foo()
{
    ResuorcePullState rps = ResuorcePullStart();

    /* тут код, вида */
    MyData* data = ResuorcePullPush( alloc( sizeof( MyData ) * count ) );
    free( ResuorcePullPop( data ) ); /* Это если таки надо, вообще-то не надо обычно */

    /* для ресурсов каких-то других типов пишем как-то так: */
    MyResuorce* dialog = ResourcePullPushExt( LoadResource( ... ), CloseHandle );

    /* ну и в конце пишем как-то так: */
    ResourcePullEnd( rps );
}

намного больше нравится, так как он банально рефакторится в такой:

HRes foo()
{
    ResuorcePullState rps = ResuorcePullStart();

    /* тут код, вида */
    MyData* data = ResuorcePullPush( alloc( sizeof( MyData ) * count ) );
    free( ResuorcePullPop( data ) ); /* Это если таки надо, вообще-то не надо обычно */

    if( что-то не так )
        return ResourcePullEnd( rps ), HRES_SOME_ERROR;

    /* для ресурсов каких-то других типов пишем как-то так: */
    MyResuorce* dialog = ResourcePullPushExt( LoadResource( ... ), CloseHandle );

    /* ну и в конце пишем как-то так: */
    return ResourcePullEnd( rps ), HRES_OK;
}

Ну и в RT можно в каком-нибудь отладочном режиме пула, проверять, что ResourcePullEnd всегда откатывает только одну ResuorcePullStart...

Здравствуйте, Alexéy Sudachén, Вы писали:

AS>Ровно после того как ты выдернешь из STL в отдельный файлик, то что нужно тебе шоб написать аналогичный моему пример.

STL НЕ НУЖЕН!

Здравствуйте, 11molniev, Вы писали:

1>Изначально я и обратил ваше внимание, на то, что С++ не позволяет писать более быстрые приложения, чем С.
1>http://www.rsdn.ru/poll/3562.aspx

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

Здравствуйте, Alexéy Sudachén, Вы писали:

AS>Ну дык, да. У языка нет единственно верного способа, а у каждого, кто его пользует не сильно много лет, точно есть. )))

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

Здравствуйте, Piko, Вы писали:

P>читайте дальше, есть решение без явного отката

Если это про тот __Auto_Release__{ тут код }, то лучше не надо

Здравствуйте, Piko, Вы писали:

P>>>то что цитата в вопросе вырвана из контекста, я уже писал
1>>Ну сделайте голосовалку не вырванную из контекста. Я чем этому мешаю?

P>а смысл? вот буквально ниже:

P>>>итого, мою точку зрения поддерживают 32.5% (даже при "плохой" постановке вопроса)
P>>>и?
1>>Привет им. Мног8ие считают, что питон быстрей всех языков в мире.

P>вы приравниваете людей разделяющих мою точку зрения к баранами

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

P>>>смотрим моё утверждение в этом топике:
1>>Ваше утверждение это самый серьезный пруф, который я только видел.

P>

P>у вас в голове контекст вообще мизерный, что-ли?
Так вы в той ветки так и не смогли написать код на С++, быстрей кода на С.
Ваше аргументы это некорректный тест (в корректном мы с вами скорости кода на С и С++ сравняли) и ваше собственное утверждение, которое вы повторяете от сообщения к сообщению.
И после этого замолчали на долгое время.

P>>>http://www.rsdn.ru/forum/cpp/4731645.aspx
P>>>

P>>>Это распространённое заблуждение, что код на C более быстр и менее требователен. Если важна эффективность, C++ легко позволяет писать более оптимальные программы чем C.

P>>>что вам не ясно-то?
1>>Мне не ясно, почему вы ~~не думаете головой.~~ пытаетесь противоречить фактам.
P>каким фактам?
1. Любой код на С++ представим эквивалентным кодом на С.
2. Код на С++ и эквивалентный на С при компиляции дадут идентичный машинный код (если вы знаете, что это).
3. Идентичный машинный код имеет идентичную скорость.

По поводу первого факта: вспоминайте декорирование функций при линковке, cfront & co.

P>

P>Ну так там где в C возможно compile-time, оно возможно и в C++, причём в C++ — оно может достигается намного легче/лучше/красивее, а может намного тяжелее/хуже/уродливей

P>Вы с этим согласны/не согласны?
Да, с исправленным мной согласен.
Что это за дурь? Намного лучше — идеальный инструмент.

P>>>вы хотели подтвердить моё высказывание своим опросом?
1>>Что 2/3 посетителей этого форума с вами совсем не согласны.

P>ну и?:
P>

P>Это распространённое заблуждение, что код на C более быстр и менее требователен. Если важна эффективность, C++ легко позволяет писать более оптимальные программы чем C.

Вы повторяете это как мантру только на этом форуме, каждое сообщение, или в жизне тоже? Я не хочу вас обидеть, но ИМХО: у вас нет опыта практической работы. А информацию о распространеном заблуждении вы почерпнули из книжки/лекций/форумов.

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

Здравствуйте, org_256, Вы писали:

_>1. Большую часть времени я пишу для платформы с большим ограничением по пространству-времени. ( робототехника )
Что за процессоры/операционки? В смысле, есть ли там нормальные С++ кросс-компиляторы вообще?
Я так понимаю, что не кросс-компилер С++, в виду чахлости платформы малореален?

_>2. При написании игр долгое время приходилось поддерживать огромное число "слабых" машин. ( и да! можете убить меня, я пишу на голом WinAPI )
Тут не понятно, чем С++ хуже С. Ну рантайм библиотека чуть больше, конечно, но это же мелочь...

_>5. В большинстве моих проектов и задач использование С++ равносильно "стрельбе из пушки по воробьям".
Это тоже не понятно. Ты хуже знаешь С++? У тебя плохая IDE/компилятор/отладчик/что-то ещё из среды разработки для С++? Чем С-подобное подмножество С++ более пушка, чем С?

_>10. Аргументны типа: можно писать Cи-like коде в самом C++ — тоже не аргумент, довелось работать в таких проектах. Половина кода на кривом С++, половина на Си, большая часть кода — вообще сторонние библиотеки на С++ со своей, невообразимой семантикой. В результате куча костылей, граблей и прочей фигни.

Ну так можно использовать только кошерные С-библиотеки. Хотя, IMHO, есть кривые библиотеки и прямые. Надо не использовать первые и использовать вторые, подмножество С++ в этом плане, казалось бы, даёт БОЛЬШЕ возможностей, а не меньше...

_>12. Вся RMOS ( моя система для экспериментальных роботов-манипуляторов ) написана на С99. Далее LCC->AT89C51. ( лицензия есть ).

Про "далее" не понял, но как факт того, что RMOS написана на С99 помогает сравнить с-подобное подмножество С++ и С?

Скажем, если ты пересоберёшь RMOS, как С++ проект, то что будет?

Пока что я понял так, что есть три более или менее понятных мне аргумента.

1) С чисто С-проектом проще управляться менеджеру. Проще следить за кодерами, проще верефицировать соблюдение инструкций, проще набирать персонал и т. д...
И даже если проект делается одним человеком, управлять им всё равно проще. Типа бери и пиши, и не надо парится над кодестилями и допустимыми и нет средствами языка

2) Библиотеки для С в среднем лучше. Правда мне не ясно, что мешает юзать их же из подмножества С++

и 3) должен содержаться в ответе на это:

_>4. Я использую и С++ как вариант подмножества Си в нём, почти не загружая код архитектурными излишествами, но часто сталкивался с кривой реализацией, и не возможностью поддерживать "чистый" Си ( без серьёзного допила )...
Очень интересно посмотреть конкретные примеры, хотя бы описания ситуаций.

То, что код без излишеств -- это хорошо в любом языке

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, 11molniev, Вы писали:

1>>Изначально я и обратил ваше внимание, на то, что С++ не позволяет писать более быстрые приложения, чем С.
1>>http://www.rsdn.ru/poll/3562.aspx

E>Вопрос не в принципиальной возможности, а в цене разработки. Иногда цена столь велика, что является запретительной...

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

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

Здравствуйте, 11molniev, Вы писали:

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

Не понимаю, в чём тут отличие С и С++ даже, а не С и С-подобного подмножества С++

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

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

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

Плохо, что мало есть средств автоматического ограничения С++ таким образом.

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

Но такого рода инструментов в С++ вообще нет...

1>Если уж совсем грубо, то плюсы можно сравнить с архиватором — сжатие (улучшение параметров) зависит от контента и результат может оказаться больше оригинала (при этом ещё и время на распаковку будет тратиться).

Ну так это только при бездумном использовании инструмента. Причём любого. В микроскоп прекрасно видно бактерии, но орехи им колоть неудобно, а соседское окно, так и вовсе не видно...

Здравствуйте, Erop, Вы писали:

P>>смотря где препроцессор отработает..
E>А есть варианты

E>Как, по твоему, С будет транслировать С++ хедеры?..

естественно, а к чему тогда вопрос про макрос assert?

P>>>>1. надёжность
E>>>Не очевидно.
P>>меньше скрытых багов выявленных системой типов во время компиляции, отсутствие возможности сделать целые классы ошибок в принципе и т.п.
E>Ну так это, С + анализатор же рассматривается?..

анализатор может поймать хотя бы 10% того, что ловится в C++ compile-time?

P>>>>2. безопасность
E>>>Это не понятно.

P>>да хотя бы сколько было уязвимостей из-за sprintf
E>Просто системного С++ кода мало, вот и уязвимостей мало

E>Опять же, анализаторы кода простые косяки, вроде ловят...

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

P>>на любом языке

P>>да на том же C — в qsort: абстрагировались от типа данных и функции сравнения — и что получили?
E>ну просела немного производительность...
E>Было бы критично -- написали бы макрос...

P>>разумеется в цене. если цена это на порядок, а то и на несколько больший объём кода, то зачастую она не платится

E>Значит скорость в этом месте не так уж и нужна...
E>Узких мест обычно мало...

P>>опять: std::sort vs qsort
E>Да пофигу. Это редко влияет на скорость реальных программ...
E>А если уж в твоей проге критична какая-то сортировка, то всё равно скорее всего надо алгоритм адаптировать...

ну вот пример:
http://eigen.tuxfamily.org/index.php?title=Main_Page
чтобы реализовать тоже самое на C, понадобится раз в 100 больше кода

P>>>>5. причём всё это, порождает меньше исходного кода чем C
E>>>Тоже ценность мутная.
P>>опять: std::sort vs qsort, самый простой пример.
E>Он слишком синтетический...

Почему синтетический? реальный пример, из реальных библиотек

Итак, в C++ мы получили более надёжный, безопасный, быстрый, код с меньшим объёмом, так?

E>Кроме того, чисто IMHO, шаблоны и STL в обсуждаемое подмножество С++ не входят

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

E>Я, кстати, тоже сторонник "подмножества С++", а не голого С, но аргументы слабые какие-то...

ну я хз, что ещё вам нужно.

Здравствуйте, Erop, Вы писали:

P>>Конкретно я имею ввиду, что C++ позволяет писать более абстрактный, более безопасный, и более быстрый код — и всё это одновременно.
E>Но очень мало кто умеет это делать. Кроме того, если вернуться к реальности, то кодер. который хреначит тысячи строк простого С-подобного кода в день и выдаёт приемлемое качество, намного дешевле мегаперца, который вам всё супер-пупер спроектирует и реализует, так, что это будет более абстрактный, безопасный и быстрый код одновременно, и не write-only при этом

я согласен, то что хороших C++ программистов мало:
http://www.rsdn.ru/forum/cpp/4785102.1.aspx

плохих C++ программистов много — я не спорю, может даже больше чем (относительно, в процентах) плохих C программистов — и это действительно печалька. И это кстати во многом из-за того, что эти плохие программисты C++ получаются из-за C бэкграунда, или C-style обучения.
Но мы ведь здесь говорим не о плохих, не так ли?

Так вот, сравните код http://www2.research.att.com/~bs/new_learning.pdf из второй главы "Complexity", что легче поддерживать?
даже нет, что легче написать?

а на счёт скорости разработки — сколько времени этот средний программист C убьёт на отладку?

E>Кстати, то, что код более абстрактный, часто не является ценностью. Ценностью является естественность выражения бизнес-логики в реалиях программы и кода

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

Здравствуйте, 11molniev, Вы писали:

P>>>>то что цитата в вопросе вырвана из контекста, я уже писал
1>>>Ну сделайте голосовалку не вырванную из контекста. Я чем этому мешаю?
P>>а смысл? вот буквально ниже:
P>>>>итого, мою точку зрения поддерживают 32.5% (даже при "плохой" постановке вопроса)
P>>>>и?
1>>>Привет им. Мног8ие считают, что питон быстрей всех языков в мире.
P>>вы приравниваете людей разделяющих мою точку зрения к баранами

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

то есть 67.5% имеют значительный опыт и знание, а 32.5% это бараны?

Здравствуйте, 11molniev, Вы писали:

P>>>>смотрим моё утверждение в этом топике:
1>>>Ваше утверждение это самый серьезный пруф, который я только видел.
P>>

P>>у вас в голове контекст вообще мизерный, что-ли?
1>Так вы в той ветки так и не смогли написать код на С++, быстрей кода на С.

вам уже объясняли, и не только я:
http://www.rsdn.ru/forum/cpp/4735187.1.aspx

1>> P>Так что быстрее? std::sort (C++ style) vs qsort (C-style) ?
1>> Они идентичны, если речь идёт о стандарте, Если не стандарт, то некоторые
1>> реализации qsort сливают.

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

MZ>Конечно, С-шный код в принципе тоже может это соптимизнуть,
MZ>но только это должен быть ОЧЕНЬ умный компилятор.

а теперь конкретно про тот пример, сколько кода добавится в вашем случае если нужно отсортировать ещё float'ы, double'ы, несколько структур? И сколько в случае C++?

P>>>>http://www.rsdn.ru/forum/cpp/4731645.aspx
P>>>>

P>>>>Это распространённое заблуждение, что код на C более быстр и менее требователен. Если важна эффективность, C++ легко позволяет писать более оптимальные программы чем C.

P>>>>что вам не ясно-то?
1>>>Мне не ясно, почему вы ~~не думаете головой.~~ пытаетесь противоречить фактам.
P>>каким фактам?
1>1. Любой код на С++ представим эквивалентным кодом на С.
1>2. Код на С++ и эквивалентный на С при компиляции дадут идентичный машинный код (если вы знаете, что это).
1>3. Идентичный машинный код имеет идентичную скорость.

4. эквивалентный код на C может быть в 10/100/1000 раз больше, и зачастую не пишется

P>>

P>>Ну так там где в C возможно compile-time, оно возможно и в C++, причём в C++ — оно может достигается намного легче/лучше/красивее

P>>Вы с этим согласны/не согласны?
1>Да, с исправленным мной согласен.

вы исправили мой текст, facepalm..

"а может намного тяжелее/хуже/уродливей"
как оно вообще может достигаться уродливей, если C по большей части является подмножеством C++ ?

P>>>>вы хотели подтвердить моё высказывание своим опросом?
1>>>Что 2/3 посетителей этого форума с вами совсем не согласны.

P>>ну и?:
P>>

P>>Это распространённое заблуждение, что код на C более быстр и менее требователен. Если важна эффективность, C++ легко позволяет писать более оптимальные программы чем C.

1>Вы повторяете это как мантру только на этом форуме, каждое сообщение, или в жизне тоже? Я не хочу вас обидеть, но ИМХО: у вас нет опыта практической работы. А информацию о распространеном заблуждении вы почерпнули из книжки/лекций/форумов.

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

на ваше имхо, могу ответить "аналогичным" своим: вы вообще не написали строчки кода C++

и к чему это?

1>PS. Либо аргументируйте свою позицию, либо спорьте ещё с кем то. Меня аргументы, что это распространенное заблуждение совсем не впечатляют.

"распространённое заблуждение" — это пояснение к результатам голосования

Здравствуйте, Erop, Вы писали:

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

E>Но такого рода инструментов в С++ вообще нет...

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

1>>Если уж совсем грубо, то плюсы можно сравнить с архиватором — сжатие (улучшение параметров) зависит от контента и результат может оказаться больше оригинала (при этом ещё и время на распаковку будет тратиться).
E>Ну так это только при бездумном использовании инструмента. Причём любого. В микроскоп прекрасно видно бактерии, но орехи им колоть неудобно, а соседское окно, так и вовсе не видно...

Здравствуйте, Piko, Вы писали:

P>анализатор может поймать хотя бы 10% того, что ловится в C++ compile-time?
AFAIK, намного больше. Например анализаторы ловят большинство багов в использовании printf и компании

P>вы прочитали статью? в каком случае уязвимости более вероятны?
P>вы считаете примеры надуманны?
Я считаю, что автор несколько однобоко смотрит на проблему.

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

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

P>ну вот пример:
P>http://eigen.tuxfamily.org/index.php?title=Main_Page
P>чтобы реализовать тоже самое на C, понадобится раз в 100 больше кода

Чушь прекрасные библиотеки линейной алгебры были уже на FORTRAN...

Просто на С и на полноценном С++ библиотеки проектируют по разному.

Я уже не говорю про то, что eigen выходит далеко за рамки "С подобного подмножества С++"...

Так что это вообще офтопик, как и std::sort vs qsort

P>Почему синтетический? реальный пример, из реальных библиотек

P>Итак, в C++ мы получили более надёжный, безопасный, быстрый, код с меньшим объёмом, так?

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

P>это почему не входят? может ещё STL выкинем?
P>даже без "мета"программирования у шаблонов большая область применимости

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

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

P>ну реально подмножество С++ + тесты не особо лучше С + анализатор + тесты...

Такой вот вывод. Лучше, но в мелочах. А в чём-то хуже может быть.

Здравствуйте, Piko, Вы писали:

P>а на счёт скорости разработки — сколько времени этот средний программист C убьёт на отладку?
Не факт, что больше, чем С++...

У С-шника будет больше строчек, зато ошибки все будут простые, а у С++ника строчек булет меньше, зато ошибки будут заковыристее...

P>а как вы выразите бизнес логику без абстракций? Как на C, вы выразите сложение двух разряженный матриц?

AddBlaBlaBlaMatrix( &matrix1, &matrix2 );

P>А как вы делаете большие и средние проекты, если без абстракций? Каждый уровень абстракции увеличивает на порядок то, что можно выразить

С уровням абстракции вроде как не мешает... Вообще, уровни абстракции -- это скорее к голове архитектора, а не к языку...

Здравствуйте, Erop, Вы писали:

P>>анализатор может поймать хотя бы 10% того, что ловится в C++ compile-time?
E>AFAIK, намного больше.

я

E>Например анализаторы ловят большинство багов в использовании printf и компании

да ловят, видел.
что на счёт преобразований от void* ?

P>>вы прочитали статью? в каком случае уязвимости более вероятны?
P>>вы считаете примеры надуманны?
E>Я считаю, что автор несколько однобоко смотрит на проблему.

E>Реальность такова, что если хочешь безопасности, то код надо целенаправленно безопасно писать, и потом ломать для проверки, просто выбором языка безопасность не получишь...

да, просто выбором не получишь — надо правильно готовить.
Но, разве по вашему мнению C++ не позволяет писать более безопасные программы легче?

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

P>>ну вот пример:
P>>http://eigen.tuxfamily.org/index.php?title=Main_Page
P>>чтобы реализовать тоже самое на C, понадобится раз в 100 больше кода

E>Чушь прекрасные библиотеки линейной алгебры были уже на FORTRAN...

да, да, знаю такое мнение.

http://www.osl.iu.edu/publications/prints/1998/siek98%3A_siamoo.pdf

Because of the code reuse provided by generic programming, MTL has an order of magnitude fewer lines of code than the Netlib Fortran BLAS [20] | while providing much greater functionality and achieving signicantly better performance. The MTL has 8,284
lines of code for its algorithms and 6,900 lines of code for its dense containers, while the Fortran BLAS total 154,495 lines of code. High performance versions of the BLAS (with which MTL is competitive) are even more verbose.

если надо, ещё подобных примеров приведу.

какова цена этих прекрасных библиотек на Fortran?

E>Просто на С и на полноценном С++ библиотеки проектируют по разному.

естественно

E>Я уже не говорю про то, что eigen выходит далеко за рамки "С подобного подмножества С++"...

а я говорю про С++, а не про его подмножество.

E>Так что это вообще офтопик, как и std::sort vs qsort

почему? очень яркий пример

P>>Почему синтетический? реальный пример, из реальных библиотек

P>>Итак, в C++ мы получили более надёжный, безопасный, быстрый, код с меньшим объёмом, так?

E>Нет, не так. Если рассматривать всё в целом, то он нифига не обязательно ни более быстрый, ни более надёжный, ни с меньшим объёмом.

нет, ну вот опять std::sort vs qsort, разве не так?

E>Но я считаю, что это проблемы не всего С++, а конкретно STL.

какие проблемы?

P>>это почему не входят? может ещё STL выкинем?
P>>даже без "мета"программирования у шаблонов большая область применимости

E>Ну ты сам, вроде как, поставил вопрос так, что не понимаешь, почему вместо С не используют некое подмножество С++...

где? и какой там контекст был?

E>Конкретно шаблоны плохи тем, что не дают вообще никаких гарантий работоспособности программы. Поэтому я бы в надёжном кодеих избегал бы, например. Ну, быть может, кроме самых-самых нужных/проверенных...

каких гарантий нет в std::sort? в std::vector?

P>>ну реально подмножество С++ + тесты не особо лучше С + анализатор + тесты...
E>Такой вот вывод. Лучше, но в мелочах. А в чём-то хуже может быть.

выделенное вроде я не говорил

	От:	Erop
	Дата:	21.06.12 04:49
	Оценка:

	От:	Alexéy Sudachén
	Дата:	21.06.12 04:58
	Оценка:

	От:	Erop
	Дата:	21.06.12 05:22
	Оценка:	1 (1)

	От:	Erop
	Дата:	21.06.12 05:56
	Оценка:

	От:	Erop
	Дата:	21.06.12 05:57
	Оценка: