Здравствуйте, LaptevVV, Вы писали:

КД>>Я тут Роберта Мартина для себя открыл — очень положительное впечатление
LVV>Блин, да я дядюшку Боба читал всего, что у нас выходило...
LVV>И студням своим постоянно цитирую.

Я тут дочитал до середины "Чистый Код" (после программиста, архитектуры) ...

Мысли там правильные. А вот код...

1. Что-то меня вывернуло от того, что он временные переменные прогоняет через члены класса. Типа зацените — нам не надо их передавать через аргументы внутренним функциям.

UPD. А по факту — это такая новая, объектно-ориентированная разновидность глобальных переменных.

2. В коде, где он добавляет к тексту страницы заголовок / подвал, он за каким-то ...ом меняет сам объект с данными. По моему в пятой главе (лень идти за книгой). То есть два раза вызовем эту функцию и получим задвоение заголовка и подвала.

3. Там дальше, он нам объясняет почему он не встроил строку со значением по-умолчанию в функцию GetxxxxOrDefault, а передает её в вызове этой функции. Ну, ок. Но в этом вызове он передает именно строку, а не константу, которую было бы неплохо определить где-нибудь на уровне объявления класса, чтобы её было видно.

Не, ну я тоже недавно захерачил прямо в код строку с именем внешнего exe — "VSIXInstaller.exe". И кто-то внутри меня тихо выругался по этому поводу. Но, это закрытый код ... Надо переделать

4. Позабавил код вида

class BLABLABLA
{
 t_context context;
 t_stream stream;

 constructor(t_context context, t_stream s)
 {
  this.context=context;
  stream=s;
 }
}

Мужик, .ля, будь последовательным.

4.5. Префиксы "m_". Он их то использует, то не использует. В начале книги, если не ошибаюсь, говорит — не надо их использовать. Типа — IDE подсвечивает.

Ага, книга тоже посвечивает.

5. Форматирование.

Он молодец, что не использует табы. У меня сразу идет отторжение такого кода.

И шаг отступа — один символ

А вот за то, что открывающую фигурную скобку не выносит на отдельную строку —

Но я в одном месте узрел где он таки накатал:

{
}

Видать есть у него некие сомнения...

6. Я дополз до главы где он затеял рефакторинг обработки параметров командной строки. Увидел в классе член currentArgument и метод который его прокручивает в цикле. Даже не стал вникать в содержимое главы, сразу посмотрел в финальный вариант. currentArgument остался.

Нахер.

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

7. Очень много воды про Java — вообще не интересно.

Выкинуть и использовать освободившееся место под '{' на отдельной строке

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

Его "Идеальный код", моё личное мнение, далеко не идеален

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>>Я тут забил на твою предыдущую рекомендацию

Автор: LaptevVV
Дата: 23.01.20

"C++. Практика многопоточного программирования".

КД>>Капец там воды. Возьму с собой в пустыню

N>Вообще-то как раз очень компактно и плотно изложено. И даже я, много лет уже писавший подобные штуки, нашёл для себя много нового.
N>Где вода-то?

В первой редакции книги или во второй? В оригинале или же варианте переведенном на русский?

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

Здравствуйте, a7d3, Вы писали:

N>>Вообще-то как раз очень компактно и плотно изложено. И даже я, много лет уже писавший подобные штуки, нашёл для себя много нового.
N>>Где вода-то?
A>В первой редакции книги или во второй? В оригинале или же варианте переведенном на русский?

2012, русский, ДМК.

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

Смешной наезд.
У меня эта тема давно и прочно освоена на C/C++ на pthreads, на других языках, и чуть-чуть в ядре но именно с родными средствами C++11 до этого не приходилось сталкиваться. И у меня впечатления очень положительные: по сути, компактно, при этом с изложением не только специфики C++ в реализации средств синхронизации, но и обоснования такой специфики.
Приведите пример явной "гадости" с точностью до страницы или хотя бы до главы.

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Я остановился на абзаце, в котором три раза повторялось одно и тоже.

