Здравствуйте, alzt, Вы писали:
A>Ищет конктерный кусок, исправляет.
Ахахаха!
И оно взрывается вообще в неожиданных местах, или просто втихую портит воздух данные. Потому что сия хрень используется из кучи левых мест неочевидным образом — спагетти же, всё знает про всех, всё от всего зависит.
A>Вот, я когда освоил шаблоны С++, прочитал книжку Вандевурда, и минимизировал код, то следующему было сложно. Я вывел в компайл тайм всё, что смог.
А, у нас таких называли "укушенные Александреску".
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, prog123, Вы писали:
P>Помучался я с этим высоко-абстрактным кодом и за пару часов восстановил протокол по спагетии коду с одним гигантским свитчем и кучей ифов внутри.
Человек-дизассемблер
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
LVV>>>Да мы проще поступили. LVV>>>Сделали свой язык для обучения и его учим. А потом переводим в С++, чтоб народ не отставал от тенденций. AN>>А зачем свой язык сделали вместо того, что бы взять какой-нибудь из существующих? И где можно код на нём посмотреть? LVV>Ответ PMу посмотри.
Который?
Вроде не в одном нет примера кода на вашем языке.
Спагетти-код это код, который тронь в одном месте — последствия проявятся в другом совершенно непредсказуемом месте.
Это как раз не про спагетти, это как раз про излишнее увлечение complexity и generic programming, на которые фапают в мире "рассово верного" C++. Это когда у тебя аукается не просто в других участках кода, не просто в других файликах, это когда у тебя аукается на других уровнях абстракции, в других объектах в других пластах. В спагетти отследить почему аукнулось и где аукнулось можно тупо grep-ом. В случае с забористым C++ grep уже не поможет. Нужно разгребать всю эту свёртку шаблонов в то самое спагетти, чтоб потом уже разбирать, где аукнулось и почему аукнулось.
Здравствуйте, уважаемый LaptevVV, Вы писали:
LVV>Я С/С++ с первого издания Кернигана-Ричи знаю...
Это по чистому C (K & R standard) — есть у меня такая кинжка — из серии must have.
По C++ писал Бьярн Страуструп — и его издания также must have (настольная книга).
LVV>И работал на нем с 1989 года. LVV>Так что я знаю, о чем говорю. LVV>Кстати, и сейчас работаю. LVV>И преподаю. LVV>С точки зрения обучения начинающих программистов — там кресты, а не плюсы.
Да ладно, уважаемый профессор, в жизни у нас у каждого свой крест
LVV>Ну, а мне лично С++ нравится. LVV>Особенно после книжки Ивана Чукича о функциональном программировании на С++.
+100500
Кстати, отличная книга, спасибо за своевременную подсказку!
Здравствуйте, Reset, Вы писали:
A>>Ищет конктерный кусок, исправляет. Задача выполнена. Всё. Не надо разбираться в паттернах, изучать архитектуру. A>>Вот, я когда освоил шаблоны С++, прочитал книжку Вандевурда, и минимизировал код, то следующему было сложно. Я вывел в компайл тайм всё, что смог. А я способный. Я думаю, что человек, который это поддерживал, многое бы отдал, чтобы это был просто спагетти код. Ему хотя бы шаблоны учить не пришлось. И разгребать было бы легче.
R>Ты неверно понимаешь термин "спагетти-код".
Похоже и правда, я под ним больше понимал копи-пастный код, который тоже не слишком структурирован.
Здравствуйте, alzt, Вы писали:
A>Ищет конктерный кусок, исправляет. Задача выполнена. Всё. Не надо разбираться в паттернах, изучать архитектуру. A>Вот, я когда освоил шаблоны С++, прочитал книжку Вандевурда, и минимизировал код, то следующему было сложно. Я вывел в компайл тайм всё, что смог. А я способный. Я думаю, что человек, который это поддерживал, многое бы отдал, чтобы это был просто спагетти код. Ему хотя бы шаблоны учить не пришлось. И разгребать было бы легче.
Высокоабстрактный код это не когда освоил шаблоны и вставил их как смог. Это когда когда читатель кода понимает, что именно хотел сделать автор, без вникания в детали как, даже не запуская его. В спагетти коде обычно все наоборот, мелкие шаги как это сделано, но непонятно зачем. Это первый уровень.
Второй, это когда корректные изменения сделать легко, а некорректные трудно, компилятор не даст. Ну и третий уровень, когда все это выражено на с++.
я сегодня смотрел лекторий фивт в записи апреля, лекцию по асио
который я считаю знаю не плохо
так вот
пока я не вслушивался в лектора, а смотрел картинки — было отлично
как только я переключился на то что же он там объясняет
я перестал вообще что то понимать
представляю какого было тем кому это рассказывалось
просто есть люди которым дано преподавать и писать учебные материалы
и кому то не дано
как говорится в одной пословице: умеешь программировать — пиши программы, а не умеешь — учи программировать других
чукчин может, классный и умный кодер
но книга — вода, разница со многими другими книгами других, что вода в картинках — большой прорыв
S>Был я относительно недавно на собеседовании (на позицию embedded-программиста), где меня попросили написать аналог tar'a. С лимитом по времени 4 часа. И без Qt, пожалуйста.
S>Штош, подумал я, где наша не пропадала?
S>1 час я потратил на установку boost'a (не встал, какие-то жэсточайшие ошибки, не было времени дальше копать).
S>Еще час я потратил, чтобы узнать, как кроссплатформенно открыть файл и узнать его размер. Кажется, никак, если нет С++17 c std::filesystem.
S>Последний час я из спичек и желудей лепил хоть что-нибудь.
Знакомое задание, случаем не Enapter ? Раньше такое задание давали в SpbTV.
Здравствуйте, _Artem_, Вы писали:
_A_>Это нифига не эквивалентный код. Объект подвергшийся операции std::move находится в валидном но неспецифируемом состоянии. То-есть, он может быть каким угодно.
Ого. И они ещё плакали, но продолжали стрелять в ногу.
Здравствуйте, PM, Вы писали:
PM>Здравствуйте, Zhendos, Вы писали:
Z>>И по-моему очевидно что я прав и C++ с каждым стандартом становиться сложнее, Z>>а как иначе если сохраняется обратная совместимость и новые конструкции только Z>>прибавляются?
PM>Да, язык становится сложнее. Я всего лишь пытаюсь донести мысль, что новые средства позволяют писать более читаемый и выразительный код.
Не согласен. Более выразительный противоречит читаемости. Так как намного больше происходит
под капотом и следовательно каждую строчку намного труднее понимать.
Вот вызвали функцию:
V v;
f(v);
Раньше это не могло быть проблемой. Раз код
скомпилировался, значит все ОК, либо функцию принимала по значению,
ли по ссылке и все с вызовом хорошо. А теперь она может принимать по значению
и нам больше не нужна "v", поэтому здесь ошибка и надо было "std::move(v)".
И это общая проблема C++11/14/17 и т.д., так как сохраняется обратная совместимость,
мы получаем все большую совершенно не нужную нагрузку на программиста,
который мог бы подумать о чем-нибудь еще — типа выбора более оптимального алгоритма,
улучшения архитектуры и т.д. Вместо этого он думает:
ок, нам пришла переменная типа Color, я знаю что это enum,
и мне нужно проверить красный ли цвет, как мне это написать?
color == RED или color == Color::RED,
ведь теперь знания что тип enum не достаточно, нужно знать
это enum или enum class.
Или я объявил новый класс, теперь кроме собственно нужных функций,
типа конструктора для создания экземпляра и методов нужно подумать еще
о пяти сервисных членов класса, вместо трех. Объявлять их default/delete,
писать руками и т.п.
И так с каждой возможностью, которую вводят. Все они усложняют язык и затрудняют
его использование, если их вводить не ломая и не выкидывая предыдущие возможности.
Z>>Итого кода стало больше, то есть программа сложнее, плюс одно и тоже действие Z>>можно записать двумя способами, это ли не усложнение?
PM>Это разные способы для разных целей. С введением семантики перемещения мы теперь имеем возможность перемещать некопируемые объекты, например дескрипторы файлов. Это не замена обмену. В С++03 трюк с обменом обычно использовался от бедности, для возврата из функции.
Но он много где использовался и в том числе чтобы не вызывать лишний раз аллокацию,
и переиспользовать выделенную память. Но я привел конкретный пример,
довольно странно парировать его другим примером, а же доказывал общее утверждение,
что весь написанный в C++11 стиле код стал хуже.
Здравствуйте, _Artem_, Вы писали:
_A_>Здравствуйте, Zhendos, Вы писали:
Z>>В C++11 прибавилось:
Z>>1. V(V&&), V& operator=(V&&) Z>>2. Появилось две возможности на выбор: Z>>
Z>>a = std::move(b);
Z>>
Z>>или старый вариант: Z>>
Z>>a.swap(b);
Z>>
Z>>Итого кода стало больше, то есть программа сложнее, плюс одно и тоже действие Z>>можно записать двумя способами, это ли не усложнение?
_A_>Это нифига не эквивалентный код. Объект подвергшийся операции std::move находится в валидном но неспецифируемом состоянии. То-есть, он может быть каким угодно.
А где я писал что это эквивалентный код?
Я писал что он "делает" тоже самое в контексте что для "b" скоро будет вызван деструктор.
С точки зрения написания программы мне все равно будет ли:
вызван код освобождения памяти для a, потом он будет владеть данными b,
а потом еще будет вызван деструктор для "b" которые данных нет,
но если посмотреть дизасемблер то декструктор все равно вызовется у этого:
> находится в валидном но неспецифируемом состоянии
но все согласно стандарту насколько я помню (вызов десктрутора у
"пустого" объекта).
или сначала a будет владеть данными b и наоборот, а потом будет вызван деструктор b.
Видимый результат в обоих случаях тот же самый, а с новыми фишками C++11 даже хуже
получается из-за вызова деструктора "пустого" объекта.
Здравствуйте, ViTech, Вы писали:
VT>Здравствуйте, Zhendos, Вы писали:
Z>>Я же написал:
Z>>
Z>>a.swap(b);
Z>>
Z>>При этом b выходит из области видимости
Z>>иными словами скоро вызовется деструктор b
VT>Хорошо, напишу чуть по другому: VT>
VT>V a{std::move(b)};
VT>
VT>Разницу чувствуете?
В чему разницу я должен чуствовать,
C++11 дает возможность создать alias a для объекта b.
При том как напомнили в другой ветке еще и не бесплатно,
так как будет вызван деструктор b, после того как он опустел?
Очень ценная возможность, но лучше просто использовать имя "b" в этой функции.
Здравствуйте, уважаемый Zhendos, Вы писали:
Z>Раньше это не могло быть проблемой. Раз код Z>скомпилировался, значит все ОК, либо функцию принимала по значению, Z>ли по ссылке и все с вызовом хорошо. А теперь она может принимать по значению Z>и нам больше не нужна "v", поэтому здесь ошибка и надо было "std::move(v)".
Что же мешало сделать две перегруженные функции:
1) аргумент типа константной ссылки
2) аргумент типа rvalue
тогда: хочешь сэкономить память — бери функцию с аргументом типа rvalue
но если не хочешь — просто передай "v" (всё будет работать без ошибки).
Z>И это общая проблема C++11/14/17 и т.д., так как сохраняется обратная совместимость, Z>мы получаем все большую совершенно не нужную нагрузку на программиста, Z>который мог бы подумать о чем-нибудь еще — типа выбора более оптимального алгоритма,
Синтаксис C++11/14/17 — вспонишь за секунды, а новый алгоритм или архитектуру — будешь продумывать не один день.
Z>ок, нам пришла переменная типа Color, я знаю что это enum, Z>и мне нужно проверить красный ли цвет, как мне это написать? Z>color == RED или color == Color::RED, Z>ведь теперь знания что тип enum не достаточно, нужно знать Z>это enum или enum class.
Использую (последнюю пятилетку) enum class — нет нигде никаких проблем.
Z>Или я объявил новый класс, теперь кроме собственно нужных функций, Z>типа конструктора для создания экземпляра и методов нужно подумать еще Z>о пяти сервисных членов класса, вместо трех. Объявлять их default/delete, Z>писать руками и т.п.
Зачем эти усложнения?
Компилятор всё правильно воспримет и без этих лишних телодвижений.
Z>>>Итого кода стало больше, то есть программа сложнее, плюс одно и тоже действие Z>>>можно записать двумя способами, это ли не усложнение?
Одно и то же действие несколькими способоми — это есть даже в старом добром Си
Страшного здесь ничего нет (и быть не может).
Здравствуйте, prog123, Вы писали:
P>Помучался я с этим высоко-абстрактным кодом и за пару часов восстановил протокол по спагетии коду с одним гигантским свитчем и кучей ифов внутри.
Именно такой код всегда считал спагетти. Вот здесь
Здравствуйте, reversecode, Вы писали:
R>вообще это стадия любого "говнокодера", который пол жизни багфиксит R>а потом оборачивается, и не видит результат R>а результатом кодера должен быть софт(продукт) R>а не знания С++ на 30 из 30
Продукт будет у бизнесмена. А у обычного программиста только, если он писал что-то мелкое, а потом крупная компания это раскрутила.
Вот, предположим писал человек MS Word. Продукт, как никак. Но он же не один его писал, и большую часть времени он фиксил баги. Продукт он не создавал. Поэтому сказать, что это его продукт, он не может.
