Программистское

[spamsink]

Кто может объяснить, зачем push_back типа void, а не типа ссылки на контейнер? Зачем заставлять меня делать нелепые телодвижения ради возможности писать container.push_back(x).push_back(y).... ? Почему сразу нельзя было?

Comments

[dvv.livejournal.com]

Шоб неповадно было.
Заведи свой темплит.

[spamsink]

Уже завел.
Шоб неповадно что было?

[dvv.livejournal.com]

Такие колбасы писать.

[spamsink]

Видишь ли, Юра... Программы иногда порождаются автоматически или полуавтоматически.

[dvv.livejournal.com]

Автомат чинить надо. Или его половину.

[rezkiy.livejournal.com]

возможность писать container.push_back(x).push_back(y) -- путь на темную сторону силы. Вот бросила эта штука исключение, сколько элементов в листе?

[spamsink]

Зачем его чинить? Той части автомата, которая хочет вставлять, не должно быть дела, куда вставлять.

[spamsink]

Эта штука семантически не отличается от
container.push_back(x); container.push_back(y);
Разница чисто синтаксическая.

[yatur.livejournal.com]

А на светлой стороне силы вокруг каждого оператора try-catch стоит?

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

container.push_back(x++).push_back(x++); - это, надо полагать, undefined behavior. А

container.push_back(x++);
container.push_back(x++); - нет.

[spamsink]

Ну мало ли можно придумать вариантов с undefined behavior?
Вон, std::cout << x++ << x++; допустимо, и все прекрасно себя чувствуют.

[sab123.livejournal.com]

Они таким образом борются за эффективность. Из тех же соображений разделены front() и pop_front().

[spamsink]

Эффективность чего? Соптимизировать возврат *this, если он не используется в точке вызова, по-моему, может и ребенок.

pop_* отделено от "peek" по более разумным соображениям эффективности: если бы pop_* возвращал значение, то даже при его неиспользовании вызывать конструктор временной копии все равно надо было бы.

[ak_47]

Скорее всего сделано для симметрии с другими подобными функциями: push_front, pop_back, pop_front.

Вдогонку. Хоть формально и не могу объяснить, но интуитивно мне не нравится код вида: container.push_back(x).push_back(y). Как и многие другие тоже отметили. Есть в этом что-то не то. Если речь идёт о генерации кода (каковая сама по себе далеко не мейнстримная задача, заметим), то сгенерить container.push_back(x); container.push_back(y); точно так же легко. Так что этот аргумент я не могу принять.

[spamsink]

push_back был ради примера. Вопрос одинаково приложим ко всем четырем.

Даже безотносительно к генерации кода, где может хотеться разделить генерацию объекта и операций над ним, и не протаскивать одно через другое, чем не угодило get_container_ref().push_back(x).push_back(y)?

[ak_47]

Не угодило тем что возврат ссылки на контейнер из всего что не оператор = выглядит странно и неуместно. Единственный осмысленный тип, который могли бы возвращать подобные функции, это ссылка/итератор на элемент контейнера, над которым совершается действие. Но некоторые из них не могут возвращать такой тип из-за ограничений накладываемых by exception safety requirements. Поэтому наверное решили привести их всех к общему знаменателю, т.е. void.

[spamsink]

Это еще почему?

Класс Брюки {
Контейнер левыйКарман, правыйКарман;
Контейнер & болееСвободныйКарман() { ... }
}

[ak_47]

Я имею в виду ссылку на себя из других методов контейнера (и просто класса в общем случае). Возвращение ссылки на себя не из операторов и не из специальных методов, типа self() - это скорее Java-изм. Формально, конечно, это не запрещено, но внутреннее чувство прекрасного противится.

[spamsink]

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

[ak_47]

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

Компилятор выкинет лишние локальные переменные, а вот readability пострадает.

[spamsink]

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

[ak_47]

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

Итого: вопрос о том почему push_back возвращает void - стилистический. Так решили создатели стандартной библиотеки следую сложившемуся стилю в С++.

[malaya-zemlya.livejournal.com]

Чтобы кто не подумал, что программирует на джаве.

[spamsink]

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

[spamsink]

Я на ней никогда не программировал, поэтому точно не подумаю.

[rezkiy.livejournal.com]

это не единственный путь на темную сторону силы. А try-catch вокруг _каждого_ оператора -- явный признак неудачно выбранного языка программирования.

[rezkiy.livejournal.com]

+1

Вот цитата из Степанова:

There is a sad obligation to return a reference from the assignment. C introduced the dangerous ability to write a = (b = c). C++ made it so that we can write the even more dangerous (a = b) = c. I would rather live in a world where assignments return void. And while we are forced to make our assignments to conform to the standard semantics, we should avoid using this semantics in our code. (This is similar to Jon Postel’s Robustness Principle: “TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.”)

[http://users.livejournal.com/_navi_/]

скорее, на хаскелле, тогда уж

[spamsink]

"be liberal in what you accept from others"

Вот именно. Именно поэтому стандарт языка должен быть как можно более либеральным.

[rezkiy.livejournal.com]

это не язык а всего лишь стандартная библиотека. При написании STL мнение Степанова, предпочитающего void-ы, очевидно учитывалось. А в стандартную библиотеку оно попало явочным порядком.

[spamsink]

Всё, что в LRM, есть часть языка.

При написании STL мнение Степанова, предпочитающего void-ы, очевидно учитывалось. А в стандартную библиотеку оно попало явочным порядком.

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

[rezkiy.livejournal.com]

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

[rezkiy.livejournal.com]

Работать не унизительно :-)

[anatoly borodin (from livejournal.com)]

pop() и front() разделены правильно.

http://ptgmedia.pearsoncmg.com/images/020163371x/supplements/Exception_Handling_Article.html

[anatoly borodin (from livejournal.com)]

Вот ссылка получше: accu.org/index.php/journals/444

[ivan-ghandhi.livejournal.com]

Because most of the programmers are assholes.

That's why.

They don't care about you.

API designers are a special kind of assholes. They are happy to make you jump through the loops.

[spamsink]

Thank you!

[sab123.livejournal.com]

В-общем, мораль: от исключений никакой пользы помимо вреда.

[boris71.livejournal.com]

Use the source, Luke...

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