Не это?

This is where the move support of std::thread comes in. As described in the previous section, many resource-owning types in the C++ Standard Library, such as std::ifstream and std::unique_ptr, are movable but not copyable, and std::thread is one of them. This means that the ownership of a particular thread of execution can be moved between std::thread instances, as in the following example. The example shows the creation of two threads of execution and the transfer of ownership of those threads among three std::thread instances, t1, t2, and t3:

Тут не одно и то же, тут как минимум три разные вещи:
1. Общий принцип movable but not copyable для группы классов (там вроде больше не упоминалось).
2. Указание на реализацию этого принципа в std::thread.
2. Пример на такое перемещение, с описанием особенностей конкретного примера.

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

КД>Это было где-то в районе, где автор жизнерадостно засовывал std::thread в std::vector. Без средств предохранения.

std::vector<std::thread> threads;
for(unsigned i=0;i<20;++i)
{
  threads.emplace_back(do_work,i);
}

Такое? Читаем про emplace_back:

If an exception is thrown, this function has no effect (strong exception guarantee).

Там же рядом читаем, что перемещающие конструктор и присвоение у thread обязаны быть noexcept.
Так от чего предохраняться было надо? От того, что вообще может нить не создаться? Так это точно за пределами примера. Ещё от чего?

Здравствуйте, netch80, Вы писали:

N>2012, русский, ДМК.

N>Смешной наезд.
N>У меня эта тема давно и прочно освоена на C/C++ на pthreads, на других языках, и чуть-чуть в ядре но именно с родными средствами C++11 до этого не приходилось сталкиваться. И у меня впечатления очень положительные: по сути, компактно, при этом с изложением не только специфики C++ в реализации средств синхронизации, но и обоснования такой специфики.
N>Приведите пример явной "гадости" с точностью до страницы или хотя бы до главы.

Это не наезд, а вопрос — полностью ли была прочитана книжка или же только местами.

Автор переливает из пустое в порожнее, как пример можно взять многократную реализацию очереди или стэка. Из главы в главу и с весьма незначительными изменениями и длительными рассуждениями про них. Сделал на копейку, рассказывает так словно миллион сотворил, потом опять тоже самое, через некоторое время снова опять двадцать пять. А уж насколько криво и косо изложено про модель памяти — это явное косноязычие. Не видно, чтобы автор пытался опереться на знакомство читателя с барьерами памяти, как их комбинирование создаёт Acquire/Release семантики.

Здравствуйте, netch80, Вы писали:

N>Так от чего предохраняться было надо? От того, что вообще может нить не создаться? Так это точно за пределами примера. Ещё от чего?

От срабатывания деструктора std::thread до вызова join() ?

Здравствуйте, netch80, Вы писали:

N>Такое? Читаем про emplace_back:

Нужно было пример полностью привести.

void do_work(unsigned id);

void f()
{
 std::vector<std::thread> threads;

 for(unsigned i=0;i<=20;++i)
 {
  threads.emplace_back(do_work,i);
 }

 for(auto& entry:threads)
  entry.join();
}

Читаем в начале главы:

Научившись запускать поток, нужно принять однозначное решение, ждать ли
его завершения (присоединив его — см. подраздел 2.1.2) или пустить его на самотек
(путем его отсоединения — см. подраздел 2.1.3). Если не принять решение до уничтожения объекта std::thread, то программа завершится (деструктор std::thread
вызовет метод std::terminate()). Поэтому даже при выдаче исключений необходимо убедиться, что поток правильно присоединен или отсоединен.

	Я тупой, и у меня вопрос...
	Что произойдет, если на второй итерации emplace_back выкинет исключение?

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Что произойдет, если на второй итерации emplace_back выкинет исключение?

