С++ с основ.

[yigal_s]

В С++ плохо всё, с самых самых безобидных, казалось бы, основ.

Вот, например, конструктор:

MySuperExtraordinaryClass::MySuperExtraordinatoryClass()
{
}

Стоп машина! Чтобы понять, что это конструктор, необходимо прочитать два слова и убедиться, что они совпадают! Поздравим создателей языка с тем, что они сэкономили ключевое слово - "constructor"

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

Теперь, пожалуй, попробуем какие-нибудь конструкторы использовать. Ну, например, конструкторы стандартной библиотеки.

const char *buf="С++ is marvelous";
std::string s1(buf);
std::string s2(buf, 2); //гммм...
std::string s3(buf, 3, 2); //блять, что это?
std::string s4('2', 5); //а это что?


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

Убей же С++ программиста в себе.

Comments

[dima-stat.livejournal.com]

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

а смысл читать декларацию класса, не зная что это за класс?

но вообще, конечно, во времена страуструпа всё было маленьким, классы тоже..

[yigal_s]

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

Можно даже знать что за класс - и всё равно придется тратить время (пусть даже 2 десятых секунды), чтобы сообразить, что перед тобой конструктор, а не функция, не возращающая тип )))

[dima-stat.livejournal.com]

функция не возвращающая тип -- обязана возвращать войд. по крайней мере так было.

[yigal_s]

чисто синтаксически, конструктор в С++ - функция, которая ничего не возвращает. )))

И это опять же, нечто, что нужно помнить, когда глаза бегут по коду.

[dima-stat.livejournal.com]

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

[yigal_s]

как раз сначала никаких проблем нет вообще.

проблема - когда это приходится делать из года в год )))

[ak_47]

Да таких примеров можно вагон легко напридумывать. То что параметры могут иметь дефолтное значение, но места их жёстко заданы, потому что нет, как в Пайтоне, например, named parameters - вот и начинаются извращения с overloading.

Outdated pile of crap.

[yigal_s]

если не хочешь, можно дефолт параметров не писать.

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

[ak_47]

Дык в том-то и дело что часто хочу, но надо выкручиваться, т.к. они могут быть только в конце сигнатуры. Да ещё и старый код не всегда можно менять.

С конструкторами не прошло и 30 лет, наконец сделали inheritance and delegation. Пока я это на работе увижу - наверное ещё 20 лет пройдёт.

Я согласен с ЙосефК на 98%. Ц++ должен быть разрушен.

[yigal_s]

" часто хочу, но надо выкручиваться"

не вполне понял суть проблемы.

Ну а лично я по возможности параметрами по-умолчанию пытаюсь не пользоваться в С++ - ибо гемор это страшный.

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

Да, пора этот С++ на свалку, пора )))

[ak_47]

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

Если среди этого есть дефолтные параметры,то согласен, наступает гемор ещё больший.

В Пайтоне сделали очень красиво. Без явных имён параметров они передаются в том порядке как объявлены в сигнатуре. А с явными именами в вызове можно некоторые указывать, а некоторые пропустить. И никаких overloads не надо, ни балета с позицией параметров.

В бусте это как всегда обшли тремя тоннами темплейтов, но снаружи вроде выглядит приемлемо. Насколько вообще может быть приемлимо в С++. Т.е., конечно же мрак и ужас, но мы и не такое видали.

Вот что им мешало сделать named parameters ещё 20 лет назад, когда и дефолтные уже были и весь гимор с ними был очевиден? Правильно, мозговой слизень им мешал.

[spamsink]

Пока я это на работе увижу - наверное ещё 20 лет пройдёт.

Это самое обидное, пожалуй.

Ц++ должен быть разрушен.

Ломать - не строить.

[ak_47]

Ломать - не строить.

Свято место пусто не бывает! :)

[yatur.livejournal.com]

Конструкторная болезнь, о которой ты говоришь - далеко не самый тяжелый недуг С++. Кроме того, ею страдают популярные языки Джава и C#, вышедшие из С++. Так что, это нынче практически стандарт :)

Нечитабельные идиомы, подобные

for (;;) или
std::string s3(buf, 3, 2);

есть в любом языке и запоминаются по мере использования. Не заглядывая в документацию, рискну предположить, что в строку кладется два символа, начиная с индекса 3, т.е. " i". Можно, конечно, завести поименованные параметры и писать что-то вроде

