Беседка для программистов, или «Бутерброд с кодом»

(пожимает плечами) Полистай мои исходники, я позавчера выкладывал.

Его процедурно-ориентированность. То бишь его способность описывать действия - последовательно, шаг за шагом, ныряя в функции и выныривая обратно.
C++ такой волшебной возможностью не обладает :-( - при просмотре исходника и его моделировании "в голове" нырок заканчивается, как правило, на первом вызове виртуального члена (ближайший аналог - "эй ты, подь туда и сделай чтобы было вот так - и меня не бомбит, что и как именно ты сделаешь"). Это с т.з. объектоукладчика. Классостроителя же, в свою очередь, не должен чесать вопрос "а на кой ляд это действие вообще нужно и что должно в конце концов получиться". Разделение труда, грок? А ещё незабвенный А.Смит писал, что оно превращает человека в узкоспециализированного закручивателя третьей левой задней гайки. :-(

Всё знаю. :-)))) Достаточно для читать/править чужие исходники (см. в моей рутрекерной раздаче сырцы dxmci) и даже писать свои (в той же раздаче файл dxthread.cpp мой, но это вынужденно - иначе пришлось бы геморроиться с вызовом C++ из Си).

Факт, сам подтвердю. :-(

Тоже факт, наблюдаю на окружающих.

Тоже подтверждаю - хорошо заметно на программистах-новичках.

while - да. А вот "if ( ) do { } while ( )" у плюсплюсников ни разу не видел, а они у меня видели - не понимали. Про "do { } while (0)" вообще молчу. :-((((

Ага. Особенно нюанс вида "подводные грабли". :-(
Пример. Один чел (новичок, который "знал оба одинаково") написал на C++ сортировку, которая 200 строк сортировала больше двух секунд, а 1000 строк - минуту с чем-то. А всего кода - меньше страницы. Начали выяснять. Во-первых, пузырьком, а во-вторых, выбирал в строках фрагменты отсель-досель (по которым сортировка) CString'овой резкой-клейкой. Представляешь, сколько десятков new/delete вызывалось на каждом сравнении??? Выперли чудака с треском. :-(

Последних двух не знаю, а Алгол с Паскалем достаточно просты. И вообще, если в языке есть if и goto - налабать на нём можно что угодно, хоть на Фортране. :-)
(вспомнив, хихикнул) А в NATURAL'е GOTO не было, пришлось мне его самому дорисовывать. :-)

 

Рассмотрим тот же while...
Как он применяется в C и C++?
1. Для организации честного цикла. В обоих языках он избыточен. for позволяет записать то же самое и, часто, короче.
2. Для замены if (без else) в случае, когда выполнение альтернативы приводит к сбросу условия. Например, при подкачке данных. Позволяет избежать многих ошибок.
3. Многие while могут быть заменены объектами-итераторами. Методы применения итераторов в C и C++ очевидно, совершенно различны.
4. Цикл в форме do...while(0) часто применяется в качестве "усиленных" скобок блоков, например в #define.
...
По какому пункту сравнивать значение этой конструкции в разных языках?

 

Тоже факт. И намного шустрее.

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

---------- Сообщение добавлено в 13:01 ---------- Предыдущее сообщение размещено в 12:53 ----------

Не уловил. Как это? Покажи, интересно!

 

Ну, допустим, есть

Код:

if (A) B;

Есть два основных случая: выполнение B оставляет A истинным или делает его ложным.
Во втором случае естественнее применять

Код:

while (A) B;

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

 

Капец, секта. До свидания.

 

Ага, дошло, этим трюком тоже пользуюсь. Но "if ( пусто ) do { прочитать ещё; } while ( пусто )" мне нравится больше. :-)

---------- Сообщение добавлено в 13:47 ---------- Предыдущее сообщение размещено в 13:43 ----------

:-))))))))))))))

 

Вот замес пошел. Мне с моим гуманитарным мозгом, похоже тут сегодня совсем нечего делать. Мы (я и мозг) пошли рубится в Street Fighter. Вам тоже, кстати разрядка не помешает

 