От std::terminate в главной нитке выбьет весь процесс.
Для судьбы процесса уже неважно, что от деструктора в main произойдёт такой же terminate и даже чуть раньше.
Разумеется, полноценный реальный код так не пишут, но пример тут на другое.
Вы считаете, что тут сразу надо было описывать пример с полной надёжностью для всех случаев? Я не согласен, это методологически избыточно.

Здравствуйте, a7d3, Вы писали:

N>>2012, русский, ДМК.

N>>Смешной наезд.
N>>У меня эта тема давно и прочно освоена на C/C++ на pthreads, на других языках, и чуть-чуть в ядре но именно с родными средствами C++11 до этого не приходилось сталкиваться. И у меня впечатления очень положительные: по сути, компактно, при этом с изложением не только специфики C++ в реализации средств синхронизации, но и обоснования такой специфики.
N>>Приведите пример явной "гадости" с точностью до страницы или хотя бы до главы.

A>Это не наезд,

Ну когда "Все кто хорошо отзывались — <куча уничижений>", то наезд.

A> а вопрос — полностью ли была прочитана книжка или же только местами.

Не читал справочные приложения. Остальное внимательно прочитал. Но, как уже сказал, меня интересовала исключительно специфика реализации в C++ по сравнению с уже известным.
Для полноты картины надо смотреть на качество подачи для тех, кто вообще не в теме до открытия книги. И вот тут я снова слова типа "узревшие какой-то непонятный свет в оконце схватив эту книжку в руки" считаю положительной оценкой — если для новичков в этой тематике (очень сложной и миноопасной) она полезна.

A>Автор переливает из пустое в порожнее, как пример можно взять многократную реализацию очереди или стэка. Из главы в главу и с весьма незначительными изменениями и длительными рассуждениями про них. Сделал на копейку, рассказывает так словно миллион сотворил, потом опять тоже самое, через некоторое время снова опять двадцать пять.

Про "на копейку" и "на миллион" я пропущу, как чисто эмоциональное описание. По сути претензии какие? Что выбраны те структуры данных, на которых в реальности чаще всего и воплощают синхронизацию? И что описываются даже мельчайшие эффекты, в которых реально легко налажать и как это может влиять на качество работы? Так это наоборот в плюс.

A> А уж насколько криво и косо изложено про модель памяти — это явное косноязычие. Не видно, чтобы автор пытался опереться на знакомство читателя с барьерами памяти, как их комбинирование создаёт Acquire/Release семантики.

А почему вы предполагаете 1) какое-то знакомство с "барьерами памяти" и 2) что описывать через них будет лучше (и даже просто законно)?

Барьеры совершенно не обязаны существовать в явном виде, это уже артефакт реализации. Да, в текущей архитектуре она именно такая, но это 1) не цель синхронизации, а средство, 2) может поменяться в будущем. Вся теория этой синхронизации основана на отношениях типа happens-before, а не на барьерах, и думать именно надо в понятиях исключения неподходящего порядка событий. Так почему автор должен был вспоминать барьеры? Это же не книга по ассемблеру, и код может, при сохранении корректности, неоднократно вывернуться наизнанку.

Здравствуйте, netch80, Вы писали:

N>Про "на копейку" и "на миллион" я пропущу, как чисто эмоциональное описание. По сути претензии какие? Что выбраны те структуры данных, на которых в реальности чаще всего и воплощают синхронизацию? И что описываются даже мельчайшие эффекты, в которых реально легко налажать и как это может влиять на качество работы? Так это наоборот в плюс.

Автор не хотел написать хорошую книжку, а хотел угнаться за двумя зайцами — написать что-то интересно и для тёртых и для новичков.
Закономерно, что получилась хрень, которая плохо заходит как новичкам, так и вызывает отторжение у тёртых.

