Опасный код на C

>Хотя бы какими-нибудь.

Какими конкретно?

>А то обычно пишут cout << "Hello world"; вместо printf("Hello world"); и считают, что используют "возможности С++".

И? И чем это плохи потоки? В же критикуете, значит, знаете, что хорошо, а что плохо. Поведайте нам.

>>Расскажите, в чем костыльность, например, STL

>В том, что сами шаблоны С++ - это костыль. Но, я понимаю, вам это трудно осилить.

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

>Порассуждаем на тему "Что было бы, если бы у бабушки были яйца"? :)

Порассуждайте-порассуждайте.

>Абстрактно расматривать подобные ситуацции не получится. Причин к тому что проект в конечном итоге уперся в производительность может быть очень много.

Ну почему же? Причину как раз выяснили - неправильный выбор инструмента. и разработчики вынуждены были согласиться с этим (потому как они сами эту причину и нашли) - что средствами C это не решается. Вернее, решить-то можно (если "упереться рогом"), но "игра не стоит свеч", потому как придётся просто заново изобрести Erlang+OTP:)

>средствами C это не решается.

Можно поинтересоваться, а что именно не получилось решить средствами C? А то тут люди на С пишут начиная от ядер ОС, поисковых систем, всякого embedded и заканчивая гуями на десктопах, а здесь что-то не получилось. Может, в консерватории что-то не так?

> Можно поинтересоваться, а что именно не получилось решить средствами C? А то тут люди на С пишут начиная от ядер ОС, поисковых систем, всякого embedded и заканчивая гуями на десктопах, а здесь что-то не получилось. Может, в консерватории что-то не так?

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

>>А то обычно пишут cout << "Hello world"; вместо printf("Hello world"); и считают, что используют "возможности С++".

>И? И чем это плохи потоки? В же критикуете, значит, знаете, что хорошо, а что плохо. Поведайте нам.

a) При локализации переводить надо всю фразу целиком а<<не<<по<<кусочкам.

б) Парсинг текста никакого отношения к вводу-выводу не имеет, и следовательно гибрид ужа и ежа из std::istream никуда не годится.

>>>Расскажите, в чем костыльность, например, STL

>>В том, что сами шаблоны С++ - это костыль. Но, я понимаю, вам это трудно осилить.

>И в чем шаблоны - костыль? В том, что упрощают жизнь и реализуют полиморфизм времени компиляции?

Полиморфизма времени компиляции не существует.

PS: Как же страуструпофагов извести с ЛОР'а? Регенерируют же аки тролли.

2 Led
>Потому что как раз это и не является причиной назвать язык хорошим
 что, "это"?

>Задача?
 тоже, что и для C - переносимый ассемблер

2 anonymous 
>"С" достаточно давно морально устарел. Не спорю, иногда вынуждены его использовать: нет других средств разработки, куча кода уже написана на "С".

 почему ты считаешь, что C устарел? назови причины

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

2 Led

>В том-то и дело, что не всегда "just works":) круто. ну и что это доказывает? то что C плохой язык? нет. то что есть языки лучше? нет. и нахрена тогда ты это сказал?

2 anonymous

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

//yesping

2 stellar

>Можно поинтересоваться, а что именно не получилось решить средствами C? А то тут люди на С пишут начиная от ядер ОС, поисковых систем, всякого embedded и заканчивая гуями на десктопах, а здесь что-то не получилось. Может, в консерватории что-то не так?

интерсно, а что еще пишут на C? я не понимаю зачем использовать C там где он не нужен?

>a) При локализации переводить надо всю фразу целиком а<<не<<по<<кусочкам.

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

>б) Парсинг текста никакого отношения к вводу-выводу не имеет, и следовательно гибрид ужа и ежа из std::istream никуда не годится.

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

>Полиморфизма времени компиляции не существует.

Как интересно. Осильте, пожалуйста:

http://www.gamedev.net/reference/articles/article2015.asp

http://cpp-tutorial.cpp4u.com/OOP_polymorphism.html

И не пишите более глупостей.

>PS: Как же страуструпофагов извести с ЛОР'а? Регенерируют же аки тролли.

Как же тех, кто даже поверхностно не разбирается в C++, но мнение имеют, извести с ЛОРа. Регенерируют, тролли.

>В том-то и дело, что не всегда "just works":) круто. ну и что это доказывает? то что C плохой язык? нет. то что есть языки лучше? нет. и нахрена тогда ты это сказал?

Это доказывает, что С *наиболее*удобно* использовать. В отличие от, скажем, Algol, который крут как незнамо что, а вот не пишут на нем. Я понимаю, да, виноваты корпорации и вообще, враги синтаксических карамелек.

> Программист не должен заморачиваться такими тупыми вещами, как, например "сколько байт в типе int у меня сейчас, а сколько будет на архитектуре X? а сколько в OS Y? а сколько в компиляторе Z?"

Для вас изобрели basic. А для продвинутых -- brainfuck, там вообще всё один большой массив.

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

там написано, что можно, но не получилось. Потому, что... бла-бла-бла. Хотелось бы узнать, *что*именно* не получилось.

> Программист не должен заморачиваться такими тупыми вещами, как, например "сколько байт в типе int у меня сейчас, а сколько будет на архитектуре X? а сколько в OS Y? а сколько в компиляторе Z?"

Против этого уже десять лет, как стандартизированы такие вещи, как int16_t итп.

