LINUX.ORG.RU

Ушат помоев в сторону крестолюбов

 , , ловите наркомана,


15

14

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

Последние 7 лет я пишу сугубо на C, и только под Linux (да, да -std=gnu99 и accept4, dup3, __attribute__((cleanup(dtor))) и прочие приятности, позволяющие сделать волосы шелковистее на 15.5%) и не понимаю, для чего вообще нужен C++? То, что на сишке делается красиво и элегантно, в крестах напоминает соитие парализованных дцпшников (к сожалению, утерял картинку, но именно этот образ всплывает в голове, когда вижу очередную порцию крестолапши).

Давайте посмотрим на типичного C++ разработчика: он использует STL, boost, многие любят Qt (не только для GUI), якобы чтобы «писать кроссплатформенный код». В итоге болезный не знает током ни WinAPI, ни POSIX — ничерта. Он абсолютно не разбирается, как работает целевая система, для которой пишет код! Крестокодер просто не осознает, какой лютый ужас кроется за его любимыми iostream-ами, какое лютое говно лежит в boost::filesystem::path, насколько убого-низкоуровневым является boost::asio в 2016 году.

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

Также эти убогие завистливо смотрят на type inference в языках, проектировавшихся не как «C на стероидах», и в ответ начинают лепить template и auto не к месту, от чего код адово пухнет и даже IDE перестает его понимать.

Серьезно, просто прекратите писать на этом языке. В следующий раз, начиная новый проект, выберите java (щютка)/go/swift/rust/c. Прекратите насиловать труп и отравлять зловонием все вокруг!

Перемещено true_admin из talks

★★★★

Последнее исправление: a1batross (всего исправлений: 2)
Ответ на: комментарий от invy

Да ладно. Вот такой код не зависит от того, Qt это, или WinAPI:

	switch (align) {
	case Align::Left:
		if (vertical)
			format.SetLineAlignment(StringAlignmentFar);
		else
			format.SetAlignment(StringAlignmentNear);
		break;
	case Align::Center:
		if (vertical)
			format.SetLineAlignment(StringAlignmentCenter);
		else
			format.SetAlignment(StringAlignmentCenter);
		break;
	case Align::Right:
		if (vertical)
			format.SetLineAlignment(StringAlignmentNear);
		else
			format.SetAlignment(StringAlignmentFar);
	}
От копипасты можно было бы избавиться так:
	switch (align) {
	case Align::Left:
		handle_halign(StringAlignmentFar, StringAlignmentNear);
		break;
	case Align::Center:
		handle_halign(StringAlignmentCenter, StringAlignmentCenter);
		break;
	case Align::Right:
		handle_halign(StringAlignmentNear, StringAlignmentFar);
		break;
	}
Где handle_halign — либо отдельный приватный метод, либо лямбда вида:
	const auto handle_halign = [&](auto vert, auto horz) {
		if (vertical)
			format.SetLineAlignment(vert);
		else
			format.SetAlignment(horz);
	};

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

eao197 ★★★★★
()
Ответ на: комментарий от eao197

От копипасты можно было бы избавиться так:

А ничего что в этом случае код с копипастой проще и понятнее? Каргокульт какойто.

anonymous
()
Ответ на: комментарий от anonymous

А ничего что в этом случае код с копипастой проще и понятнее?

Он даже в таком виде не проще, и не понятнее. Для того, чтобы проверить, правильно ли выставляются значения, нужно проходить каждую ветку, т.к. парность вызова SetLineAligment и SetAligment, а так же аргументы для этих методов размазаны по коду.

Про сопровождение и развитие такого кода и говорить не приходится.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Он даже в таком виде не проще, и не понятнее.

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

anonymous
()
Ответ на: комментарий от eao197

Про сопровождение и развитие такого кода и говорить не приходится.

Простота сопровождения и развитися на 90% зависит от такого насколько кож простой и читабельный. На 10% от всего остального. Если с копипастой проще - надо делать с копипастой, сэкономишь на сопровождении.

anonymous
()
Ответ на: комментарий от anonymous

В каком «таком»?

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

заменили непонятной ф-ей с нетривиальной (зависящей от глобальной переменной) логикой.

Функция на 4 строчки с одним if-ом стала нетривиальной? Пожалуй, вы ошиблись профессией.

Логика, кстати, зависит от тех же самых переменных, что и исходный метод с копипащенными switch-ами. И это не глобальные переменные, это атрибуты класса.

