согласись уже, рядом с Царем ты просто сявка.

К Царю я вообще отказываюсь приближаться.

понимаю. в горку то тяжело лезть...

Типичное заблуждение что С++-программист должен знать или знает С. Еще большее заблуждение - советовать начинать изучать С++ с С.

на пальму то тяжело лезть...

/fixed

нет поддержки виртуальных таблиц. плюс много чего ещё нет.

отучаемся писать о том, в чём ничего не понимаем...

Пользуясь случаем, хочется аннигилировать wannabe-системного программиста, который не владеет грамотной речью на родном языке.

уже пригодилась, школота. так что подумай лучше о себе.

Если до этого ничего С-подобного не знал, начинать с С ИМХО лучше, т.к. язык банально намного проще. Затем осилить С++ как «надстройку» над уже изученным будет намного проще. В принципе тут разделение на два разных языка очень условно, все это можно рассматривать в рамках одного С++, последовательно изучая разные его аспекты, начиная с функций и заканчивая шаблонами и т.д.

А по теме, «системно программирую» на С++ и лишпике. Вообще не понимаю жесткого ограничения «системное — простой язык». Главное адекватно оценивать неоходимую производительность и оверхед от более высокоуровневого языка/компилятора. На примере С и С++ этого оверхеда практически нет.

школота. так что подумай лучше о себе.

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

Вообще не понимаю жесткого ограничения «системное — простой язык»

Системное - «простой, предсказуемый и эффективный рантайм». Язык может быть и сложным.

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

Хотя я сам на плюсах в ядро ничего не писал :) Есть истории успеха?

раскрутка стека прямого отношения к крестам не имеет

это часть abi (как бы иначе отладчик со стрипнутыми бинарниками работал?). для прикладных программ это делает rtld, в ядре отладчик свой именно потому, что rtld не захотели тащить.

зыж на практике не пробовал.

А потом в С++ коде появляются уродства вроде strlen, memcpy, const char * для строк и прочее. Нет уж, если хочется С++, то надо изучать С++. В большинстве случаев С++-программисту достаточно знать С в объеме необходимом для написания врапперов для С-библиотек.

ты что prinf & scan на cin & cout поменять не можешь ?

На пальму, не на пальму, а он выше и ссыт на тебя сверху

одним вводом и выводом не обойдешься.

На пальму, не на пальму, он выше и ссыт на тебя сверху

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

Обойдешься, если считаешь факториал на локалхосте и кушаешь мамкин борщ.

Что плохого в embedded на питоне? Ну кроме самого питона.

Уродство зависит от того, к месту оно используется или нет, что в свою очередь зависит от адекватности программиста, а не от порядка его обучения. Хотя правильное место для уродств зачатую это как раз стык С и С++, соглашусь. Да и перегибов в С++-уродства ведь тоже никто не отменял, это даже более распространенное и большее зло.

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

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

Притом, что С это и есть ассемблер. Если бы ты хоть немного понимал о чём речь, то не пердел бы.

С это и есть ассемблер

О вау. Походу, ты из тех, кто всерьез воспринял фразу «Си - это переносимый ассемблер», но смог запомнить только первое и последнее слово.

Если бы ты хоть немного понимал о чём речь

Когда поймешь, чем метафора отличается от определения - заходи. А до того - в сад. Детский.

вот нафехуа страдать обработкой ексепшинов в обработчике прерываний от юарта?

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

Как мне может пригодиться раии если у меня стека 2 с половиной байта?

Мусора в коде меньше же.

любопытно. в чем же я ошибаюсь?

Ты еще жабку туда засунь, а потом плачь: "почему это у меня простой ногодрыг в 32кБ флеша микроконтроллера не влезает?".

// кстати, даже на сях надо грамотно писать: все эти "мегабиблиотечки" — жутчайшее говно, для разработки на коленке годится, но для серьезных вещей — ни в коем разе! А уж "кетайские" и "индусские" — это совсем финиш! Такого образчика тупой копипасты еще поискать надо!

ООП для свистоперделок нужно. Ему в системном программировании места нет. Зачем излишнее усложнение?

В целом правильно, ядро на шаблонах - это был бы ужоснах. Хотя, если абстрактно подойти к вопросу, то stdio использует объектное программирование. Какая разница

FILE* f=fopen("out.txt", "w");
fprintf(f, "Hello world\n!");
fclose(f);

или же (ну некий условный C++ подобный абстрактный код)

FILE* f=new FILE("out.txt", "w");
f->fprintf("Hello world!\n");
delete f;

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

ИМХО, если Страуструп откроет доступ напрямую к vtable классов, а C++ ABI стандартизируют (чтобы линковка с разными компиляторами не превращалась в ад), то преимуществ у всяких извращений в стиле GLIB просто не останется. С другой стороны, проблем такое изменение создаст значительно больше, чем существует сейчас...

Помимо объектов у ООП есть еще много каких вещей. И я уже неоднократно с пытающимися мне "доказать", что на сях тоже ООП есть, спорил, что таки тупо "объекты" — не есть ООП. Где наследование? Где полиморфизм?

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

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

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

на сях тоже ООП есть, спорил, что таки тупо «объекты» — не есть ООП. Где наследование? Где полиморфизм?

Посмотри как сделали в GLIB. ИМХО, элитный пример того что мы говорим «C++ - это кака», а при этом изобретаем не менее костыльное ООП на сишечке.