>Так переписывали потом (на том, на чём надо). За время заза в три меньшее. Производительность - как минимум - не хуже. масштабируемость - практически не ограничена. Led *** (*) (06.11.2008 12:33:48)

Чой-то много тумана: "системные", "не ламеры", "переписывали на чём надо", "время в 3 раза...", "производительность не хуже", "масштабируемость не ограничена". Сильно смахивает на откровенную брехню. Переписывали-то на чем? На lisp-е? Питоне? Или C++? Намекни хоть область применения вашего шедевра.

>PS: Как же страуструпофагов извести с ЛОР'а? Регенерируют же аки тролли. Absurd * (*) (06.11.2008 13:50:08)

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

>>a) При локализации переводить надо всю фразу целиком а<<не<<по<<кусочкам.

>И что мешает вывести в потоке сразу *всю* локализованную строку? Строка, видимо, 100 мегабайт? Не смешите, не бывает в реальности таких *строк*.

std::cout<<"There are "<<n<<" files in directory\n" - это строка разбита на куски. printf("There are %i files in directory\n", n) - эта нет.

Даже если высказывание не может иметь никаких неправильных трактовок все равно кто-то поймет не так (ц) Мерфи. Плюсофаги, что с них взять.

>>б) Парсинг текста никакого отношения к вводу-выводу не имеет, и следовательно гибрид ужа и ежа из std::istream никуда не годится.

>Не годится - не пользуйтесь. Кроме istream, так, на минутку, потоки умеют еще и кучу других вещей.

Не умеют ничего полезного. Нужно парсить текст - берешь lex/yacc.

>>Полиморфизма времени компиляции не существует.

>Как интересно. Осильте, пожалуйста:

Я знаю что там написано. Шаблоны С++ мы тут на ЛОР уже закопали, поскольку

а) Они херят раздельную компиляцию б) Они херят ABI и, следовательно, модульность в) Нормального Open-Source IDE способного понимать С++ шаблонный код не существует, есть одни недоделки.

Не насилуйте пожалуйста труп.

>>PS: Как же страуструпофагов извести с ЛОР'а? Регенерируют же аки тролли.

>Как же тех, кто даже поверхностно не разбирается в C++, но мнение имеют, извести с ЛОРа.

Типичное плюсофагское обинение в ниасиливании. Слив засчитан.

>а) Они херят раздельную компиляцию

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

>б) Они херят ABI и, следовательно, модульность

Очень и очень сомнительный аргумент, особенно для Open Source

>в) Нормального Open-Source IDE способного понимать С++ шаблонный код не существует, есть одни недоделки.

В данном случае - это проблемы Open-Source IDE, а не С++

>Не насилуйте пожалуйста труп.

Да никому твой мозг не нужен

>>Монструозность - это как раз удел C.

>Как интересно. Приведите пример немонструозного ЯП. Объясните,

>почему же на этом ЯП не написано до сих пор ни одного ядра ОС,

>используемого в production.

Оберон

>>а) Они херят раздельную компиляцию

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

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

>>б) Они херят ABI и, следовательно, модульность

>Очень и очень сомнительный аргумент, особенно для Open Source

Мне нахрен не нужны открытые сорцы говна на С++. Проще ассемблерные листинги изучить.

>>в) Нормального Open-Source IDE способного понимать С++ шаблонный код не существует, есть одни недоделки.

>В данном случае - это проблемы Open-Source IDE, а не С++

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

> Приведите пример немонструозного ЯП

А что вы подразумеваете под монструозностью? Лично я - синтаксический оверхед. В этом смысле любой язык более высого уровня менее монструозен чем C.

> Объясните, почему же на этом ЯП не написано до сих пор ни одного ядра ОС, используемого в production.

Критерий немонструозности языка для вас - существование реализации ядра ОС на этом языке? Не понимаю к чему эта фраза вообще.

Статья ужас. Такое писать нельзя. Не засоряйте тырнет.

>конкуренция в совместно используемой памяти

Ввобще пятЪ! Случайно глаз выцепил, я дальше пары разделов не смог.

:Е

> Такой подход называется defensive programming и является спорным.

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

>Не насилуйте пожалуйста труп.

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

>Слив засчитан.

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

самый опасный код ---->> одноэс на ЗуПе =)))

на си можно легко написать опасный код - это же низкоуровневый язык

>Весь DirectX

DirectX это не язык программирования и не библиотека для HPC, так что ты опять только пукнул

>Мне нахрен не нужны открытые сорцы говна на С++. Проще ассемблерные лстинги изучить.

Вперед, красноглазик

>Перекладывание с больной головы на здоровую

Проблемы твоей головы это только твои проблемы

>Вообще, если для рещения не походит динамический полиморфизм то заведомо не подойдет никакой.

Ты случаем не в одной палате с Наполеоном и Луговским прописан?

че-та тривиально как-то всё, кто на Це программит, автоматически уже эти вещи в уме держит, я думал что будут действительно о граблях всяких написано переводчик жжот

> ... Шаблоны С++ ... > > а) Они херят раздельную компиляцию

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

За деталями к Страуструпу.

> Более новая функция, strncat(), была создана, чтобы сделать это легче. Эта функция принимает в качестве третьего аргумента [объем пространства в первой строке]. Она гарантирует, что функция никогда не выйдет за пределы первой строки

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