То что ег ов принципе можно в целом получше переписать

Ануткать. А мы поржом тут всем LOR-ом.

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

Если с копипастой проще - надо делать с копипастой, сэкономишь на сопровождении.

«Копипаста», «сэкономишь на сопровождении». Можно примеры подобного сочетания?

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Функция на 4 строчки с одним if-ом стала нетривиальной? Пожалуй, вы ошиблись профессией.

Таков тренд :-) Так, сейчас среди цепепе программистов функция на 2 строчки стала нетривиальной :-) Например, вот это

S::~S() // Explicit delete, uh, nontrivial!!1
{
  delete impl_;
  impl_ = nullptr;
}

считается нетривиальным :-) Надо писать так

S::~S() = default; // I'm fan of unique_ptr<>!!1

Видишь, было две строчки, а теперь просто = default !11 :-)

anonymous
()
Ответ на: комментарий от eao197

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

А еще, я чаще использую std::map, т.к. мне не надо иметь миллионы элементов и совершать поиск там миллион раз в секунду.

invy ★★★★★
()
Последнее исправление: invy (всего исправлений: 1)
Ответ на: комментарий от eao197

Функция на 4 строчки с одним if-ом стала нетривиальной? Пожалуй, вы ошиблись профессией.

Из названия вообще непонятно что делает, безе перехода к объявлению/описанию вообще не ясно что там происходит.

Dudraug ★★★★★
()
Ответ на: комментарий от Dudraug

Из названия вообще непонятно что делает, безе перехода к объявлению/описанию вообще не ясно что там происходит.

Если handle_halign будет лямбдой перед свитчем, то все будет понятно. Если это будет отдельный метод, то у него может быть другое название, например, SetHorizontalAligmentParams().

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

считается нетривиальным :-) Надо писать так
Видишь, было две строчки, а теперь просто = default !11 :-)

Ну толсто же.

Dudraug ★★★★★
()
Ответ на: impl_ = nullptr; от anonymous

impl_ = nullptr;
детектор говнокода сгорел от зашкаливания

От чего же присваивание указателю nullptr в деструкторе считается говнокодом? :-) Давай, продемонстрируй тут свою некомпетентность :-)

anonymous
()
Ответ на: комментарий от Dudraug

Ну толсто же.

А разве не так принято сейчас определять деструкторы в современном цепепе? :-)

anonymous
()
Ответ на: комментарий от anonymous

потому что в нескольких соседних методах (не во всех, обычно, лол) написано

if (impl_)
wait. oh shi

anonymous
()
Ответ на: комментарий от anonymous

потому что в нескольких соседних методах (не во всех, обычно, лол) написано
if (impl_)

Ахаха :-) Это где так пишут очередной стартап? :-)

anonymous
()
Ответ на: комментарий от anonymous

практически везде, где встречается impl_ = nullptr;

зачем иначе присваивать значение, которое никогда не будет считано?

anonymous
()
Ответ на: комментарий от anonymous

практически везде, где встречается impl_ = nullptr;

зачем иначе присваивать значение, которое никогда не будет считано?

Так в чём говнокод тогда? :-) Присваиваем значение, потом проверяем :-) В старапах нынче что, в случае с unique_ptr<> проверки вида if (impl_) не делают? :-) unique_ptr<> за это не отвечает :-) Получается, говнокодите там у себя? :-)

anonymous
()
Ответ на: комментарий от anonymous

Присваиваем значение

в деструкторе

потом проверяем

ну ок

на этом беседу с необучаемым можно заканчивать

anonymous
()
Ответ на: комментарий от anonymous

в деструкторе
ну ок
на этом беседу с необучаемым можно заканчивать

Слив засчитан :-) Впрочем, не было сомнений, что адепт не слышал про явный вызов деструктора, поэтому так слажался :-) Квалификация адептов цепепе - штука неоднозначная :-) Лол :-)

anonymous
()
Ответ на: комментарий от anonymous

я смотрю, тебе нравится жрать говно...

адепт слышал, что за ub компилятор может сгенерировать код, который потрёт весь прон в твоём хомяке.

anonymous
()
Ответ на: комментарий от anonymous

я смотрю, тебе нравится жрать говно...

Посмотри лучше в зеркало :-)

адепт слышал, что за ub компилятор может сгенерировать код, который потрёт весь прон в твоём хомяке.

