Здравствуйте, org_256, Вы писали:
_>Если вы действительно просто желаете спорить, или убедить меня в чем-то ( подозреваю собака тут покопалась ), то боюсь к сожалению вам придется указать мне успешные конкурентноспособные ОС преимущественно ядро которых написано на С++... если таких нет, какой смысл дальше препираться?
scmrtos — собственно не ОС, а только шедулер. Можно рассматривать как ядро ОС.
Вполне себе конкурентносособная на 8-битниках и младших 32-битниках
P>А зачем вообще может понадобится использовать C, когда есть C++ ?
В С99 есть киллер фича — динамические массивы. Сразу, пока меня не ткнули в вектор — их можно создавать на стеке, и тогда они
а. быстрее
б. не приводят к фрагментации памяти.
Кроме того, С компилятор не делает манглинга — что очень важно, если пишешь бинарную библиотеку.
И наконец, сообщения об ошибках от С компилятора, как правило, в разы более вменяемые.
В остальном для компиляции С кода можно использовать компилятор С++ — бинарник, который он будет делать, гарантированно не будет хуже, чем тот, который бы произвел С компилятор на том же самом исходнике.
Здравствуйте, Vamp, Вы писали:
P>>А зачем вообще может понадобится использовать C, когда есть C++ ? V>В С99 есть киллер фича — динамические массивы. Сразу, пока меня не ткнули в вектор — их можно создавать на стеке, и тогда они V>а. быстрее V>б. не приводят к фрагментации памяти.
в. выедают stack
V>Кроме того, С компилятор не делает манглинга — что очень важно, если пишешь бинарную библиотеку.
extern "C"
V>И наконец, сообщения об ошибках от С компилятора, как правило, в разы более вменяемые.
не сравнивал. недавно открыл для себя clang — улётная штука
V>В остальном для компиляции С кода можно использовать компилятор С++ — бинарник, который он будет делать, гарантированно не будет хуже, чем тот, который бы произвел С компилятор на том же самом исходнике.
V>>В С99 есть киллер фича — динамические массивы. V>>а. быстрее V>>б. не приводят к фрагментации памяти. P>в. выедают stack
Это не обязательно проблема — например, если такой массив используется в многократно вызываемой фунцкции. Стек все равно освобождается в ее конце.
Кстати, есть еще один пункт, про который я забыл — их можно использовать в обработчиках сигналов.
V>>Кроме того, С компилятор не делает манглинга — что очень важно, если пишешь бинарную библиотеку. P>extern "C"
Не помогает . Полностью манглинг это не убирает. Не пробовал что ли, никогда? Чтобы не было манглинга, надо колдовать с опциями компилятора (gcc) или сочинять .def файл (виндоус).
V>>И наконец, сообщения об ошибках от С компилятора, как правило, в разы более вменяемые. P>не сравнивал. недавно открыл для себя clang — улётная штука
Clang, говорят, крутой. Но в продакшн я не слышал, чтобы кто-то его использовал. А разница в диагностике выглядит примерно так:
int foo(int k) { return k; }
int main() {
double* p;
foo(); // missing parameter
p(); //calling something which is not a function
foo(p); // improper usagechar (*f)(int) = foo; // function mismatch
}
С++:
"test_error.cpp", line 5: Error: Too few arguments in call to "foo(int)".
"test_error.cpp", line 6: Error: Only a function may be called.
"test_error.cpp", line 7: Error: Formal argument k of type int in call to foo(int) is being passed double*.
"test_error.cpp", line 8: Error: Cannot use int(*)(int) to initialize char(*)(int).
С:
"test_error.c", line 5: prototype mismatch: 0 args passed, 1 expected
"test_error.c", line 6: function designator is not of function type
"test_error.c", line 7: warning: improper pointer/integer combination: arg #1
"test_error1.c", line 8: warning: assignment type mismatch:
pointer to function(int) returning char "=" pointer to function(int) returning int
Сравниваем:
Строка 5 — сишный компилятор четко говорит, сколько должно быть аргументов, и сколько передано. Плюсовый — просто ругается. Когда аргумент один, это не важно. А вот если их 10...
Строка 6. Плюсовый просто врет — не только функцию можно вызывать! Сишный четко говорит. Но вобщем-то, здесь ничья.
Строка 7. Компилятор подсказывает, какой именно аргумент не такой в твоем вызове, а не заставляет тебя лезть в объявление функции, чтобы смотреть, что там k. Особенно увлекательно при использовании всяких смешных имен с подчеркиваниями.
Строка 8. Ну тут и комментировать нечего.
V>>>В С99 есть киллер фича — динамические массивы. V>>>а. быстрее V>>>б. не приводят к фрагментации памяти. P>>в. выедают stack V>Это не обязательно проблема — например, если такой массив используется в многократно вызываемой фунцкции. Стек все равно освобождается в ее конце.
ну естественно — это же стэк.
проблемы могут начаться, при относительно большом количестве вложенных вызовов.
V>>>Кроме того, С компилятор не делает манглинга — что очень важно, если пишешь бинарную библиотеку. P>>extern "C" V>Не помогает . Полностью манглинг это не убирает. Не пробовал что ли, никогда? Чтобы не было манглинга, надо колдовать с опциями компилятора (gcc) или сочинять .def файл (виндоус).
естественно, что полностью не уберёт, так как в С++ есть перегрузка функций(для каждой должно быть своё имя) и т.п.
но ничто не мешает для С++ библиотеки, делать полностью clean-C интерфейс.
V>>>И наконец, сообщения об ошибках от С компилятора, как правило, в разы более вменяемые. P>>не сравнивал. недавно открыл для себя clang — улётная штука V>Clang, говорят, крутой. Но в продакшн я не слышал, чтобы кто-то его использовал.
Clang можно использовать только для диагностики, без поставки собраных им бинарников.
V>А разница в диагностике выглядит примерно так:
а что за компиляторы?
вот вывод clang (в консоли, он ещё раскрашивает сообщения)
C:
errt.c:5:9: error: too few arguments to function call, expected 1, have 0
foo(); // missing parameter
~~~ ^
errt.c:1:1: note: 'foo' declared here
int foo(int k) { return k; }
^
errt.c:6:6: error: called object type 'double *' is not a function or function pointer
p(); //calling something which is not a function
~^
errt.c:7:9: warning: incompatible pointer to integer conversion passing 'double *' to parameter of type 'int' [-Wint-conversion]
foo(p); // improper usage
^
errt.c:1:13: note: passing argument to parameter 'k' here
int foo(int k) { return k; }
^
errt.c:8:12: warning: incompatible pointer types initializing 'char (*)(int)' with an expression of type 'int (int)' [-Wincompatible-pointer-types]
char (*f)(int) = foo; // function mismatch
^ ~~~
2 warnings and 2 errors generated.
C++
errt.cpp:5:5: error: no matching function for call to 'foo'
foo(); // missing parameter
^~~
errt.cpp:1:5: note: candidate function not viable: requires 1 argument, but 0 were provided
int foo(int k) { return k; }
^
errt.cpp:6:6: error: called object type 'double *' is not a function or function pointer
p(); //calling something which is not a function
~^
errt.cpp:7:5: error: no matching function for call to 'foo'
foo(p); // improper usage
^~~
errt.cpp:1:5: note: candidate function not viable: no known conversion from 'double *' to 'int' for 1st argument; dereference the argument with *
int foo(int k) { return k; }
^
errt.cpp:8:12: error: cannot initialize a variable of type 'char (*)(int)' with an lvalue of type 'int (int)': different return type ('char' vs 'int')
char (*f)(int) = foo; // function mismatch
^ ~~~
4 errors generated.
Здравствуйте, Piko, Вы писали:
P>Здравствуйте, org_256, Вы писали: _>>1. Большую часть времени я пишу для платформы с большим ограничением по пространству-времени. ( робототехника ) P>Это распространённое заблуждение, что код на C более быстр и менее требователен. Если важна эффективность, C++ легко позволяет писать более оптимальные программы чем C.
Вы можите аргументировать, почему С++ позволяет писать более оптимальные программы? Равные — безусловно. При равном объеме кода — тоже. Но в общем случае "более", звучит довольно странно.
_>>7. Если бы все мои задачи требовали быстрого решения и реализации и не были бы требовательны к скорости выполнения и размерам кода, то да, я бы стал использовать С++ постоянно, даже не смотря на то, что этот язык просто чисто физически не возможно выучить на все 100%. P>даже выучив 50% C++, вы сможете делать более быстрые программы чем на C, либо более компактные чем на C (вообще одновременно максимальная компактность и максимальная скорость почти никогда не достигаются одновременно, в том числе и на C)
Вопрос к пункту один.
_>>8. Аргументы вроде: на современных машинах вызов через один указатель или через указатель на на таблицу указателей не имеет значения, потому что скорость на современных машинах ничтожна мала и не ощутима даже в супер-пупер-тестах... — для меня не аргумент... P>При чём тут вызов через указатель? P>Там где необходимо сделать runtime decision в C++, его также необходимо сделать и в C. P>Compile-time decision конечно быстрее чем runtime decision, но никто вас не заставляет делать runtime decision, где возможно compile-time. И кстати, C++ предоставляет намного более богатые возможности для реализации compile-time decision. P>Ярким примером является сравнение std::sort (C++ style) vs qsort (C-style) — как вы думаете, что быстрее? P>В std::sort как раз compile-time decision, а в qsort — runtime decision. P>http://www2.research.att.com/~bs/new_learning.pdf P>http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Keynote-Bjarne-Stroustrup-Cpp11-Style
Дык кто ж пользуется этой qsort? Я о ней вообще узнал только после двух лет программирования на Си)) А если сравнивать std::sort с сортировкой написанной под конкретную задачу — выигрывает последняя. За счет проигрыша в объеме кода.
_>>9. Аргументы вроде: На Си глобалы, код-лапша, легко насрать куда не нужно, что провоцирует трудновылавливаемые баги — тоже не аргументы. Баги есть даже в релизном коде многих успешных продуктов. P>какие-то детские рассуждения. P>То что баги есть во многих успешных проектах, ни капли не аргумент против того, что C++ позволяет писать программы с меньшим количеством багов (а значит быстрее). P>При грамотном использовании C++ позволяет находить многие баги при компиляции, либо не делать их вовсе (по сравнению с C). Да, все делают ошибки, но при грамотном использовании C++ позволяет делать меньше багов чем C.
В целом согласен, но грамотное использование чистого Си тоже позволяет обходиться без ошибок (но по сравнению С++ будет больше кода).
_>>12. Вся RMOS ( моя система для экспериментальных роботов-манипуляторов ) написана на С99. Далее LCC->AT89C51. ( лицензия есть ). P>Как я писал ранее — отсутствие компилятора действительно может затруднять использование С++, но как я уже писал есть компиляторы транслирующие код C++ в код C.
Иногда транслируют так, что как раз отсутствие компилятора С++ это аргумент его не использовать)) Ну во всяком случае так раньше было, может сейчас уже проще.
Здравствуйте, 11molniev, Вы писали:
_>>>1. Большую часть времени я пишу для платформы с большим ограничением по пространству-времени. ( робототехника ) P>>Это распространённое заблуждение, что код на C более быстр и менее требователен. Если важна эффективность, C++ легко позволяет писать более оптимальные программы чем C. 1>Вы можите аргументировать, почему С++ позволяет писать более оптимальные программы? Равные — безусловно. При равном объеме кода — тоже. Но в общем случае "более", звучит довольно странно.
пример qsort vs sort.
В qsort — runtime decision, в sort — compile-time, отсюда и скорость. И это не единственный пример.
_>>>7. Если бы все мои задачи требовали быстрого решения и реализации и не были бы требовательны к скорости выполнения и размерам кода, то да, я бы стал использовать С++ постоянно, даже не смотря на то, что этот язык просто чисто физически не возможно выучить на все 100%. P>>даже выучив 50% C++, вы сможете делать более быстрые программы чем на C, либо более компактные чем на C (вообще одновременно максимальная компактность и максимальная скорость почти никогда не достигаются одновременно, в том числе и на C) 1>Вопрос к пункту один.
ну так я не говорил что всегда одновременно получается достигнуть и скорость и компактность. либо то, либо другое, причём на C++ обе цели (по отдельности) достигаются легче чем на C.
_>>>8. Аргументы вроде: на современных машинах вызов через один указатель или через указатель на на таблицу указателей не имеет значения, потому что скорость на современных машинах ничтожна мала и не ощутима даже в супер-пупер-тестах... — для меня не аргумент... P>>При чём тут вызов через указатель? P>>Там где необходимо сделать runtime decision в C++, его также необходимо сделать и в C. P>>Compile-time decision конечно быстрее чем runtime decision, но никто вас не заставляет делать runtime decision, где возможно compile-time. И кстати, C++ предоставляет намного более богатые возможности для реализации compile-time decision. P>>Ярким примером является сравнение std::sort (C++ style) vs qsort (C-style) — как вы думаете, что быстрее? P>>В std::sort как раз compile-time decision, а в qsort — runtime decision. P>>http://www2.research.att.com/~bs/new_learning.pdf P>>http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Keynote-Bjarne-Stroustrup-Cpp11-Style 1>Дык кто ж пользуется этой qsort? Я о ней вообще узнал только после двух лет программирования на Си)) А если сравнивать std::sort с сортировкой написанной под конкретную задачу — выигрывает последняя. За счет проигрыша в объеме кода.
Вы понимаете почему std::sort быстрее? Посмотрите на ссылки которые я дал — там sort в несколько раз быстрее.
_>>>9. Аргументы вроде: На Си глобалы, код-лапша, легко насрать куда не нужно, что провоцирует трудновылавливаемые баги — тоже не аргументы. Баги есть даже в релизном коде многих успешных продуктов. P>>какие-то детские рассуждения. P>>То что баги есть во многих успешных проектах, ни капли не аргумент против того, что C++ позволяет писать программы с меньшим количеством багов (а значит быстрее). P>>При грамотном использовании C++ позволяет находить многие баги при компиляции, либо не делать их вовсе (по сравнению с C). Да, все делают ошибки, но при грамотном использовании C++ позволяет делать меньше багов чем C. 1>В целом согласен, но грамотное использование чистого Си тоже позволяет обходиться без ошибок (но по сравнению С++ будет больше кода).
не согласен: во-первых больше кода — больше ошибок, во-вторых такие штуки как RAII исключают возможность целых классов ошибок — то есть если вы знаете и используете RAII, то вы чисто технически не сможете сделать целую кучу ошибок.
_>>>12. Вся RMOS ( моя система для экспериментальных роботов-манипуляторов ) написана на С99. Далее LCC->AT89C51. ( лицензия есть ). P>>Как я писал ранее — отсутствие компилятора действительно может затруднять использование С++, но как я уже писал есть компиляторы транслирующие код C++ в код C. 1>Иногда транслируют так, что как раз отсутствие компилятора С++ это аргумент его не использовать)) Ну во всяком случае так раньше было, может сейчас уже проще.
да, как я сказал, пока — отсутствие компилятора это единственный более-менее разумный аргумент.
Здравствуйте, Piko, Вы писали:
P>Здравствуйте, 11molniev, Вы писали:
_>>>>1. Большую часть времени я пишу для платформы с большим ограничением по пространству-времени. ( робототехника ) P>>>Это распространённое заблуждение, что код на C более быстр и менее требователен. Если важна эффективность, C++ легко позволяет писать более оптимальные программы чем C. 1>>Вы можите аргументировать, почему С++ позволяет писать более оптимальные программы? Равные — безусловно. При равном объеме кода — тоже. Но в общем случае "более", звучит довольно странно.
P>http://www.rsdn.ru/forum/cpp/4731645.1.aspx
P>пример qsort vs sort. P>В qsort — runtime decision, в sort — compile-time, отсюда и скорость. И это не единственный пример.
Я то понимаю разницу между ними, но в том то и дело, что в чистом Си обычно именно compile-time. qsort — одно из немногих исключений. Все равно что виртуальные методы.
_>>>>7. Если бы все мои задачи требовали быстрого решения и реализации и не были бы требовательны к скорости выполнения и размерам кода, то да, я бы стал использовать С++ постоянно, даже не смотря на то, что этот язык просто чисто физически не возможно выучить на все 100%. P>>>даже выучив 50% C++, вы сможете делать более быстрые программы чем на C, либо более компактные чем на C (вообще одновременно максимальная компактность и максимальная скорость почти никогда не достигаются одновременно, в том числе и на C) 1>>Вопрос к пункту один.
P>ну так я не говорил что всегда одновременно получается достигнуть и скорость и компактность. либо то, либо другое, причём на C++ обе цели (по отдельности) достигаются легче чем на C.
ОК. Компактность — безусловно. Но скорость то на С++ достигается за счет legacy C.
_>>>>8. Аргументы вроде: на современных машинах вызов через один указатель или через указатель на на таблицу указателей не имеет значения, потому что скорость на современных машинах ничтожна мала и не ощутима даже в супер-пупер-тестах... — для меня не аргумент... P>>>При чём тут вызов через указатель? P>>>Там где необходимо сделать runtime decision в C++, его также необходимо сделать и в C. P>>>Compile-time decision конечно быстрее чем runtime decision, но никто вас не заставляет делать runtime decision, где возможно compile-time. И кстати, C++ предоставляет намного более богатые возможности для реализации compile-time decision. P>>>Ярким примером является сравнение std::sort (C++ style) vs qsort (C-style) — как вы думаете, что быстрее? P>>>В std::sort как раз compile-time decision, а в qsort — runtime decision. P>>>http://www2.research.att.com/~bs/new_learning.pdf P>>>http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Keynote-Bjarne-Stroustrup-Cpp11-Style 1>>Дык кто ж пользуется этой qsort? Я о ней вообще узнал только после двух лет программирования на Си)) А если сравнивать std::sort с сортировкой написанной под конкретную задачу — выигрывает последняя. За счет проигрыша в объеме кода.
P>Вы понимаете почему std::sort быстрее? Посмотрите на ссылки которые я дал — там sort в несколько раз быстрее.
Быстрей, потому что qsort делает вызовы функции сравнения. Лишние call/ret + использование стека по сравнению с С++. Реализация qsort под массив float без callback-a будет быстрей std::sort.
И таки не в несколько раз: 1,7 для 32 и 1,4 для 64 кода.
_>>>>9. Аргументы вроде: На Си глобалы, код-лапша, легко насрать куда не нужно, что провоцирует трудновылавливаемые баги — тоже не аргументы. Баги есть даже в релизном коде многих успешных продуктов. P>>>какие-то детские рассуждения. P>>>То что баги есть во многих успешных проектах, ни капли не аргумент против того, что C++ позволяет писать программы с меньшим количеством багов (а значит быстрее). P>>>При грамотном использовании C++ позволяет находить многие баги при компиляции, либо не делать их вовсе (по сравнению с C). Да, все делают ошибки, но при грамотном использовании C++ позволяет делать меньше багов чем C. 1>>В целом согласен, но грамотное использование чистого Си тоже позволяет обходиться без ошибок (но по сравнению С++ будет больше кода).
P>не согласен: во-первых больше кода — больше ошибок, во-вторых такие штуки как RAII исключают возможность целых классов ошибок — то есть если вы знаете и используете RAII, то вы чисто технически не сможете сделать целую кучу ошибок.
Это (в том числе и RAII) компенсируется в Си стандартом кодирования + выделением отдельного слоя api. Гарантия конечно не такая надежная, люди ошибаются чаще машин — но вполне себе работает. В качестве примера можно привести nginx — чистый Си, ничего не течет.
AD>>Вообще я ожидал услышать что-то типа "В случае <бла-бла-бла> был применён С++, но от него пришлось отказаться по причине <бла-бла-бла>. Код бы переписан на си, что привело к повышению <бла-бла-бла>", а получил кучу демагогии, из которой ничего не следует. Пичалька
Ну, по причине неадекватной сложности, ведущей к постоянной борьбе с языком, и постоянного вынужденного скатывания к синтаксическому онанизму. Плюс к тому ещё и высокая сложности разбора крешей в случае использования 'правильных' либ.
Привело к серьёзному упрощению кода, который теперь можно понять не изучая в течении нескольких лет методы высокой магии и прорицания в пространствах синтаксических подсластителей.
_>И вообще, каким нужно быть идиотом, чтобы создав проект, и на опираясь С++, вдруг, резко ни с того ни с сего решить даунсемплиться в Си?
Таким как я например. Больше года пишу новые проекты только на С, и рад что принял такое решение. И да, на С, но с исключениями, автоматическим управлением ресурсами и объектной моделью. С++ для всего этого не особенно и не нужен.
Как бы для уточнения, я использую С не по тому что не знаю или не умею готовить С++, но именно по тому что неплохо умею готовить и тот и другой. Дык вот, старый добрый С оказался на практике гораздо приятнее.
P.S.
То что С++ как-то сильно влияет на обнаружение ошибок в отличии от С — миф.
Здравствуйте, 11molniev, Вы писали:
_>>>>>1. Большую часть времени я пишу для платформы с большим ограничением по пространству-времени. ( робототехника ) P>>>>Это распространённое заблуждение, что код на C более быстр и менее требователен. Если важна эффективность, C++ легко позволяет писать более оптимальные программы чем C. 1>>>Вы можите аргументировать, почему С++ позволяет писать более оптимальные программы? Равные — безусловно. При равном объеме кода — тоже. Но в общем случае "более", звучит довольно странно. P>>http://www.rsdn.ru/forum/cpp/4731645.1.aspx
P>>пример qsort vs sort. P>>В qsort — runtime decision, в sort — compile-time, отсюда и скорость. И это не единственный пример. 1>Я то понимаю разницу между ними, но в том то и дело, что в чистом Си обычно именно compile-time.
Ну так там где в C возможно compile-time, оно возможно и в C++, причём в C++ — оно достигается намного легче/лучше/красивее. Я не призываю раздувать иерархии классов с виртуальным методами, там где возможно compile-time, и да я признаю что многие C++ проекты страдают от этого (из-за низкой квалификации разработчиков, и из-за слепого применения методов из других языков и т.п.)
_>>>>>7. Если бы все мои задачи требовали быстрого решения и реализации и не были бы требовательны к скорости выполнения и размерам кода, то да, я бы стал использовать С++ постоянно, даже не смотря на то, что этот язык просто чисто физически не возможно выучить на все 100%. P>>>>даже выучив 50% C++, вы сможете делать более быстрые программы чем на C, либо более компактные чем на C (вообще одновременно максимальная компактность и максимальная скорость почти никогда не достигаются одновременно, в том числе и на C) 1>>>Вопрос к пункту один. P>>ну так я не говорил что всегда одновременно получается достигнуть и скорость и компактность. либо то, либо другое, причём на C++ обе цели (по отдельности) достигаются легче чем на C. 1>ОК. Компактность — безусловно. Но скорость то на С++ достигается за счет legacy C.
это заблуждение. std::sort — это legacy C? expression templates — это legacy C? и т.п.
P>>Вы понимаете почему std::sort быстрее? Посмотрите на ссылки которые я дал — там sort в несколько раз быстрее. 1>Быстрей, потому что qsort делает вызовы функции сравнения. Лишние call/ret + использование стека по сравнению с С++.
даже если вызов функции сравнения в C++ не заинлайнится (то есть будет call/ret + stack), sort всё равно будет быстрее, так как прямой вызов.
1>Реализация qsort под массив float без callback-a будет быстрей std::sort. 1>И таки не в несколько раз: 1,7 для 32 и 1,4 для 64 кода.
Это ещё почему? для std::sort callback'и как правило инлайнятся.
P>>не согласен: во-первых больше кода — больше ошибок, во-вторых такие штуки как RAII исключают возможность целых классов ошибок — то есть если вы знаете и используете RAII, то вы чисто технически не сможете сделать целую кучу ошибок. 1>Это (в том числе и RAII) компенсируется в Си стандартом кодирования + выделением отдельного слоя api. Гарантия конечно не такая надежная, люди ошибаются чаще машин — но вполне себе работает.
так я не говорю что оно "вообще не работает". оно работает, но на C++ оно получается быстрее и безопасней.
ну вот пример, в блоке кода, пусть в функции, нужно при входе захватить мьютекс, открыть файл, и выделить память, при выходе соответственно нужно всё убрать.
Вы можете показать как это делается на C (в более-менее псевдокоде, 100% компилируемый исходник не нужен. просто используйте C-style), причём безопасно, с обработкой ошибок. + показать вызов такой функции.
1>В качестве примера можно привести nginx — чистый Си, ничего не течет.
вообще не аргумент.
можно что угодно написать хоть на ассемблере без протечек...
AD>>>Вообще я ожидал услышать что-то типа "В случае <бла-бла-бла> был применён С++, но от него пришлось отказаться по причине <бла-бла-бла>. Код бы переписан на си, что привело к повышению <бла-бла-бла>", а получил кучу демагогии, из которой ничего не следует. Пичалька AS>Ну, по причине неадекватной сложности, ведущей к постоянной борьбе с языком, и постоянного вынужденного скатывания к синтаксическому онанизму. Плюс к тому ещё и высокая сложности разбора крешей в случае использования 'правильных' либ.
если какие-то средства языка сложны для вас в использовании — не используйте их, если какие-то либы для вас не удобны — не используйте их, но это не причины баннить весь язык и все либы.
AS>Привело к серьёзному упрощению кода, который теперь можно понять не изучая в течении нескольких лет методы высокой магии и прорицания в пространствах синтаксических подсластителей.
что привело? переписывание на C? Так может если бы второй раз на C++ переписали, получилось бы не хуже?
AS>И да, на С, но с исключениями, автоматическим управлением ресурсами и объектной моделью. С++ для всего этого не особенно и не нужен.
Я не совсем понял, вы используете подмножество C++ ?
Или просто C? Как объектную модель можно на C сэумлировать — мне понятно. Но вот исключения и автоматическое управление ресурсами на С — сходу не соображу как сделать.
AS>Как бы для уточнения, я использую С не по тому что не знаю или не умею готовить С++, но именно по тому что неплохо умею готовить и тот и другой. Дык вот, старый добрый С оказался на практике гораздо приятнее.
ну — дело ваше, кому-то на ассемблере приятней.
AS>P.S. AS>То что С++ как-то сильно влияет на обнаружение ошибок в отличии от С — миф.
Здравствуйте, Piko, Вы писали:
P>Здравствуйте, 11molniev, Вы писали:
_>>>>>>1. Большую часть времени я пишу для платформы с большим ограничением по пространству-времени. ( робототехника ) P>>>>>Это распространённое заблуждение, что код на C более быстр и менее требователен. Если важна эффективность, C++ легко позволяет писать более оптимальные программы чем C. 1>>>>Вы можите аргументировать, почему С++ позволяет писать более оптимальные программы? Равные — безусловно. При равном объеме кода — тоже. Но в общем случае "более", звучит довольно странно. P>>>http://www.rsdn.ru/forum/cpp/4731645.1.aspx
P>>>пример qsort vs sort. P>>>В qsort — runtime decision, в sort — compile-time, отсюда и скорость. И это не единственный пример. 1>>Я то понимаю разницу между ними, но в том то и дело, что в чистом Си обычно именно compile-time. P>Ну так там где в C возможно compile-time, оно возможно и в C++, причём в C++ — оно достигается намного легче/лучше/красивее. Я не призываю раздувать иерархии классов с виртуальным методами, там где возможно compile-time, и да я признаю что многие C++ проекты страдают от этого (из-за низкой квалификации разработчиков, и из-за слепого применения методов из других языков и т.п.)
Дык о том речь, что runtime decision получаеться в Си только посредством усилий разработчика, а в плюсах и без оных.
_>>>>>>7. Если бы все мои задачи требовали быстрого решения и реализации и не были бы требовательны к скорости выполнения и размерам кода, то да, я бы стал использовать С++ постоянно, даже не смотря на то, что этот язык просто чисто физически не возможно выучить на все 100%. P>>>>>даже выучив 50% C++, вы сможете делать более быстрые программы чем на C, либо более компактные чем на C (вообще одновременно максимальная компактность и максимальная скорость почти никогда не достигаются одновременно, в том числе и на C) 1>>>>Вопрос к пункту один. P>>>ну так я не говорил что всегда одновременно получается достигнуть и скорость и компактность. либо то, либо другое, причём на C++ обе цели (по отдельности) достигаются легче чем на C. 1>>ОК. Компактность — безусловно. Но скорость то на С++ достигается за счет legacy C. P>это заблуждение. std::sort — это legacy C? expression templates — это legacy C? и т.п.
std::sort, expression templates, это способ уменьшить объем кода, а не ускорить его выполнение. В чем заблуждение?
P>>>Вы понимаете почему std::sort быстрее? Посмотрите на ссылки которые я дал — там sort в несколько раз быстрее. 1>>Быстрей, потому что qsort делает вызовы функции сравнения. Лишние call/ret + использование стека по сравнению с С++. P>даже если вызов функции сравнения в C++ не заинлайнится (то есть будет call/ret + stack), sort всё равно будет быстрее, так как прямой вызов.
qsort из Си будет медленней, чем std::sort. std::sort будет медленней алгоритма сортировки для double*. C++ выигрывает в скорости при одинаковом объеме кода, проигрывает при разном.
1>>Реализация qsort под массив float без callback-a будет быстрей std::sort. 1>>И таки не в несколько раз: 1,7 для 32 и 1,4 для 64 кода. P>Это ещё почему? для std::sort callback'и как правило инлайнятся.
Потому что оверхейд больший. Если хотите скину код, состряпанный на скорую руку. Для qsort кстати функция сравнения не инлайница — разница в скорости 32/64 скорей всего объединяться разной формой передачи аргументов по умолчанию (не проверял, могу ошибаться).
P>>>не согласен: во-первых больше кода — больше ошибок, во-вторых такие штуки как RAII исключают возможность целых классов ошибок — то есть если вы знаете и используете RAII, то вы чисто технически не сможете сделать целую кучу ошибок. 1>>Это (в том числе и RAII) компенсируется в Си стандартом кодирования + выделением отдельного слоя api. Гарантия конечно не такая надежная, люди ошибаются чаще машин — но вполне себе работает.
P>так я не говорю что оно "вообще не работает". оно работает, но на C++ оно получается быстрее и безопасней. P>ну вот пример, в блоке кода, пусть в функции, нужно при входе захватить мьютекс, открыть файл, и выделить память, при выходе соответственно нужно всё убрать. P>Вы можете показать как это делается на C (в более-менее псевдокоде, 100% компилируемый исходник не нужен. просто используйте C-style), причём безопасно, с обработкой ошибок. + показать вызов такой функции.
ОК, я не стал все копировать, но общие моменты я думаю будут ясны.
В stdafx.h:
#define MALLOC(x) (x*)memalloc(sizeof(x))
#define ZEROPTR(x) memset(x, 0, sizeof(*x))
#define SAFEALLOC(xpointer, xtype) { xpointer = MALLOC(xtype); RETNULL(xpointer); ZEROPTR(xpointer); }
#define RETNULL(x) if (NULL == (x) ) goto ret;
#define CODE_ERROR SIZE_MAX
#define CODE_SUCCESS 0
#define RETERROR(x) { if (CODE_SUCCESS != x) goto ret; }
#define RETEQU(x, y) if ( (y) == (x) ) goto ret;
В коде:
t_error function name(...) {
HANDLE h = INVALID_HANDLE_VALUE;
struct name *name;
void * p = NULL;
t_error = CODE_ERROR_BAG...;
....
EnterCriticalSection(&cs);
SAFEALLOC(name, struct name);
RETEQU(INVALID_HANDLE_VALUE, h = CreateFile(...) );
RETNULL( p = memalloc( ... ) );
1>>В качестве примера можно привести nginx — чистый Си, ничего не течет.
P>вообще не аргумент. P>можно что угодно написать хоть на ассемблере без протечек...
И да и нет. Подобный пример опровергает утверждение, что больше кода — больше ошибок. Есть ещё человеческий фактор.
Здравствуйте, Piko, Вы писали:
P>да, хотя бы посмотрите на сортировку: P>что безопасней?
Между сильно влияет и безопаснее есть какая-то существенная связь?!
P>P.S. C++ позволяет не только лучше обнаруживать ошибки, но и не делать вовсе целые классы ошибок.
И на ещё большее количество ошибок он вообще не реагирует. Я же говорю, это не принципиально )))
Что есть, что нет — Рояля не играет.
AS>>Ну, по причине неадекватной сложности, ведущей к постоянной борьбе с языком, и постоянного вынужденного скатывания к синтаксическому онанизму. Плюс к тому ещё и высокая сложности разбора крешей в случае использования 'правильных' либ. P>если какие-то средства языка сложны для вас в использовании — не используйте их, если какие-то либы для вас не удобны — не используйте их, но это не причины баннить весь язык и все либы.
Дык, он же весь такой )))
P>что привело? переписывание на C? Так может если бы второй раз на C++ переписали, получилось бы не хуже? P>Я не совсем понял, вы используете подмножество C++ ? P>Или просто C? Как объектную модель можно на C сэумлировать — мне понятно. Но вот исключения и автоматическое управление ресурсами на С — сходу не соображу как сделать.
С и С++ разные языки. Считать один подмножеством другого — большая ошибка, говорящая о незнании одного из языков, ну или обоих.
То что вы чего-то не видите или не соображаете, означает ровно то что означает. Как сделать я уже не раз писал.
Тут нельзя сказать хуже/лучше. Проще, понятнее, удобнее ... всё субъективные характеристики.
Вот вам как пример одного из аспектов (а их много...), кошмарный сон — представьте себе что вы такой крутой С++ программер, ну скажем, один такой крутой на целый на город. Александреску там вкуриваете с полпинка, на шаблонах не материтесь, а прямо таки излагаете. И в коде у вас прямо таки полный фашизм контроль и порядок, все байты по струнке ходють. Круто да? И вдруг вам нужно часть своей работы делегировать кому-то ещё... упс, да?
AS>>Как бы для уточнения, я использую С не по тому что не знаю или не умею готовить С++, но именно по тому что неплохо умею готовить и тот и другой. Дык вот, старый добрый С оказался на практике гораздо приятнее. P>ну — дело ваше, кому-то на ассемблере приятней.
Ну вот и ладненько )
AS>>То что С++ как-то сильно влияет на обнаружение ошибок в отличии от С — миф. P>Как реализовать на C: ....
А зачем? Вам это как-то РЕАЛЬНО хоть раз помогло? Мне нет. А с поправкой на весь синтаксический онанизм что с этим связан, это ваще бессмысленно и даже вредно.
Здравствуйте, 11molniev, Вы писали:
P>>>>В qsort — runtime decision, в sort — compile-time, отсюда и скорость. И это не единственный пример. 1>>>Я то понимаю разницу между ними, но в том то и дело, что в чистом Си обычно именно compile-time. P>>Ну так там где в C возможно compile-time, оно возможно и в C++, причём в C++ — оно достигается намного легче/лучше/красивее. Я не призываю раздувать иерархии классов с виртуальным методами, там где возможно compile-time, и да я признаю что многие C++ проекты страдают от этого (из-за низкой квалификации разработчиков, и из-за слепого применения методов из других языков и т.п.) 1>Дык о том речь, что runtime decision получаеться в Си только посредством усилий разработчика, а в плюсах и без оных.
а чем принципиально indirect call отличается от virtual call в контексте runtime decision? и то и то получается посредством усилий разработчика
_>>>>>>>7. Если бы все мои задачи требовали быстрого решения и реализации и не были бы требовательны к скорости выполнения и размерам кода, то да, я бы стал использовать С++ постоянно, даже не смотря на то, что этот язык просто чисто физически не возможно выучить на все 100%. P>>>>>>даже выучив 50% C++, вы сможете делать более быстрые программы чем на C, либо более компактные чем на C (вообще одновременно максимальная компактность и максимальная скорость почти никогда не достигаются одновременно, в том числе и на C) 1>>>>>Вопрос к пункту один. P>>>>ну так я не говорил что всегда одновременно получается достигнуть и скорость и компактность. либо то, либо другое, причём на C++ обе цели (по отдельности) достигаются легче чем на C. 1>>>ОК. Компактность — безусловно. Но скорость то на С++ достигается за счет legacy C. P>>это заблуждение. std::sort — это legacy C? expression templates — это legacy C? и т.п. 1>std::sort, expression templates, это способ уменьшить объем кода, а не ускорить его выполнение. В чем заблуждение?
ещё раз, вы говорите, что скорость C++ достигается за счёт legacy C.
std::sort это legacy С?
или вы имеете ввиду то, что для любого C++ кода можно написать аналогичный C код? если да, то я и не спорю — да можно, есть даже авто трансляторы с C++ на C. вот только размер аналогичного С кода будет не меньше, а в большинстве случаев больше в разы.
P>>>>Вы понимаете почему std::sort быстрее? Посмотрите на ссылки которые я дал — там sort в несколько раз быстрее. 1>>>Быстрей, потому что qsort делает вызовы функции сравнения. Лишние call/ret + использование стека по сравнению с С++. P>>даже если вызов функции сравнения в C++ не заинлайнится (то есть будет call/ret + stack), sort всё равно будет быстрее, так как прямой вызов. 1>qsort из Си будет медленней, чем std::sort.
ну вот, а товарищ org_256, говорит что идентичны, и при этом принимает за оскорбление:
Не примите за оскорбление, но вы сильно заблуждаетесь на счёт своего знания C++.
1>std::sort будет медленней алгоритма сортировки для double*.
вы имеете ввиду специальные алгоритмы (типа Radix sort) отличные от quicksort?
ну так C++ и в этом месте лучше — можно сделать специализацию для double*, либо вообще для T* — причём интерфейс не поменяется.
1>C++ выигрывает в скорости при одинаковом объеме кода, проигрывает при разном.
вы имеете ввиду использование специальных алгоритмов, для специальных случаев?
1>>>Реализация qsort под массив float без callback-a будет быстрей std::sort. 1>>>И таки не в несколько раз: 1,7 для 32 и 1,4 для 64 кода. P>>Это ещё почему? для std::sort callback'и как правило инлайнятся. 1>Потому что оверхейд больший.
на что именно оверхед, ваши предположения?
1>Если хотите скину код, состряпанный на скорую руку.
если не трудно — то скиньте, мне будет интересно. можно сюда, а можно в http://ideone.com/
1>Для qsort кстати функция сравнения не инлайница
браво
P>>>>не согласен: во-первых больше кода — больше ошибок, во-вторых такие штуки как RAII исключают возможность целых классов ошибок — то есть если вы знаете и используете RAII, то вы чисто технически не сможете сделать целую кучу ошибок. 1>>>Это (в том числе и RAII) компенсируется в Си стандартом кодирования + выделением отдельного слоя api. Гарантия конечно не такая надежная, люди ошибаются чаще машин — но вполне себе работает. P>>так я не говорю что оно "вообще не работает". оно работает, но на C++ оно получается быстрее и безопасней. P>>ну вот пример, в блоке кода, пусть в функции, нужно при входе захватить мьютекс, открыть файл, и выделить память, при выходе соответственно нужно всё убрать. P>>Вы можете показать как это делается на C (в более-менее псевдокоде, 100% компилируемый исходник не нужен. просто используйте C-style), причём безопасно, с обработкой ошибок. + показать вызов такой функции.
1>ОК, я не стал все копировать, но общие моменты я думаю будут ясны.
вот буквально за 10 секунд увидел:
Я правильно понимаю, если это сфейлится
1> RETNULL( p = memalloc( ... ) );
то это
1> LeaveCriticalSection(&cs);
не вызовется?
...
даже для C, я ожидал увидеть меньше кода, так как имел в виду псевдокод.
причём try, может быть намного выше в call hierarchy, когда в C надо сравнивать код всё время.
Я думаю даже без причёсывания вашего C-style варианта, видно что безопасней и легче.
1>>>В качестве примера можно привести nginx — чистый Си, ничего не течет. P>>вообще не аргумент. P>>можно что угодно написать хоть на ассемблере без протечек... 1>И да и нет. Подобный пример опровергает утверждение, что больше кода — больше ошибок. Есть ещё человеческий фактор.
я считаю не опровергает.
важно рассматривать одновременно: объём кода, время затраченное на его написание (грубо говоря строк/час), и количество ошибок.
например 10000строчный проект мог полироваться 20 лет, естественно в нём может быть меньше ошибок чем в проекте на 1000строк написанному за день.
P>Или просто C? Как объектную модель можно на C сэумлировать — мне понятно. Но вот исключения и автоматическое управление ресурсами на С — сходу не соображу как сделать.
Исключения делаются на setjmp. Автоматическое управление ресурсами — не знаю как. Впрочем, мне неизвестны языки с автоматическим управлением ресурсами, кроме С++.
Здравствуйте, Alexéy Sudachén, Вы писали:
P>>что привело? переписывание на C? Так может если бы второй раз на C++ переписали, получилось бы не хуже? P>>Я не совсем понял, вы используете подмножество C++ ? P>>Или просто C? Как объектную модель можно на C сэумлировать — мне понятно. Но вот исключения и автоматическое управление ресурсами на С — сходу не соображу как сделать. AS>С и С++ разные языки. Считать один подмножеством другого — большая ошибка, говорящая о незнании одного из языков, ну или обоих.
Что мешает использовать то подмножество C++, которое комфортно вам? (я знаю что множество C не полностью входит в C++)
AS>То что вы чего-то не видите или не соображаете, означает ровно то что означает. Как сделать я уже не раз писал.
если вам трудно описать как вы используете автоматическое управление ресурсами на C и исключения, хотя бы в паре предложений, я не вижу смысла продолжения моего общения с вами
Здравствуйте, Vamp, Вы писали:
P>>Или просто C? Как объектную модель можно на C сэумлировать — мне понятно. Но вот исключения и автоматическое управление ресурсами на С — сходу не соображу как сделать. V>Исключения делаются на setjmp.
ок, но вот зачем грызть этот кактус? (это вопрос не к вам. что-то типа риторического)
V> Автоматическое управление ресурсами — не знаю как. Впрочем, мне неизвестны языки с автоматическим управлением ресурсами, кроме С++.
вроде D. но не суть.
Alexéy Sudachén вроде как умеет это делать на C, правда не показывает
Здравствуйте, Piko, Вы писали:
P>Здравствуйте, 11molniev, Вы писали:
P>>>>>В qsort — runtime decision, в sort — compile-time, отсюда и скорость. И это не единственный пример. 1>>>>Я то понимаю разницу между ними, но в том то и дело, что в чистом Си обычно именно compile-time. P>>>Ну так там где в C возможно compile-time, оно возможно и в C++, причём в C++ — оно достигается намного легче/лучше/красивее. Я не призываю раздувать иерархии классов с виртуальным методами, там где возможно compile-time, и да я признаю что многие C++ проекты страдают от этого (из-за низкой квалификации разработчиков, и из-за слепого применения методов из других языков и т.п.) 1>>Дык о том речь, что runtime decision получаеться в Си только посредством усилий разработчика, а в плюсах и без оных. P>а чем принципиально indirect call отличается от virtual call в контексте runtime decision? и то и то получается посредством усилий разработчика
В С эти усилия всегда в явном виде. С++ можно и без усилий получить их по дефолту. Проще говоря на чистом Си тормоза всегда являются результатом осознанного решения разработчика. Только то и всего.
_>>>>>>>>7. Если бы все мои задачи требовали быстрого решения и реализации и не были бы требовательны к скорости выполнения и размерам кода, то да, я бы стал использовать С++ постоянно, даже не смотря на то, что этот язык просто чисто физически не возможно выучить на все 100%. P>>>>>>>даже выучив 50% C++, вы сможете делать более быстрые программы чем на C, либо более компактные чем на C (вообще одновременно максимальная компактность и максимальная скорость почти никогда не достигаются одновременно, в том числе и на C) 1>>>>>>Вопрос к пункту один. P>>>>>ну так я не говорил что всегда одновременно получается достигнуть и скорость и компактность. либо то, либо другое, причём на C++ обе цели (по отдельности) достигаются легче чем на C. 1>>>>ОК. Компактность — безусловно. Но скорость то на С++ достигается за счет legacy C. P>>>это заблуждение. std::sort — это legacy C? expression templates — это legacy C? и т.п. 1>>std::sort, expression templates, это способ уменьшить объем кода, а не ускорить его выполнение. В чем заблуждение? P>ещё раз, вы говорите, что скорость C++ достигается за счёт legacy C.
Да. P>std::sort это legacy С?
Нет.
P>или вы имеете ввиду то, что для любого C++ кода можно написать аналогичный C код? если да, то я и не спорю — да можно, есть даже авто трансляторы с C++ на C. вот только размер аналогичного С кода будет не меньше, а в большинстве случаев больше в разы.
Нет. Я имею в виду, что получить максимальную скорость в плюсах можно используя для критичных участков кода чистый Си. Если вместо вызова std::sort вы напишите быстрою сортировку на си, она будет работать быстрей.
Ещё раз — qsort, это быстрая сортировка на Си для произвольных структур. Она заведомо проигранная в скорости. Осознанный выбор, когда в этом месте программы на её скорость можно наплевать.
Да размер кода будет больше. Я собственно везде об этом и говорю. Лично для меня основное преимущество С++, когда я использую его, вместо С — это объем кода.
P>>>>>Вы понимаете почему std::sort быстрее? Посмотрите на ссылки которые я дал — там sort в несколько раз быстрее. 1>>>>Быстрей, потому что qsort делает вызовы функции сравнения. Лишние call/ret + использование стека по сравнению с С++. P>>>даже если вызов функции сравнения в C++ не заинлайнится (то есть будет call/ret + stack), sort всё равно будет быстрее, так как прямой вызов. 1>>qsort из Си будет медленней, чем std::sort. P>ну вот, а товарищ org_256, говорит что идентичны, и при этом принимает за оскорбление: P>
P>Не примите за оскорбление, но вы сильно заблуждаетесь на счёт своего знания C++.
Ну все мы люди, все делаем ошибки. Надеюсь вы пояснили ему причину его заблуждения.
1>>std::sort будет медленней алгоритма сортировки для double*.
P>вы имеете ввиду специальные алгоритмы (типа Radix sort) отличные от quicksort? P>ну так C++ и в этом месте лучше — можно сделать специализацию для double*, либо вообще для T* — причём интерфейс не поменяется.
Да нет же. И шаблоны я знаю.
1>>C++ выигрывает в скорости при одинаковом объеме кода, проигрывает при разном. P>вы имеете ввиду использование специальных алгоритмов, для специальных случаев?
Нет.
1>>>>Реализация qsort под массив float без callback-a будет быстрей std::sort. 1>>>>И таки не в несколько раз: 1,7 для 32 и 1,4 для 64 кода. P>>>Это ещё почему? для std::sort callback'и как правило инлайнятся. 1>>Потому что оверхейд больший.
P>на что именно оверхед, ваши предположения?
Мое предложение посмотреть в дизассемблере, но так навскидку, первое что попало на глаза:
000000013FC41805 E8 C6 00 00 00 call std::_Unguarded_partition<double * __ptr64> (13FC418D0h)
1>>Если хотите скину код, состряпанный на скорую руку.
P>если не трудно — то скиньте, мне будет интересно. можно сюда, а можно в http://ideone.com/ http://pastebin.com/YsGRBtZ0 — только #include "stdafx.h" уберите, я забыл http://ideone.com/iL6Gb
На скорую рука, так что не очень, но общий подход иллюстрирует.
1>>Для qsort кстати функция сравнения не инлайница P>браво
Я обратил ваше внимание на то, почему в приведенном вами сравнении выигрывает С++. И как это исправить.
P>>>>>не согласен: во-первых больше кода — больше ошибок, во-вторых такие штуки как RAII исключают возможность целых классов ошибок — то есть если вы знаете и используете RAII, то вы чисто технически не сможете сделать целую кучу ошибок. 1>>>>Это (в том числе и RAII) компенсируется в Си стандартом кодирования + выделением отдельного слоя api. Гарантия конечно не такая надежная, люди ошибаются чаще машин — но вполне себе работает. P>>>так я не говорю что оно "вообще не работает". оно работает, но на C++ оно получается быстрее и безопасней. P>>>ну вот пример, в блоке кода, пусть в функции, нужно при входе захватить мьютекс, открыть файл, и выделить память, при выходе соответственно нужно всё убрать. P>>>Вы можете показать как это делается на C (в более-менее псевдокоде, 100% компилируемый исходник не нужен. просто используйте C-style), причём безопасно, с обработкой ошибок. + показать вызов такой функции.
1>>ОК, я не стал все копировать, но общие моменты я думаю будут ясны.
P>вот буквально за 10 секунд увидел:
P>Я правильно понимаю, если это сфейлится
1>> RETNULL( p = memalloc( ... ) );
P>то это
1>> LeaveCriticalSection(&cs);
P>не вызовется?
Да. Её следовало вынести за ret. P>...
P>даже для C, я ожидал увидеть меньше кода, так как имел в виду псевдокод.
P>Вот пример на C++ P>
И? Померились?
P>причём try, может быть намного выше в call hierarchy, когда в C надо сравнивать код всё время.
И ещё чаще его там в итоге не будет для выбрасываемого типа исключения)))
P>Я думаю даже без причёсывания вашего C-style варианта, видно что безопасней и легче.
Чем меряете безопасность и легкость кода? Всетаки субъективные критерии. Помимо наличия конструкторов и деструкторов.
1>>>>В качестве примера можно привести nginx — чистый Си, ничего не течет. P>>>вообще не аргумент. P>>>можно что угодно написать хоть на ассемблере без протечек... 1>>И да и нет. Подобный пример опровергает утверждение, что больше кода — больше ошибок. Есть ещё человеческий фактор.
P>я считаю не опровергает. P>важно рассматривать одновременно: объём кода, время затраченное на его написание (грубо говоря строк/час), и количество ошибок. P>например 10000строчный проект мог полироваться 20 лет, естественно в нём может быть меньше ошибок чем в проекте на 1000строк написанному за день.
Ну дык потому и привожу в пример nginx. Кода там немало, и делался не 20 лет.
. Полностью манглинг это не убирает. Не пробовал что ли, никогда? Чтобы не было манглинга, надо колдовать с опциями компилятора (gcc) или сочинять .def файл (виндоус).