Нет смысла сводить вопрос к личным предпочтениям, заявляя, что дескать лично мне понравилось и а вы все хоть обделайтесь. Дело в том, как эта конкретная книжка зашла в профессиональную среду — тех людей, кто на этом самом С++ работу работает. Можно ли ею обучить человека соображающего в OOA/D, SOLID, но несведущего в многопоточке тому, что же нового появилось в С++11 по части поддержки работы с тредами? Может ли профи знакомый с lock-free не по наслышке, но слабо представляющий себе современные средства языка С++ без отвращения прочитать всю эту водянистую писанину?

Судить об этом надо не по своему личному примеру, не по своему личному разумению и представлению.

A>> А уж насколько криво и косо изложено про модель памяти — это явное косноязычие. Не видно, чтобы автор пытался опереться на знакомство читателя с барьерами памяти, как их комбинирование создаёт Acquire/Release семантики.

N>А почему вы предполагаете 1) какое-то знакомство с "барьерами памяти" и 2) что описывать через них будет лучше (и даже просто законно)?

N>Барьеры совершенно не обязаны существовать в явном виде, это уже артефакт реализации. Да, в текущей архитектуре она именно такая, но это 1) не цель синхронизации, а средство, 2) может поменяться в будущем. Вся теория этой синхронизации основана на отношениях типа sequenced-before, а не на барьерах, и думать именно надо в понятиях исключения неподходящего порядка событий. Так почему автор должен был вспоминать барьеры? Это же не книга по ассемблеру, и код может, при сохранении корректности, неоднократно вывернуться наизнанку.

Вот тут или разговор про разные вещи или попытка уйти от темы разговора через растекание мыслью по древу.
Есть старое доброе LoadLoad, LoadStore, StoreLoad, StoreStore и компановка таковых в Acquire/Release для создания тех же критических секций без блокирующих примитивов, сродни мьютексов.
Отдельные варианты аппаратных платформ по разному реализуют эти самые барьеры, в силу своих ISA (instruction set architecture).

А есть условно стандарт С++, который со своими абстракциями на тему реордеринга операций на этапе компиляции. Например, упомянутое sequenced-before вообще никаким боком к модели памяти с многопоточкой, поскольку из окрестностей sequence points.

Здравствуйте, a7d3, Вы писали:

A>Нет смысла сводить вопрос к личным предпочтениям, заявляя, что дескать лично мне понравилось и а вы все хоть обделайтесь. Дело в том, как эта конкретная книжка зашла в профессиональную среду — тех людей, кто на этом самом С++ работу работает.
A>Судить об этом надо не по своему личному примеру, не по своему личному разумению и представлению.

Отличные слова. Теперь их бы ещё подкрепить хоть какой-то реальной статистикой. У вас есть результаты опроса прочитавших? С разделением по группам — кто опытен в C++ или нет, кто опытен в многонитевости или нет? В достаточном количестве (хотя бы от ста) и за пределами одной конкретной фирмы? Ссылку в студию, пожалуйста.

"Я так и знал" ([Wallace Breen])

И не объявляю аргументом, но отзыв Мейерса “It’s not just the best current treatment of C++11’s threading facilities ... it’s likely to remain the best for some time to come.” ко 2му изданию — это таки повод задуматься.

A> Можно ли ею обучить человека соображающего в OOA/D, SOLID, но несведущего в многопоточке тому, что же нового появилось в С++11 по части поддержки работы с тредами?

А почему именно "новое в C++11"? Тут общее описание проблематики и методов решения. На примере C++11, да — не на алголе же такое описывать. Второе издание уже описывает C++17.

A> Может ли профи знакомый с lock-free не по наслышке, но слабо представляющий себе современные средства языка С++ без отвращения прочитать всю эту водянистую писанину?

Я считаю себя вправе отнести именно к таким профи (даже с поправкой на то, что от lock-free использовал только очень простые случаи), прочитал вполне с удовольствием и не считаю эту книгу "водянистой писаниной". Ещё будете использовать Termini или всё-таки попробуете вести дискуссию без вывертов?

