А был ли мальчик? (помянем плюсы)

[OtherSide]

В теории плюсы красивый язык, и вообще писал на них много, но положа руку на сердце на чистых плюсах писал в основном на собеседованиях.
А на самих проектах почти всегда был си с классами. То помню под какую-то плату писал, а там не было нормального компилятора, то заходил в древние проекты, там большая часть на чистом си, часть дописывалась под плюсы, то писал middleware библиотеку, что бы оно нормально линковалось над плюсами была обертка на Си, получалось писали почти что на Си. В общем с 2000 по 2010 все жил в надеждах когда дадут развернутся писать красивый код, пока он благополучно не издох.
Несколько лет назад волею судеб с месяцок писал на плюсах, оказалось что в стандарте нет элементарных вещей, к которым привык на шарпе. Была какая-то простецка задача со строками, оказалось не в стандарте, пришлось подтягивать Буст. Буст с разбегу не билдился, потом пошли какие-то конфликты с другими модулями, в общем плюнул и написал за 10 минут работу со строками в c-style.
В общем мысль, что плюсы погубила совместимость с си, по хорошему на плюсах в ООП стиле оч. редко писали.
Или это только мне так "повезло"?

[StrangerR]

Еще в лохматые годы, у нас один чудак переписал прозрачную легко понимаемую программу с C на C++. Потом он ушел, и мы сели ее модифицировать...

Короче, разобраться не удалось, пришлось уконтрокупить (и написать на скриптовом языке). Ну и плюс к тому в стандарте C++ нету массы нужных вещей, а если еще и в тред компатибилити лезть, то только ахать и охать остается...

[M. Ridcully]

Буст это практически как расширенная стандартная библиотека. Если в компании чего-то своего нет, то абсолютно кошерно использовать.
Кстати, разве библиотеку строковых алгоритмов нужно билдить? Я думал, она header-only. Но может и ошибаюсь...

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

[f_evgeny]

Мне тут пришлось тоже в плюсы залезть. Нузно было одну библиотечку с Cython подружить. Хорошо бы если бы это были просто плюсы в библиотеке, а там еще на разных новомодных улучшениях типа C++11, а заголовков в Cython к таким новостям половины нет. В общем пришлось бросить. Но ужаснуться я успел.

[Мальчик-Одуванчик]

Вот поэтому так мало индусни, пишущей на плюсах.

[M. Ridcully]

Вот поэтому так мало индусни, пишущей на плюсах.

Да ну, мало.
Полно.

[Мальчик-Одуванчик]

Вот поэтому так мало индусни, пишущей на плюсах.

Да ну, мало.
Полно.

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

[M. Ridcully]

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

Зато у румынов с метапрограммированием всё в порядке!

Только осмелюсь предположить, что это метапрограммирование на практике нужно не больше, чем Хаскель. Был у меня опыт - как-то пришлось в паре проектов парсить кое-что. Первый раз решил использовать это самое метапрограммирование - Boost Spirit. Так себе удовольствие (есть тут блюющий смайлик?). Второй раз решил ошибку не повторять и сделать честную, выделенную стадию для парсенья и кодогенерации, с использованием pyparsing. Так на контрасте - небо и земля.
Так что моя скромная имха - это самое метапрограммирование есть не что иное, как курьёз и использование средств не по назначению. И самое главное - fucking ugly!

И если уж зашла речь о Хаскеле. Там чуток по-другому. Вот из практических соображений, тоже не могу никак оправдать использование. Но так хочется! Ибо, в отличие от метапрограммирования, эстетически как раз очень привлекательная штука. То есть буквально, хочется найти предлог его использовать.

[Мальчик-Одуванчик]

Так что моя скромная имха - это самое метапрограммирование есть не что иное, как курьёз и использование средств не по назначению. И самое главное - fucking ugly!

А у меня наоборот - специализация шаблонных классов и функций давно уже превалирует в написании кода.
Ну и вариадики сильно заценил.

[M. Ridcully]

Так что моя скромная имха - это самое метапрограммирование есть не что иное, как курьёз и использование средств не по назначению. И самое главное - fucking ugly!

А у меня наоборот - специализация шаблонных классов и функций давно уже превалирует в написании кода.

А какая компания, или хотя бы предметная область?
Можно в личку.
Также интересно, сколько за это платят.

[Medium-rare]

В общем мысль, что плюсы погубила совместимость с си, по хорошему на плюсах в ООП стиле оч. редко писали.
Или это только мне так "повезло"?

* В C++, как C с классами, нет ничего плохого. Но порядок в коде без лишнего напряжения, если есть хорошая композиция объектов в дизайне.
* Трудно сказать, что C++ это есть C с классами, когда применяются templates, ибо их нет в C. Standard Template Library теперь просто неотъемлимая часть языка C++, и её большая часть C++ программистов, или другую template library, или свои собственные templates используют. Или (чаще) более одной.
* Вам не повезло.

std::vector<std::string> vctOfStrings; // уже точно никакой не C

[StrangerR]

Я весьма немного сам писал на C++, и побольше разбирался в чьем то коде. Темплейты - хороший способ запутать все насмерть.

[Мальчик-Одуванчик]

Я весьма немного сам писал на C++, и побольше разбирался в чьем то коде. Темплейты - хороший способ запутать все насмерть.

Это только с непривычки.

[StrangerR]

Я весьма немного сам писал на C++, и побольше разбирался в чьем то коде. Темплейты - хороший способ запутать все насмерть.

Это только с непривычки.

Отладчик тоже непривыкший, как выясняется. Как и кодоанализаторы. А так _все хорошо прекрасная маркиза_.