DocPainkiller, как обычно:

 

Ну размер бинарников сейчас мало кого волнует.

 

Trimmer, речь не о бинарниках.

 

Тогда странно. Обычно на плюсах короче выходит. Ты о любом коде вообще или о какой-то конкретной предметной области?

 

На основании чего вывод?

Доводы против:
1. На C не надо заботиться о поддержании парадигм ООП.
2. Таблицы адресов функций занимают гораздо меньше места, чем описания методов.
3. Макросы рулят. В отличие от шаблонов нет нужды выравнивать их по границам функций.
4. Очевидную типизацию в C можно опускать.

 

Ну RAII, исключения и всё такое. Закрывать ресурсы не надо, коды ошибок не надо проверять. Ну и STL опять же. Она является частью языка, там много всего.

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

Тут я не совсем понял. Ты ООП на си пишешь?

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

В C++ можно auto поставить.

 

Вы правы, практически все (кроме (4) - auto поможет слабо) можно сделать и на C++.
Но:

1. Парадигмы ООП мешают это делать. ОО-программисты просто не понимают, как это делается. Их никто не учил нормальному программированию.
2. C-код в C++-программе выглядит так, что, как писал известный С++-писатель: "Такие вещи можно делать только накануне увольнения".
3. Если C++ "может почти то же, что и C", то нафига он нужен? Возьмите C.

Например: RAII.
С++-программист: "Как хорошо! Ресурс выделяется в конструкторе! И удаляется автоматически!"
C-программист: "Значит, я должен для каждого выделения ресурса еще и конструктор писать? И заранее учитывать в деструкторе все случаи уничтожения объекта?"
С++-эксперт: "И не забудьте, что некоторые конструкторы могут быть созданы компилятором автоматически и не знать, что им нужен ресурс".

 

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

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

На си ты тоже можешь малоком выделить ресурс который создаётся специальной функцией. И точно так же будешь неправ. И запретить это нельзя в отличии умолчальных конструкторов в C++.

Короче С++ может не только почти то же, что и Си но то, что си не может. Это помогает сделать код короче.

 

Это проблема языка, а не программистов. C++ в отличие от C не переводится в ассемблер "один в один". Слишком многое добавляется по умолчанию. И слишком многое из того, что программист вынужден писать, выкидывается (это я к тому, что программист вынужден писать заведомо ненужные для программы вещи - следовательно, программы длиннее).

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

А зачем что-то запрещать программисту? Он дурак?
Еще раз сталкиваемся с механизмом, который "можно не использовать" - а зачем он тогда нужен?

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

Я с таким не сталкивался.

 

очень спорное утверждение

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

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


тогда возникает вопрос - а стоило ли вообще колупаться с ООП ?

 

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

 

То, что С++ не переводится в ассемблер один в один, как раз следствие его лаконичности по сравнению с Си. Ну и цена за это - неизбежное повышение уровня абстракции. К счастью очень часто о том, как и что мапится в ассемблер можно не беспокоиться. Но если тебе критично, то you are not paying for you are not using.
Ты вот говоришь, что программист вынужден писать заведомо ненужные вещи, но я не совсем понимаю о чём ты. Конструкторы те же умолчальные писать не надо например.

Но вот с запретами тема интересная и пример хороший. Как в Си программист понимает, что ему надо создавать ресурс только специальной функцией? Только прочитав исходники или документацию.
В случае с С++ программа просто не будет компилироваться, если ресурс создаётся заведомо неправильным образом. Это не остановит программиста, если он действительно хочет пошалить, но предупредит, если он просто случайно ошибся.

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

Ну как же? RAII же. На строчку короче выходит, потому, что ресурс высвобождать не надо. И исключения, они ведь на ту же тему.


Ты скажи, ты о любой предметной области вообще или о чём-то конкретном?

---------- Сообщение добавлено в 01:34 ---------- Предыдущее сообщение размещено в 01:32 ----------

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

---------- Сообщение добавлено в 01:37 ---------- Предыдущее сообщение размещено в 01:34 ----------

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

 

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