s3.substring(start:3, count:2)

но это многословно и быстро начинает доставать опытных программистов. В общем, это все мелочи.

В С++ хватает настоящих проблем - идиотская грамматика, затрудняющая автоматический рефакторинг, отсутствие единой системы типов (char* vs string, int[] vs vector<int>), отсутствие двоичной совместимости между разными компиляторами на одной платформе и т.п.

[yigal_s]

* std::string s3(buf, 3, 2);

это нельзя считать допустимой к заучиванию идиомой, поскольку подобное повторяется при дизайне практически любого value-like класса, как библиотечного, так и прикладного.

> Можно, конечно, завести поименованные параметры и писать что-то вроде
> s3.substring(start:3, count:2)

В этом примере обязано присутствовать слово "substr", именуемые параметры не обязательны. Так когда-то было сделано в старом тупом языке BASIC, например ))) Программист не должен из сочетания типов и количества параметров понимать, что речь идет именно о взятии подстроки. И еще раз, речь о конструкторе, а не об обычной функции ))).

А то давай еще для развития стиля сделаем все функции имеющими название "operator ()", а по типу аргументов будем судить, что она делает )))

Что до твоих проблем - так выкинь нафиг char* и int[] - и будет тебе счастье. А вот что действительно восхищает, это количество способов, которым можно передать параметр в функцию:

по значеню
по ссылке
по указателю
по ссылке на r-value
по эзотерической ссылке && в темплейте
по значению интеллектуального указателя (shared_ptr например)
по указателю на интеллектуальный указатель
по ссылке на интеллектуальный указатель

сюда ж еще модификатор const
далее со всеми остановками

Но я именно хотел поговорить о соверешнно безобидных на первых взгляд вещах, лежащих в основах синтаксиса, например. Что и было сделано.

[yatur.livejournal.com]

> выкинь нафиг char* и int[]

А вот фиг. Нельзя их выкинуть. По двум причинам - во-первых литералы имеют именно такой тип. Во-вторых, APIs специально под С++ мало кто пишет (см. проблему двоичной совместимости) - их пишут под С, а там без char* и int[] никуда.

> по эзотерической ссылке && в темплейте

Не знаком. Видать, добавили после того как я ушел из большого секса ежедневного программирования на С++.

[yigal_s]

ну литералы можно сразу в string завернуть, а из vector<int> указатель на int вытаскивается на ура. Так же как и на char из string.

[yatur.livejournal.com]

Из string вытаскивается указатель на char const :) Если мне нужно вызывать функцию типа GetCurrentDirectory(), то это, кагбэ, не подходит. У yosefk было много про duplicate facilities и почему от char* избавиться не так просто.

Так что же такое && в темлпейтах? На какие ключевые слова гуглить?

[yigal_s]

ну забей туда vector<char>

не, ну понятно, что это всё не идеально, я и не претендую.

По &&

http://thbecker.net/articles/rvalue_references/section_08.html

http://isocpp.org/blog/2012/11/universal-references-in-c11-scott-meyers

[yatur.livejournal.com]

Спасибо, с && ясно. Блин, неужели еще один выверт в грамматике?

[yigal_s]

типа, а лямбда в виде -

[ ] ( ) { }

это не выверт, а мы погулять вышли?

[ak_47]

Это мудрость предков:



:)

[yatur.livejournal.com]

> давай еще для развития стиля сделаем все функции имеющими название "operator ()"

Good idea! Тогда у нас получится LISP :)

[yigal_s]

в LISP вообще-та на первой позиции списка стояло имя функции. Если мне детские воспоминания не изменяют...

[yatur.livejournal.com]

Ну правильно. А у нас будет имя объекта. А все функции в нем будут называться (). И во всем, что они возвращают тоже будут только операторы (). Результат будет примерно такой же, не?

[yigal_s]

Кароче, правильный объектно-ориентированный протокол должен предусматривать лишь обращение от одного объекта к другому объекту с передачей сообщения/вызовом метода "doIt".

[yatur.livejournal.com]

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

void* doIt(void* data);

Ну или

Object doIt(Object data);

в терминах Java/C#. Обратная совместимость гарантирована на 100%, по крайней мере на этапе компиляции. :)