Полифорфизм - это по сути указатель на функцию. В случае с C++ указатели на функцию «скрыты» под капот и добраться до них нереально. Хз почему Страуструп это не открыл, видимо оверхеда не было, а от проблем типа «Pure virtual function call» это спасало (в стандартном C++ без перделок это кажется нельзя воспроизвести).

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

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

О да! Спроектировать ООП-программу чисто на классах у меня не разу не получилось. Но без std::vector/std::map, а также без всяких std::string/QString/QByteArray мне жизнь уже не мила :)

Алсо, в некоторых задачах без ООП (или хотя бы без объектного программирования) ну просто никак. Я с гуем много работаю, ни одной библиотеки чисто на функциях пока что не видел. Все имеют яркую склонность к ООП. Так что видимо без него никак.

Метафора? Нуну. Открой мануал по гцц и разупорись уже.

Ода! посоны, пишущие quemu такие тупые, жаль им эдди глаза не открыл раньше, они то во все поля ... Но эдди то лучше знает.

вот тебе ссылочка с наследованием и кастами.

http://code.metager.de/source/xref/qemu/include/qom/object.h

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

Хотя кому я это говорю. Прав царь..Ничтожество ты, пытающееся рассуждать о том, что только на картинках видел.

Зачем спорить?

Вы мне объясните как лучше писать код на С++?

Так:

FILE* f=fopen("out.txt", "w");
fprintf(f, "Hello world\n!");
fclose(f);

или так:

FILE* f=new FILE("out.txt", "w");
f->fprintf("Hello world!\n");
delete f;

?

спасибо за книжку.

первые два примера ясно.

Третий - нет. То есть я понял, но мне удобней писать, как в Си (с fclose, fopen и т.д).

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

Как я понимаю нету разницы писать через классы или через функции?

ниосилил понять вопроса. Через какие классы и функции? Первые 2 примера просто работают с указателями (в первом кста вместо std::scoped_ptr std::unique_ptr должен быть).

третий пример мы могли написать через fopen

брр .. я думал, что FILE это некий твой класс, а не тот, что из stdio.h.

если ты имел в виду этот, то первые 2 примера вообще работать не будут.

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

третий тоже работать не будет, да =] в общем читай книжку, лучше по самым началам.

Ну конкретно с stdio второй вариант еще придется изобрести... :) Хотя, есть вероятность, что ассемблерный код обоих вариантов получится вообще идентичным. На мой взгляд - однозначно вариант на C, т.к. иначе в проект будет втянута C++ подобная либа (или просто пара cpp/h файлов), которая никакай полезной работы не делает, а только увеличивает энтропию вселенной...

ООП обычно существенно сокращает использование кода в ключевых местах программы. Классы получаются сложными, но их использование может оказаться проще, чем писать код напрямую. Экономия в 3 строчки в ключевом месте программы приведет к паре лишних файлов с классами на 100-1000 строк в проекте (и суммарный код проекта увеличится).

Например, не вижу смысла определять свой класс для работы с сокетами просто чтобы было ООП. Но, если нужно 3-4 немного разных TCP-сервера в одной программе с немного разной логикой работы с входящими подключениями, то профит от ООП есть. Также есть профит в определении класса типа TThread, от которого нужно унаследоваться и переопределить только одну функцию run. Если потоки будут в 5 местах в программе, то это очень компактно и красиво (проще чем работать со всякими pthread_init_attr напрямую).

В принципе, вместо классов тут можно использовать функции. Но если приходится по 5 параметров передавать в функции несколько раз, или использовать указатели на CALLBACK-функции, то проще классы.

Также исключения помогают сократить код обработки ошибок при вводе/выводе. Например, стиль java при работе с исключениями мне очень понравился: ни одной ошибки ввода/вывода не будет пропущено даже случайно, после каждого вызова функции не нужно проверять результат. Код обработки будет в одном месте в except (ну может в двух местах). А проверка на ошибки и генерация исключений сделаны в самой функции. Если идет активная работа с файлом/сокетом, то намного компактнее исключения, а не if после каждого вызова. Ради такого стоит заморочится с классом (хотя он и может получится в 1000 строк).

уже проверил. всерьез принял примеры

будем читать.

Ты еще жабку туда засунь, а потом плачь: «почему это у меня простой ногодрыг в 32кБ флеша микроконтроллера не влезает?».

Ты про javacard слышал?

Слышал. Мне на БХ подсказали, когда я в теме про пхытон для МК про жабку перданул...

Не счесть количества идиотов на Шарике...

и добраться до них нереально

Добраться-то реально... Это ж С++ :) Только толку от этого немного, но если очень хочется или руки чешутся... Например, пора выстрелить в ногу, нога сама не отстрелится... Еще Саттер расказывал N способов обойти модификаторы доступа, чуть более изящные, чем тупое кастование яблок к апельсинам. И пюре виртуал калл невьехавшие в ООП в сплющеной реализации получают регулярно. (Достаточно посмотреть платиновые треды StackOverflow)

Например, не вижу смысла определять свой класс для работы с сокетами просто чтобы было ООП

Смысел обычно, чтоб не переписывать с POSIX на WSA и не засорять код оберточными макросами/вилками условной конпеляции. Да еще потом отдельно пристегивать их к epoll/iocp. Некоторые щас юзают просто boost asio и не парятся слоями абстрагирования от конкретной реализации. (И еще ждут затаскивания этого в std :) Потоки уже там, чо, пусть сокеты и io тоже будут)

Открой исходники gcc и просвещайся.

Учи матчасть, сынок. В жизни пригодится.