Практикуете ли вы смешение С и С++?
| |
Saitei | Дата: Воскресенье, 19 Июля 2015, 17:55 | Сообщение # 1 |
старожил
Сейчас нет на сайте
| И почему? Довольно любопытно услышать ваши мнения на этот счёт
|
|
| |
harmoxyne | Дата: Воскресенье, 19 Июля 2015, 18:19 | Сообщение # 2 |
заслуженный участник
Сейчас нет на сайте
| Да, использую printf в C++, ибо уже привык к форматированию.
|
|
| |
Gudleifr | Дата: Воскресенье, 19 Июля 2015, 19:03 | Сообщение # 3 |
почти ветеран
Сейчас нет на сайте
| Ни разу не видел "программы на C++" (кроме примеров). Обычно попадались программы на "плохом C" c "элементами C++" (позднее многие из них узаконили в C): 1. //-комментариями 2. избыточной типизацией 3. stl-функциями 4. заменой struct на class 5. использованием ОО-библиотек и все... Как пример "научно обоснованного" C-использования C++ см, например, исходники Linux.
Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
|
|
| |
Jhon | Дата: Понедельник, 20 Июля 2015, 11:50 | Сообщение # 4 |
частый гость
Сейчас нет на сайте
| Использую директиву препроцессора #include и делаю защиту от множественного вложения (include guard). Совсем от сишного препроцессора избавиться не получается. Хотя конкретно эти вещи не мешают.
|
|
| |
harmoxyne | Дата: Вторник, 21 Июля 2015, 10:06 | Сообщение # 5 |
заслуженный участник
Сейчас нет на сайте
| Цитата Jhon ( ) Использую директиву препроцессора #include Мне кажется, или весьма нелогично относить это сюда, ведь это крайне весомая часть как С, так и С++?
|
|
| |
Jhon | Дата: Вторник, 21 Июля 2015, 10:40 | Сообщение # 6 |
частый гость
Сейчас нет на сайте
| Цитата harmoxyne ( ) Мне кажется, или весьма нелогично относить это сюда, ведь это крайне весомая часть как С, так и С++? Препроцессор - это пережиток Си, а в C++ есть альтернатива любому применению препроцессора кроме подключения заголовочных файлов, поэтому приходится им пользоваться. Так что все очень логично, но бессмысленно - полезной информации мое прошлое сообщение не несет, с этим согласен.
|
|
| |
Gudleifr | Дата: Вторник, 21 Июля 2015, 11:04 | Сообщение # 7 |
почти ветеран
Сейчас нет на сайте
| Цитата harmoxyne ( ) это [#include] крайне весомая часть как С, так и С++? Все зависит от того, в каких целях его (и препроцессор в целом) используют. Возможно: 1. Тупо сократить число букофф 2. Обеспечить некую подстройку/переносимость 3. Для самодокументированности/структурирования 4. В качестве дырки, позволяющей засунуть в язык "инновации" (например, те же template) 5. "Нада!" ...
Не надо забывать, что изначально C был языком для написания простеньких программ-комманд для UNIX и главным было (1). И даже (2) не особенно раздражало. С усложнением же задач программирования (требованием 100%-защиты от дурака-системного-программиста), доля обязательных танцев с бубном выросла неимоверно и препроцесор играет в них не последнюю роль. Он, как вера православная, стал внешней силой, диктующей стиль программирования. Что в C++ часто смотрится атавизмом.
Однажды искал в исходниках Linux какую-то переменную, имя которой состояло букв этак из 30-и, пришлось просмотреть, с того места, где эта переменная была определена, 6 файлов, чтобы, наконец выяснить, что это просто макрос "*(некий_полезный_адрес+2)". Это, конечно, для больших C и C++ программ норма (даже обоснованная норма), но цена такого стиля программирования - полная потеря управляемости кода.
Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
Сообщение отредактировал Gudleifr - Вторник, 21 Июля 2015, 11:11 |
|
| |
rrrfer | Дата: Воскресенье, 26 Июля 2015, 07:41 | Сообщение # 8 |
частый гость
Сейчас нет на сайте
| З У Маерса (чувак из комитета стандартизации С++) первый совет (из 55) - "относитесь к С++ как к конгломерату языков". Там все написано, что, зачем и почему. У Страуструпа есть фраза, что Си - это часть С++, оставленная для понижения порога входа (чтобы было проще переходить с Си). Т.е. это две части одного языка, они уже соединены исторически и по объективным причинам.
4. заменой struct на class Заменой мягкого на теплое? Мало того, что у этих ключевых слов настолько разное назначение, что заменять тут что-то наивно, дак еще и как же нам быть с битовыми полями, например? (или на С++ мы не должны их использовать? xD)
|
|
| |
Gudleifr | Дата: Воскресенье, 26 Июля 2015, 10:22 | Сообщение # 9 |
почти ветеран
Сейчас нет на сайте
| Цитата rrrfer ( ) Т.е. это две части одного языка, они уже соединены исторически и по объективным причинам. Это заблуждение. Языки похожи, но способы программирования абсолютно разные.
Цитата rrrfer ( ) Мало того, что у этих ключевых слов настолько разное назначение Разное. Но обычно для "перехода с C на C++" просто облыжно меняют одно на другое, без понимания этой разницы.
Если кратко, то невзирая на языковые фичи, золотое правило кодирования никто не отменял. Оно гласит:
1. Лучше всего нужную штуку просто вычислить. 2. Если ее нельзя просто вычислить, используй таблицы. 3. Если таблица не получается, используй if-ы и switch-и.
Язык C сделал шаг в сторону отказа от (3): макросы, расширенный набор операций вычисления, нестрогая типизация, адресная арифметика. Все это расширяет возможности вычисления и табулирования. С++ заявил о готовности отказа и от (2) - любое сложное действие можно инкапсулировать (спрятать от программиста не только его логику, но и таблицы). Однако, людей, готовых отказаться от if-ов и switch-ей очень мало, поэтому им что C, что C++... Они, наоборот, требуют введения новых условий (например, динамической проверки типа) или структурностей (исключений, имен пространств...).
Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
|
|
| |
rrrfer | Дата: Воскресенье, 26 Июля 2015, 11:15 | Сообщение # 10 |
частый гость
Сейчас нет на сайте
| Цитата Это заблуждение. Языки похожи, но способы программирования абсолютно разные. Я сослался на Страуструпа и на Маерса.
Маерс пишет (почти цитирую): Цитата в С++ 4 подъязыка: Си, объектно-ориентированный С++, С++ с шаблонами, STL Мы все знаем что это за люди, а кто ты такой, чтобы утверждать что чувак из комитета стандартизации и автор языка "заблуждаются"? )
Цитата Разное. Но обычно для "перехода с C на C++" просто облыжно меняют одно на другое, без понимания этой разницы. Кто так обычно делает?, откуда инфа что кто-то так вообще делает? Вопросы про битовые поля ты не заметил или проигнорировал? А что делают с union при переходе от Си к С++?
Цитата Если кратко, то невзирая на языковые фичи, золотое правило кодирования никто не отменял. Оно гласит: Это "золотое правило" ты сам придумал? - если нет, дай пруф, т.к. гугл такого "правила" не знает ))
|
|
| |
Gudleifr | Дата: Воскресенье, 26 Июля 2015, 11:52 | Сообщение # 11 |
почти ветеран
Сейчас нет на сайте
| rrrfer, пиписькометрией не занимаюсь. Сомневаетесь в том, что я пишу, проведите свой анализ.
Цитата rrrfer ( ) Маерс пишет... Именно, большинство людей воспринимают именно C++ так. Отсюда и смешение C и C++. Страуструп: " Чем лучше программист знает С, тем труднее будет для него при программировании на С++ отойти от стиля программирования на С".
Цитата rrrfer ( ) Кто так обычно делает?, откуда инфа что кто-то так вообще делает? Рассмотрим простейший пример. Даже не на C++, а на Python. Просто. чтобы не повторять одно и то же (см. в разделе "УСЛОЖНИТЕЛИ"). Пересчитайте классы сами. Много из них тех, что по своим возможностям выходят за рамки обычных struct? Причем, даже в обычном C такие структуры (временные буфера привязанные к конкретным операциям) нафиг ненужны.
Цитата rrrfer ( ) Вопросы про битовые поля ты не заметил или проигнорировал? Проигнорировал. Они к делу не относятся.
Цитата rrrfer ( ) А что делают с union при переходе от Си к С++? Повторю: речь не о том, что "что-то переносится хуже или лучше", а о том, что C++-кодеры в большинстве не воспринимают классы иначе, чем просто "структуры с удобными встроенными конструкторами". Поэтому "все С++ программы, которые я видел..." Далее - по тексту первого поста.
Цитата rrrfer ( ) Это "золотое правило" ты сам придумал? Доходчивее всего его описал Броуди в книге "Думаем на FORTH".
Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
|
|
| |
Xakep | Дата: Воскресенье, 26 Июля 2015, 15:48 | Сообщение # 12 |
めちゃくちゃちゃ
Сейчас нет на сайте
| Раньше использовал Си с классами, когда только начал на нем программировать, год назад где-то может меньше начал разбираться когда с новым стандартом С++14 перестал так делать ) из Си пока что использую не безопасное преобразование типов.
|
|
| |
rrrfer | Дата: Воскресенье, 26 Июля 2015, 16:53 | Сообщение # 13 |
частый гость
Сейчас нет на сайте
| Цитата речь не о том, что "что-то переносится хуже или лучше", а о том, что C++-кодеры в большинстве не воспринимают классы иначе, чем просто "структуры с удобными встроенными конструкторами" Поправка С++-говнокодеры, тогда дальше все верно. Структуры в Си было нельзя наследовать, в С++ их можно наследовать, они могут содержать конструкторы и прочее. Если С++-кодеры в большинстве воспринимают это иначе - это их личные проблемы.
Цитата Проигнорировал. Они к делу не относятся. Они относятся, т.к. битовые поля задаются при помощи того же ключевого слова struct, но ты писал: Цитата 4. заменой struct на class
Цитата Чем лучше программист знает С, тем труднее будет для него при программировании на С++ отойти от стиля программирования на С Хорошая цитата, только ИМХО понимать ее надо не так прямо как вы это сделали. Страуструп говорит про СТИЛЬ программирования. Все в той же книге (и во многих других книгах, в т.ч. у Г. Буча) используется термин "процедурное мышление" и причина не в Си, а в том, что программист на Си, паскале, фортране, старых версиях пхп и т.д. и т.п. привыкает решать задачи в процедурном стиле. Затем начав использовать ОО язык он по прежнему пытается применить старые подходы, только если в чисто ОО языках типа джавы и шарпа это сделать сложнее (но тоже можно), то в С++ этот сделать очень легко, т.к. Страуструп сохранил частичную обратную совместимость с Си для снижения порога входа (про это он пишет в "Язык программирования С++", по крайней мере в издании 1999 года). Но суть не в Си, а процедурном мышлении, на это намекает фраза СТИЛЬ программирования С. Я думаю Страуструп ничего не имеет против структур, которые вы предлагаете заменять классами. Потому что например если по сети мне приходят данные в определенном формате, то для их разбора я использую структуры или битовые поля - никакие классы эту задачу не решают.
|
|
| |
Gudleifr | Дата: Воскресенье, 26 Июля 2015, 17:06 | Сообщение # 14 |
почти ветеран
Сейчас нет на сайте
| Цитата rrrfer ( ) Они относятся... Повторяю: речь не о том, что "что-то переносится хуже или лучше", а о том, что C++-кодеры в большинстве не воспринимают классы иначе, чем просто "структуры с удобными встроенными конструкторами". Цитата rrrfer ( ) Поправка С++-говнокодеры... Других не видел. Не видел ни одной "боевой" C++ программы, в которой бы классы рассматривались не как (навязанные свыше) кирпичи для построения кода, а как части "информационной модели вселенной", чего требовали Страуструп, Парнас и другие теоретики ООП. Цитата rrrfer ( ) Страуструп говорит про СТИЛЬ программирования... Я тоже. В xxx-надцатый раз повторяю: не видел ни одной серьезной программы, написанной в ОО-стиле. Только "процедурные". (Если уж на то пошло, видел единственную действительно структурную серьезную программу: TeX Кнута).
Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
|
|
| |
rrrfer | Дата: Воскресенье, 26 Июля 2015, 17:10 | Сообщение # 15 |
частый гость
Сейчас нет на сайте
| Цитата Цитата Это "золотое правило" ты сам придумал? Доходчивее всего его описал Броуди в книге "Думаем на FORTH".
Гугл по запросу "Думаем на FORTH золотое правило " без кавычек выдает: Цитата Золотое правило гуманизма гласит: не делай другим того, чего не хочешь, чтобы делали тебе Цитата Золотое правило морали известно с древнейших времен в различных формулировках. На основе философской концепции золотого правила, можно Цитата Библия | От Матфея 7 (King James Version)
И так далее, что угодно, но никак не то, что привел тут ты. Если есть возможность, приведи цитату из книги целиком. У меня большие сомнения, что в приличной книге могут быть слабоформализованные "просто вычислить" и т.п. О каких таблицах идет речь - тоже не понятно, ты пишешь, что на С++ можно "спрятать не только логику, но и таблицы". В стандарте С++ вообще нет такого термина как таблица.
В "золотом правиле" как-то странно используется термин табулирование. В интернете этому понятию вообще нормального описания не найдешь, т.к. студентам регулярно дают задачи типа "протабулировать функцию на интервале", но реально термин использовался в лохматых годах для обозначения техники программирования, когда вычисленные на некотором шаге результаты могут потребоваться в будущем (поэтому их накапливают чтобы потом не вычислять повторно).
Дак вот возвращаюсь к "золотому правилу": Цитата "макросы, расширенный набор операций вычисления, нестрогая типизация, адресная арифметика. Все это расширяет возможности вычисления и табулирования." Каким образом нестрогая типизация и адресная арифметика расширяет возможности табулирования?
|
|
| |
Xakep | Дата: Воскресенье, 26 Июля 2015, 17:18 | Сообщение # 16 |
めちゃくちゃちゃ
Сейчас нет на сайте
| Цитата Gudleifr ( ) что C++-кодеры в большинстве не воспринимают классы иначе, чем просто "структуры с удобными встроенными конструкторами". Новички наверное, то что ты общался только с новичками это же не значит что опытные программисты будут так воспринимать С++.
Цитата Gudleifr ( ) Других не видел. Не видел ни одной "боевой" C++ программы, в которой бы классы рассматривались не как (навязанные свыше) кирпичи для построения кода, а как части "информационной модели вселенной", чего требовали Страуструп, Парнас и другие теоретики ООП. UE4 как минимум.
|
|
| |
rrrfer | Дата: Воскресенье, 26 Июля 2015, 17:19 | Сообщение # 17 |
частый гость
Сейчас нет на сайте
| Цитата Не видел ни одной "боевой" C++ программы, в которой бы классы рассматривались не как (навязанные свыше) кирпичи для построения кода, а как части "информационной модели вселенной", чего требовали Страуструп, Парнас и другие теоретики ООП. Про части информационной модели вселенной впервые прочитал у тебя. Даже самые упоротые теоретики ближе к земле. Не видел ни одной программы, ну посмотри тут: http://sourceforge.net/directory/developmentstatus:production/language:cpp/os:linux/freshness:recently-updated/
Среди прочих, например, буст (это не программа, а библиотека, но более чем "боевая"). Там очень много примеров.
Я, кстати, ниразу не видел чтобы заменяли struct на class чтобы перенести программу на С++. Т.к. в С++ ключевое слово struct тоже работает, зачем что-то заменять даже если программист сошел с ума?
|
|
| |
Xakep | Дата: Воскресенье, 26 Июля 2015, 17:23 | Сообщение # 18 |
めちゃくちゃちゃ
Сейчас нет на сайте
| Цитата rrrfer ( ) О каких таблицах идет речь - тоже не понятно, ты пишешь, что на С++ можно "спрятать не только логику, но и таблицы". Заранее предрасчитанные значения, это же очевидно
Цитата Gudleifr ( ) 1. Лучше всего нужную штуку просто вычислить. 2. Если ее нельзя просто вычислить, используй таблицы. 3. Если таблица не получается, используй if-ы и switch-и.
думаю это правило было сформулировано очень давно, когда машины только занимались математическимим вычислениями, как в пример Gudleifr, все нормально привел, мысль свою выразил хорошо, какие-то не уместные наезды.
|
|
| |
Gudleifr | Дата: Воскресенье, 26 Июля 2015, 17:33 | Сообщение # 19 |
почти ветеран
Сейчас нет на сайте
| Цитата rrrfer ( ) Если есть возможность, приведи цитату из книги целиком. Там это формулируется как "СОВЕТ" в [url="http://www.gudleifr.h1.ru/cgi-bin/pilo.cgi?FL=../g9.txt&IS=\6.PERWOISTOTNIKI\LEO%20BRODIE%20THINKING%20FORTH\04.DETALISIROWANNAA%20RASRABOTKA/RESENIE%20SADATI"]4-й главе[/url]: (Пардон, ссылки не по зубам этому форуму, попытайтесь копипастить).
"При выборе того, какой подход применить к решения задачи, отдавайте свое предпочтение в следующем порядке: 1. вычисления (кроме случаев, когда существенна скорость) 2. структуры данных 3. логика". Но сама задача, приводящая к этому выводу решается во [url="http://www.gudleifr.h1.ru/cgi-bin/pilo.cgi?FL=../g9.txt&IS=\6.PERWOISTOTNIKI\LEO%20BRODIE%20THINKING%20FORTH\02.ANALIS"]второй[/url]. Золотым же я это правило называю потому, что еще не видел ни одного опытного программиста, который бы при его упоминании не произнес: "Я всегда это говорил".
Цитата rrrfer ( ) Каким образом нестрогая типизация и адресная арифметика расширяет возможности табулирования? Во-первых, под "табулированием" в данном случае я понимаю сведение управляющей информации в таблицы, позволяющей избежать лишних if-ов. Самый известный пример: замена жуткого switch-а, распознающего Win-сообщения, двумя таблицами - по msg- и ctrl-кодам.
Что дает нестрогая типизация? Во-первых, возможность совмещения логических, числовых и битовых выражений (это, понятно, (1)), во-вторых, есть возможность указания в таблицах адресов функций с произвольным числом параметров (это уже, понятно (2)) и , разумеется, опять чисел, флагов, шкал...
Почему для (2) удобна адресная арифметика? Очевидно: я могу в управляющей таблице передать не только адрес ф-ии, но данные любой сложности (через указатель).
Цитата rrrfer ( ) Про части информационной модели вселенной впервые прочитал у тебя. Почему же. См. у Страуструпа, например, в главе "Проектирование и развитие". Или, у японцев, в их многотомниках по машинам пятого поколения. Например, в томе "Языки программирования и схемотехника СБИС" (там про SmallTalk). Огульную оценку влияния ООП на программирование можете посмотреть в поздних изданиях "Человеко-месяца" Брукса".
Цитата rrrfer ( ) посмотри тут: Вы сами себе противоречите. Заявляете, что классический ООП не существует иначе, чем в моем воображении, а затем утверждаете, что есть куча примеров. Определитесь уж как-нибудь.
Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
Сообщение отредактировал Gudleifr - Воскресенье, 26 Июля 2015, 17:47 |
|
| |
rrrfer | Дата: Воскресенье, 26 Июля 2015, 19:47 | Сообщение # 20 |
частый гость
Сейчас нет на сайте
| Цитата Или, у японцев, в их многотомниках по машинам пятого поколения. Японцы вроде как развивали логическую парадигму к компьютерам пятого поколения. ООП они вроде как вообще не касались. Если я не прав - дайте пруфлинк.
Цитата См. у Страуструпа, например, в главе "Проектирование и развитие" Я открыл главу 11, пролистал ее целиком. Искал по части слова всел-енная - ничего нет. Очевидно, Страуструп не пишет в этой главе "Про части информационной модели вселенной". Ты дал недостоверный пруфлинк.
Цитата Вы сами себе противоречите. Заявляете, что классический ООП не существует иначе, чем в моем воображении, а затем утверждаете, что есть куча примеров.
Процитируйте меня, где я "сначала заявляю", а "затем утверждаю". Я говорил о том, что ни о каких "моделях вселенных" в ООП речи не идет. И что ваши представления об ОО-программах, как о программах в которых struct заменили на class ничего общего с реальностью не имеют. Затем скинул ссылку на открытые проекты, в которых ООП используется правильно.
По поводу "золотого правила", сравни то, что ты написал вначале с тем, что процитировал позже: Цитата 1. Лучше всего нужную штуку просто вычислить. 2. Если ее нельзя просто вычислить, используй таблицы. 3. Если таблица не получается, используй if-ы и switch-и.
Цитата При выборе того, какой подход применить к решения задачи, отдавайте свое предпочтение в следующем порядке: 1. вычисления (кроме случаев, когда существенна скорость) 2. структуры данных 3. логика"
Структуры данных - это не (не только) таблицы, это массивы, списки, хеш-массивы, всевозможные деревья и т.п. Речь в оригинале шла о том, что если твое решение работает не достаточно эффективно (на это указывает приписка в скобках к первому пункту) - то можно попробовать применить другие структуры данных. Что автор имел ввиду под логикой я не знаю, но вагную, что предлагал поискать вкорне другой подход к решению задачи если никакая структура данных не дала нужного ускорения. И таки да, что-то такое можно найти у Брукса и многих адептов TDD, например. С этим трудно не согласиться, но это не имеет никаокго отношения к тому, что изначально ты писал (табулирование можно притянуть, но не более).Добавлено (26 июля 2015, 19:44) ---------------------------------------------
Цитата Во-первых, под "табулированием" в данном случае я понимаю сведение управляющей информации в таблицы, позволяющей избежать лишних if-ов. Самый известный пример: замена жуткого switch-а, распознающего Win-сообщения, двумя таблицами - по msg- и ctrl-кодам.
Что дает нестрогая типизация? Во-первых, возможность совмещения логических, числовых и битовых выражений (это, понятно, (1)), во-вторых, есть возможность указания в таблицах адресов функций с произвольным числом параметров (это уже, понятно (2)) и , разумеется, опять чисел, флагов, шкал...
Почему для (2) удобна адресная арифметика? Очевидно: я могу в управляющей таблице передать не только адрес ф-ии, но данные любой сложности (через указатель).
Я выше писал что такое табулирование. Примерно тоже самое написал Xakep. - Это значения, которые вычислены заранее (или на предыдущих шагах алгоритма). Например это могли бы быть таблицы Брадиса или типа того. Т.е. При табулировании формируется массив с константами. Типа того:
Код tab[i] = f(x, tab, i);
Ну а функция f при вычислении очередного значения использует то, что сохранено при табулировании - банально обращается к элементам массива tab по индексам. Никакая нестрогая типизация тут ничего не даст дополнительного, как и адресная арифметика. Суть табулирования, как метода я описывал выше, уже пример привел.Добавлено (26 июля 2015, 19:47) --------------------------------------------- Но вцелом тема надоела. Соглашаюсь с вами, я ошибался, спасибо что открыли мне глаза (иначе бы прожил всю жизнь в заблуждении).
Сообщение отредактировал rrrfer - Воскресенье, 26 Июля 2015, 19:37 |
|
| |
|