A>Вот тут или разговор про разные вещи или попытка уйти от темы разговора через растекание мыслью по древу.
A>Есть старое доброе LoadLoad, LoadStore, StoreLoad, StoreStore и компановка таковых в Acquire/Release для создания тех же критических секций без блокирующих примитивов, сродни мьютексов.
A>Отдельные варианты аппаратных платформ по разному реализуют эти самые барьеры, в силу своих ISA (instruction set architecture).

A>А есть условно стандарт С++, который со своими абстракциями на тему реордеринга операций на этапе компиляции. Например, упомянутое sequenced-before вообще никаким боком к модели памяти с многопоточкой, поскольку из окрестностей sequence points.

Это описка — подставил на автомате похожий термин, у меня иногда бывает. Happens before, как реально применяющийся вариант (и в стандарте тоже), подправил там.

По сути: в стандарт (хотя бы в final drafts, они доступны всем) вы не заглянули, когда это писали? Там есть happens-before и определения гарантий для разных операций через него. Вы хотели, чтобы именно термины LoadStore/etc. были названы явно? А почему собственно, если это не в местной традиции? Я не знаю, почему для вас только этот набор терминов — "старое доброе", но в этом тогда надо было скорее убеждать авторов стандарта. И для книги по C++ естественно следовать стилю стандартов C++, а не, например, Java (специально погуглил по этим словам и JSR'ы вылазят перед остальным).
Так что уводите разговор тут, похоже, вы. Реальные факты будут?

Здравствуйте, netch80, Вы писали:

N>По сути: в стандарт (хотя бы в final drafts, они доступны всем) вы не заглянули, когда это писали? Там есть happens-before и определения гарантий для разных операций через него. Вы хотели, чтобы именно термины LoadStore/etc. были названы явно? А почему собственно, если это не в местной традиции? Я не знаю, почему для вас только этот набор терминов — "старое доброе", но в этом тогда надо было скорее убеждать авторов стандарта. И для книги по C++ естественно следовать стилю стандартов C++, а не, например, Java (специально погуглил по этим словам и JSR'ы вылазят перед остальным).
N>Так что уводите разговор тут, похоже, вы. Реальные факты будут?

Есть реордеринг с релятивистскими эффектами для глобального наблюдателя. А есть переупорядочивание (реордерингом) оптимизирующего компилятора и тем, как оно в рантайме.
Нет смысла ставить знак равенства между happens-before и ненаглядной acquire/release семантикой. Если человек пытается это сделать, значит с ним лучше прекратит диалог.

Касаемо сбора статистики — как и кому зашла книжка. Чтобы отличить хорошую книжку от плохой — достаточно спросить тет-а-тет пару десятков коллег, ныне разбросанных по разным компаниям, но которых знаешь с профессиональной стороны порядка 10-15 лет.

Здравствуйте, a7d3, Вы писали:

N>>Так что уводите разговор тут, похоже, вы. Реальные факты будут?
A>Есть реордеринг с релятивистскими эффектами для глобального наблюдателя. А есть переупорядочивание (реордерингом) оптимизирующего компилятора и тем, как оно в рантайме.

Уже сказал, что второе мы тут не обсуждаем (хотя в общем его, естественно, надо учитывать тоже).

A>Нет смысла ставить знак равенства между happens-before и ненаглядной acquire/release семантикой.

Что такое "ненаглядная" acquire/release семантика? Похоже, это вы сами придумали.
У обычных acquire/release есть вполне чёткая семантика, без какой-то "ненаглядности".

A>Касаемо сбора статистики — как и кому зашла книжка. Чтобы отличить хорошую книжку от плохой — достаточно спросить тет-а-тет пару десятков коллег, ныне разбросанных по разным компаниям, но которых знаешь с профессиональной стороны порядка 10-15 лет.

То есть статистики нет. Спасибо за честный ответ.

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, a7d3, Вы писали:

N>>>Так что уводите разговор тут, похоже, вы. Реальные факты будут?
A>>Есть реордеринг с релятивистскими эффектами для глобального наблюдателя. А есть переупорядочивание (реордерингом) оптимизирующего компилятора и тем, как оно в рантайме.

N>Уже сказал, что второе мы тут не обсуждаем (хотя в общем его, естественно, надо учитывать тоже).

И каким же боком тогда становится возможным смешать happens-before и acquire/release?


A>>Нет смысла ставить знак равенства между happens-before и ненаглядной acquire/release семантикой.

N>Что такое "ненаглядная" acquire/release семантика? Похоже, это вы сами придумали.
N>У обычных acquire/release есть вполне чёткая семантика, без какой-то "ненаглядности".

Из этого высказывания стало понятно, что с русским языком у собеседника проблемы, но аргументационная база закончилась и дальше начнется тыканье пальцем в орфографические и грамматические ошибки. После неудачной попытки указать на стилистическую

A>>Касаемо сбора статистики — как и кому зашла книжка. Чтобы отличить хорошую книжку от плохой — достаточно спросить тет-а-тет пару десятков коллег, ныне разбросанных по разным компаниям, но которых знаешь с профессиональной стороны порядка 10-15 лет.

N>То есть статистики нет. Спасибо за честный ответ.

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

Здравствуйте, a7d3, Вы писали:

A>А пример собственной статистики?

Ха! Классный ход: ты же сам сказал, что нужна статистика для доказательства — вот и приводи. Твой оппонент честно с самого начала говорил, что выражает личное мнение.

Здравствуйте, a7d3, Вы писали:

N>>>>Так что уводите разговор тут, похоже, вы. Реальные факты будут?
A>>>Есть реордеринг с релятивистскими эффектами для глобального наблюдателя. А есть переупорядочивание (реордерингом) оптимизирующего компилятора и тем, как оно в рантайме.
N>>Уже сказал, что второе мы тут не обсуждаем (хотя в общем его, естественно, надо учитывать тоже).
A>И каким же боком тогда становится возможным смешать happens-before и acquire/release?

Определите "смешать". С вашим стилем уже непонятно, какое слово у вас значит в какой момент и почему. И, надеюсь, вы понимаете, что вопрос "переупорядочивание (реордерингом) оптимизирующего компилятора", хоть и плотно связан с этим, всё-таки другой.

A>>>Нет смысла ставить знак равенства между happens-before и ненаглядной acquire/release семантикой.

N>>Что такое "ненаглядная" acquire/release семантика? Похоже, это вы сами придумали.
N>>У обычных acquire/release есть вполне чёткая семантика, без какой-то "ненаглядности".

A>Из этого высказывания стало понятно, что с русским языком у собеседника проблемы, но аргументационная база закончилась и дальше начнется тыканье пальцем в орфографические и грамматические ошибки.

При чём тут "орфографические и грамматические ошибки", когда вы ввели какой-то свой неизвестный термин? Определите этот термин, чтобы было о чём говорить по сути — или признайте, что это был, мягко говоря, неудачный ход.

A> После неудачной попытки указать на стилистическую

Стилистика тут вообще ни при чём (пока что)

N>>То есть статистики нет. Спасибо за честный ответ.
A>А пример собственной статистики?

Я и не предлагал свою статистику, я высказал своё мнение. Ну и ещё привлёк высокий авторитет, но чисто вскользь. Но меня почему-то обвиняют в отсутствии статистики, которую я не предлагал. Ъ — логика.

A>Чтобы убедить собеседника, что нет попытки судить с высокой позиции личных пристрастий к цвету и вкусу фломастеров.

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

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

Ну вы обсуждайте это с воображаемым собеседником дальше.

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, a7d3, Вы писали:

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

N>Ну вы обсуждайте это с воображаемым собеседником дальше.

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