Хотя и считается, что в конкурсе на самую нечитабельную программу побеждает обычно Перл, я бы все таки C++ отдал первое место. Учитывая возможность скомбинировать темплейты, классы и инклюды с CPP и запутать всех окончательно...

[Мальчик-Одуванчик]

Я весьма немного сам писал на C++, и побольше разбирался в чьем то коде. Темплейты - хороший способ запутать все насмерть.

Это только с непривычки.

Отладчик тоже непривыкший, как выясняется. Как и кодоанализаторы. А так _все хорошо прекрасная маркиза_.

Хотя и считается, что в конкурсе на самую нечитабельную программу побеждает обычно Перл, я бы все таки C++ отдал первое место. Учитывая возможность скомбинировать темплейты, классы и инклюды с CPP и запутать всех окончательно...

Был когда-то язык Форт, программы на котором казались мне ужасно нечитабельными, постоянно приходилось вникать что же я такое наваял на нем еще буквальео вчера. А что сложного в плюсовом отладчике мне не совсем понятно, разве что gdb выглядит несколько неудобным при работе с командной строкой.

[AndreyT]

В общем мысль, что плюсы погубила совместимость с си, по хорошему на плюсах в ООП стиле оч. редко писали.

В C++ нет никакой совместимости с С и никогда не было (кроме замшелых времен "C with classes"). Миф о совместимости C++ с С существует только в головах студентов, которые не сумели изучить ничего больше, чем какое-то куцее С-подобное подмножество С++, да и то знают плохо. Схожесть С и С++ существует только на уровне syntactic sugar и общих деталей абстрактной платформы, но семантики этих языков различаются фундаментально, причем с самого начала стандартизованных времен.

[Мальчик-Одуванчик]

Под совместимостью наверное имеется ввиду что С в целом является подмножеством С++ и программа, написанная на С, будет компилироваться средой С++. Понятно, что стандарт 97 года устанавливает эту совместимость не абсолютной.

[Andriy777]

Я весьма немного сам писал на C++, и побольше разбирался в чьем то коде. Темплейты - хороший способ запутать все насмерть.

Я немного сам говорил по французски и больше разбирался что говорили. Лягушатники, что скажешь?

Sent from my Nexus 6P using Tapatalk

[Pantigalt]

* В C++, как C с классами, нет ничего плохого. Но порядок в коде без лишнего напряжения, если есть хорошая композиция объектов в дизайне.
* Трудно сказать, что C++ это есть C с классами, когда применяются templates, ибо их нет в C. Standard Template Library теперь просто неотъемлимая часть языка C++, и её большая часть C++ программистов, или другую template library, или свои собственные templates используют. Или (чаще) более одной.
* Вам не повезло.

std::vector<std::string> vctOfStrings; // уже точно никакой не C

+100 про темплейты.
По сути ООП в классическом виде в С++ не нужно.

1. Наследование в топку. Используем аггрегацию.
2. Полиморфное поведение экземпляров классов за счёт использования виртуальных методов в топку
2. Инкапсуляция по сути тоже не особо нужна (we are adults here).

Мне лично нравится идея использовать Микс-ыны.
Вместо классов использовать только структуры как контейнеры или для RAII-поведения.

[AndreyT]

Под совместимостью наверное имеется ввиду что С в целом является подмножеством С++ и программа, написанная на С, будет компилироваться средой С++.

Понятно, что без необходимости от этого отступать не хотели. Но уже с самого первого стандарта С++ (С++98) такой совместимости не было в целом ряде деталей. А на уровне семантики выражений различия сразу были фундаментальные: С - lvalue-discarding язык, С++ - lvalue-preserving язык.

[M. Ridcully]

А на уровне семантики выражений различия сразу были фундаментальные: С - lvalue-discarding язык, С++ - lvalue-preserving язык.

Вот блин, как же я жил то до сих пор без таких фундаментальных знаний!

[Medium-rare]

1. Наследование в топку. Используем аггрегацию.

* Template: если базовый тип коллекции мутирует. wrapper для указателя и т.п.
* Inheritance: если вам нужна большая заготовка со сложным предопределённым поведением, как элемент UI, в котором надо переопределить сколько-то хэндлеров, и чем дольше пишете этот UI, тем обычно, больше. Иначе что? Возьмёте такой template с десятком, а то и сотней параметризующих типов?

Вот в Qt есть и то, и другое. Хотя они сами говорят, вместо наших контейнеров и врапперов используйте уже один STL. А всё остальное, если C++ код писать - то наследовать от их базы, а то как ещё? Помню такой фреймворк WTL майкрософтовский, тимплейтный UI, ага. Так он хорош "отсюда до сюда", и если что, писать-непереписать.

[AndreyT]

А на уровне семантики выражений различия сразу были фундаментальные: С - lvalue-discarding язык, С++ - lvalue-preserving язык.

Вот блин, как же я жил то до сих пор без таких фундаментальных знаний!

Это нормально. И в С, и в С++ хватает людей, знающих эти языки на уровне Машины Тьюринга: указатель, `++`, `--` и прочитать/записать. И таки живут как-то.

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

[Мальчик-Одуванчик]

Вместо классов использовать только структуры как контейнеры или для RAII-поведения.

Кортежи (tuples) тоже удобны в этом плане.

[M. Ridcully]

А на уровне семантики выражений различия сразу были фундаментальные: С - lvalue-discarding язык, С++ - lvalue-preserving язык.

Вот блин, как же я жил то до сих пор без таких фундаментальных знаний!

Это нормально. И в С, и в С++ хватает людей, знающих эти языки на уровне Машины Тьюринга: указатель, `++`, `--` и прочитать/записать. И таки живут как-то.

Ну не всем же быть в top 0.03% on SO

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