Ого! :-) Бедный адепт :-) Смотри, не пиши так в деструкторах! :-)

Можешь написать письмо команде GCC, узнать, почему у них в деструкторе nullptr по факту присваивается :-) Ну а пока поржите всем стартапом :-)

~unique_ptr() noexcept
{
  auto& __ptr = std::get<0>(_M_t);
  if (__ptr != nullptr)
    get_deleter()(__ptr);
    __ptr = pointer();
  }
anonymous
()
Ответ на: комментарий от anonymous

мало ли на свете быдлокодеров? в стандарте [unique.ptr.single.dtor] написано так:

Effects: If get() == nullptr there are no effects. Otherwise get_deleter()(get()).
налепили отсебятины — не соответствуют стандарту.

anonymous
()
Ответ на: комментарий от anonymous

в стандарте [unique.ptr.single.dtor] написано так:
налепили отсебятины — не соответствуют стандарту.

«Куд-кудах, все правильно, ко-ко-ко, комитет не обсирается!» (C) :-)

Самомнение, однако :-)

anonymous
()
Ответ на: комментарий от eao197

Функция на 4 строчки с одним if-ом стала нетривиальной?

Любая ф-я с глобальной переменной нетривиальна. Код становится значительно менее читабален.

Логика, кстати, зависит от тех же самых переменных, что и исходный метод с копипащенными switch-ами. И это не глобальные переменные, это атрибуты класса.

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

anonymous
()
Ответ на: комментарий от eao197

«Копипаста», «сэкономишь на сопровождении». Можно примеры подобного сочетания?

Да в любом номральном софте. Копипаста _сама по себе_ ни чем не вредна. А вот попытки ее избежать - часто вредны.

anonymous
()
Ответ на: комментарий от anonymous

Копипаста _сама по себе_ ни чем не вредна

Глубокая философия.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Они глобальные по отношении к функции, то есть не важно.

Да, блин, настало время акуительных открытий. Было:

struct TextSource {
	obs_source_t *source = nullptr;
...
	bool vertical = false;
...
	void GetStringFormat(StringFormat &format);
...
};
void TextSource::GetStringFormat(StringFormat &format)
{
	UINT flags = StringFormatFlagsNoFitBlackBox |
		StringFormatFlagsMeasureTrailingSpaces;

	if (vertical)
		flags |= StringFormatFlagsDirectionVertical |
			StringFormatFlagsDirectionRightToLeft;

	format.SetFormatFlags(flags);
	format.SetTrimming(StringTrimmingWord);

	switch (align) {
	case Align::Left:
		if (vertical)
			format.SetLineAlignment(StringAlignmentFar);
		else
			format.SetAlignment(StringAlignmentNear);
		break;
...

Могло бы стать:

void TextSource::GetStringFormat(StringFormat &format)
{
	UINT flags = StringFormatFlagsNoFitBlackBox |
		StringFormatFlagsMeasureTrailingSpaces;

	if (vertical)
		flags |= StringFormatFlagsDirectionVertical |
			StringFormatFlagsDirectionRightToLeft;

	format.SetFormatFlags(flags);
	format.SetTrimming(StringTrimmingWord);

	const auto handle_halign = [&](auto vert, auto horz) {
		if (vertical)
			format.SetLineAlignment(vert);
		else
			format.SetAlignment(horz);
	};
	switch (align) {
	case Align::Left:
		handle_halign(StringAlignmentFar, StringAlignmentNear);
		break;
...

Какие глобальные переменные? Хватит бредить и нести херню.

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

Копипаста _сама по себе_ ни чем не вредна.

Да, не видели вы копипасты. Не приходилось вам код с копипастой суппортить...

eao197 ★★★★★
()
Ответ на: комментарий от eao197

< Могло бы стать:

Во втором случае надо искать и смотреть объявление handle_halign, которая работает совершенно невнятным образом и непонятно вообще зачем нужна (на самом деле ни зачем,просто у когото копипаста головного мозга).

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

anonymous
()
Ответ на: комментарий от eao197

Я не говорю что копипаста не может быть плоха. Я говорю, что она необязательно плоха. Часто копипаста (сама по себе не являясь злом) ведет к некоторым отрицательным последствиям, да. Равно как к некоторым отрицательным последствиям часто ведет попытка избежать копипасты. Надо смотреть на ситуацию а не выполнять бездумные директивы.

anonymous
()
Ответ на: комментарий от anonymous

Во втором случае надо искать и смотреть объявление handle_halign

Т.е. найти объявление локальной переменной в методе для вас проблема? А разбираться с 20 строками однотипного кода, отличающегося лишь отдельными деталями — нет? Ну, окай.

Главное, что аргументы о привязке к глобальным переменным вдруг исчезли. Как так? Уважаемый анонимный ыксперт поменял свое мнение? А ну как он еще раз его поменяет.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Т.е. найти объявление локальной переменной в методе для вас проблема?

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

Главное, что аргументы о привязке к глобальным переменным вдруг исчезли. Как так?

Почему исчезли? Не исчезли. На практике ты не будешь смотреть объявление handle_halign, на это обычно времени нет. Ты прикинешь, что делает ф-я из контекста и по названию, потом ВНЕЗАПНО окажется что она зависит от переменной из внешнего контекста (этой информации нету ни в названии, ни в типе, ни по смыслу, был бы ты не идиотом, передавал бы этот параметр vertical третьим аргументом, но ты же так не сделал), которая меняется хз как, хз где и тоже совершенно неожиданным образом. В результате - либо надо прежде, чем менять этот код, досконально разбираться во всем контрол флоу (что резко повышает затраты, это ж будет, повторюсь, не одно место где ты там чето «нарефакторил», ака «обфусцировал»), либо надеяться, что код писал не баран и в handle_halign не будет потенциально опасных вещей. Но надежды не оправдаются и мы с нехилой долей вероятности получим весьма сложный в отладке баг.

anonymous
()
Ответ на: комментарий от anonymous

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

Дальше можно не продолжать. Возвращайтесь, когда напишите что-то побольше HelloWorld. А то у вас упрощение кода ничего не дает в замен, копипаста не проблема и т.д.

Да, и прочитайте где-нибудь о плюсовых лямбдах, захватах контекста и пр. Чтобы не нести бред про какой-то внешний контекст. Заодно почитайте про локальные функции, дабы было понятно, в какой роли выступает handle_halign.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Дальше можно не продолжать. Возвращайтесь, когда напишите что-то побольше HelloWorld.

Вам того же. Поработаете с крупным проектом - поймете, о чем речь.

А то у вас упрощение кода ничего не дает в замен, копипаста не проблема и т.д.

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

Да, и прочитайте где-нибудь о плюсовых лямбдах, захватах контекста и пр. Чтобы не нести бред про какой-то внешний контекст. Заодно почитайте про локальные функции, дабы было понятно, в какой роли выступает handle_halign.

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

anonymous
()
Ответ на: комментарий от anonymous

Поработаете с крупным проектом - поймете, о чем речь.

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

Так в рассматриваемом примере как раз простой код с копипастой

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

становится более сложным кодом с лямбдой и неочивидными зависимостями, которые невыводимы из контекста.

Где вы там увидели сложный код, неочевидные зависимости и невыводимость из контекста?

Захват мутабельных переменных в лямбде ничем абсолютно от глобальных переменных не отличается.

Скажите честно: вы просто дебил или захотелось пофлеймить на форуме?

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Если вам никогда не приходилось ловить одну и ту же ошибку в разных местах из-за того

... что отсутствует ревью :)

от языка это никак не зависит, кстати

anonymous
()
Ответ на: комментарий от eao197

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

Я где-то говорил, что копипаста _никогда_ не ведет к фейлам? Я говорил, что не любая.

Простой код с копипастой всегда является бомбой замедленного действия.

Я указал основной критерий «опасности» копипасты - когда она появляется _в разных местах_. Тогда это действительно хороший претендент на то, чтобы убрать дублирование. И это сразу ликвидирует вот эту возможность:

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

Если же копипаста в пределах одного экрана - то проблем не бывает, труджно даже придумать синтетический пример, при котором проблемы могут возникнуть.

Где вы там увидели сложный код, неочевидные зависимости и невыводимость из контекста?

Зависимость от внешней переменний vertical, о которой в коде вообще ничего не сказано. Она, еще раз, должна передаваться в вашу лямбду явным третьим аргументом. Это тоже, конечно, не идеал, но по крайней мере _настолько_ убогим ваш код не будет.

Скажите честно: вы просто дебил или захотелось пофлеймить на форуме?

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

anonymous
()
Ответ на: комментарий от anonymous

Я говорил, что не любая.

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

Если же копипаста в пределах одного экрана - то проблем не бывает

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

Зависимость от внешней переменний vertical, о которой в коде вообще ничего не сказано.

Вы на плюсах вообще хоть пару строчек написали? vertical — это не переменная, это член класса TextSource, который явтоматически виден во всех методах класса TextSource. И лямбда handle_halign ведет себя как локальный метод этого же класса, поэтому и обращение к vertical в ней такое же нормальное, как и во всех других методах.

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

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

eao197 ★★★★★
()
Ответ на: комментарий от eao197

На практике разница между «любой» и «не любой» выясняется постфактум.

Зачем же постфактум? Я сформулировал вполне четкий и ясный критерий, который легко проверяется еще до того, как ты код начал писать.

Вы уж определитесь, если то, что в пределах одного экрана не проблема, то с какого вы доколупались до handle_halign?

Ты, видимо, потерял нить разговора? _копипаста_ в пределах одного экрана не проблема. Причем тут handle_align?

Вы на плюсах вообще хоть пару строчек написали? vertical — это не переменная, это член класса TextSource, который явтоматически виден во всех методах класса TextSource.

То есть, переменная, область видимости которой - контекст класса.

И лямбда handle_halign ведет себя как локальный метод этого же класса, поэтому и обращение к vertical в ней такое же нормальное, как и во всех других методах.

Ты, видимо, не слышал про инкапсуляцию, да? Если писать без инкапсуляции, то поле класса ничем не отличается от глобальной переменной, точно так же порождает невнятный control flow. ООП и инкапсуляцию придумали за тем, чтобы ограничить область видимости переменных и работать с ними предсказуемым, понятным способом (т.к. модули в сишку завести трудно). Это, однако, не означает, что можно в один класс напихать кучу говна, нет - надо придерживаться определенной дисциплины. Метод (и, соответственно, лямбда внутри класса) либо должны поддерживать определенные инварианты, либо указывать на зависимости. Иначе последствия обычно такие, что и махровая копипаста в разных местах - детский лепет. Вот я прочитал твою портягу кода, в ней использование вертикал не указано, я ожидаю, что оно там не используется. А потом ловлю совершенно невнятный баг.

Я не понимаю, где вы там все эти захваты увидели.

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

anonymous
()
Ответ на: комментарий от anonymous

Вот я прочитал твою портягу кода, в ней использование вертикал не указан

Ты чем смотрел? А это что по-твоему: [&]?

Esper
()
Ответ на: комментарий от anonymous

Если писать без инкапсуляции, то поле класса ничем не отличается от глобальной переменной, точно так же порождает невнятный control flow.

А ты не путаешь инкапсуляцию и сокрытие членов? :-)

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

Инкапсуляцию придумали в качестве средства, благодаря которому внесение изменения в единицу проектирования (будь то класс или модуль) не приводит к нарушению кода, который от неё зависит :-)

anonymous
()
Ответ на: комментарий от anonymous

Я сформулировал вполне четкий и ясный критерий, который легко проверяется еще до того, как ты код начал писать.

Этот четкий и ясный критерий нужно засунуть автору в задницу. Ибо он не защищает от проблем, а лишь создает видимость безопасности. Попробуйте с исходном примере добавить по еще одной операции в каждую ветку if-а внутри switch-а. И поймете о чем идет речь.

Хотя нет, не поймете.

_копипаста_ в пределах одного экрана не проблема.

Это заблуждение. Но вы пока еще на себе этого не ощутили.

Причем тут handle_align?

При том, что если вам хватает мозгов разобраться с копипастой на одном экране, то должно хватить мозгов разобраться и с наличием handle_halign. Там ведь 5 строчек сама лямбда и 3 строки с ее использованием. Но вони развели на весь LOR.

Ты, видимо, не слышал про инкапсуляцию, да?

Когда чувак на вопрос «Вы на плюсах вообще хоть пару строчек написали?» начинает срать простынями текста про инкапсуляцию, ООП и control flow, то это дальше разговор можно не продолжать.

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

операция индексации по адресу же. а ты — неосилятор

А, точно :-) Префиксное разыменование по адресу закрывающей квадратной скобки :-)

anonymous
()
Ответ на: комментарий от Esper

У тебя опять проблемы с пониманием контекста?

А в чём проблем взятия адреса от квадратной скобки? :-)

anonymous
()
Ответ на: комментарий от anonymous

А в чём проблем взятия адреса от квадратной скобки? :-)

Ну возьми, если сможешь.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.