Продуктивность разработки на C++.

У тебя нет свидетельств что в помойке.

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

У меня нет свидетельств что не в помойке.

Значит оно в помойке, всё правильно.

Но его аргументы лучше твоих и он что-то делал в отличии от тебя.

У него нет никаких аргументов, как и у тебя. В противном случае он был бы не на помойке и не был на поводке у хозяина. Всё просто.

Да блин, вы не в курсе что такое MS Research? Там не разрабатывают продукты. Но результаты разработок в продукты когда-нибудь попадают.

Ну т.е. краеугольным оказывается все-таки требование о наличии рефлексии, а не миксинов.

Ну скорее да, миксины лишь дополняют другие средства.

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

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

Интересно на такое посмотреть.

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

Ну и отдельный вопрос: должен ли C++ применяться там, где такое требуется. Есть мнение, что языки с GC и уже имеющие рефлексию (что compile-time, что run-time) будут справляться с этим гораздо лучше.

По мне так GC здесь не причем. Рефлексия позволит С++ стать более высокоуровневым (правда компиляция будет еще дольше).

Остается открытым вопрос о том, много ли такой рутины в тех задачах, где C++у самое место.

Это да, нужно смотреть по ситуации.

Некоторые C++ники используют CRTP и не видят в этом никакого шаманства. Другие начинают вопить, что незачем трехэтажные шаблоны наворачивать, а то не понятно, кто и что делает.

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

но в то что в майкрософте 15 лет тратили деньги на то что не продадут еще меньше.

Ну опыт Windows CE/WinPhone как бы говорит сам за себя.

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

А можно примеров? Ну, за исключением возможности использовать строки в качестве параметров.

Вообще-то D-шные шаблоны делали с учетом опыта C++ных, а не наборот.

Нету там маркетиногово булшита. Тот продукт не продается.

Значит оно в помойке, всё правильно.

Вот анон говорит что

Там не разрабатывают продукты. Но результаты разработок в продукты когда-нибудь попадают.

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

он был бы не на помойке и не был на поводке у хозяина

Кажется, что уровень жизни у него получше чем у меня и у тебя. Но мне вообще пофиг.

Ох уж этот ваш подход с примерами)) На вскидку: Плюсовый вариант

// Включение перегруженных вариантов foo1 при помощи возвращаемого типа
template<class T>
typename std::enable_if<std::is_floating_point<T>::value, T>::type
    foo1(T t)
{
    std::cout << "foo1: float\n";
    return t;
}
 
template<class T>
typename std::enable_if<std::is_integral<T>::value, T>::type
    foo1(T t)
{
    std::cout << "foo1: int\n";
    return t;
}

T foo1(T t) if (isFloatingPoint!T)
{
    writeln("foo1: float");
    return t;
}

T foo1(T t) if (isIntegral!T)
{
    writeln("foo1: float");
    return t;
}

Правильный Дишный вариант

T foo1(T)(T t) if (isFloatingPoint!T)
{
    writeln("foo1: float");
    return t;
}

T foo1(T)(T t) if (isIntegral!T)
{
    writeln("foo1: int");
    return t;
}

Нету там маркетиногово булшита. Тот продукт не продается.

Да ты совсем крякнутый. Продаётся не продукт, а жопа индуса.

Вот анон говорит что

Чё?

Она лежит где-то в столе и из нее идеи и код использую где-то еще.

Нигде он не лежит и никакого кода там нет.

Изначально вопрос был в том, можно ли писать лоулевел без ансейф.

На него ответа нет. И тебе уже сказали почему. Но ты слишком туп, чтобы это понять. Никому не интересно что там какой школотрон может насрать и как он это назовёт. Вопрос звучит не так.

Можно ли в реальности использовать safe в лоулевел - ответ нет. И причина проста - это дерьмо в реальности никто не использовал. Это потуги от школоты для школоты, которые периметр парты никогда не выходили.

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

Кажется, что уровень жизни у него получше чем у меня и у тебя. Но мне вообще пофиг.

У поюзанной 20раз шлюхи уровень жизни ещё лучше и что? Дак и никакого уровня жизни там нет.

Правильный Дишный вариант

Чёт только выглядит он как параша. Сразу видно убогая отрыжка.

Я лучше на крестах напишу:

template<typename T> using  is_parasha = typename std::enable_if<std::is_integral<T>::value, T>::type;

template<typename T> is_parasha<T> foo1(T t) {
    std::cout << "foo1: int\n";
    return t;
}

Чем буду это дерьмо, что выше писать.

Ну это же просто верх аутизма:

foo1(T)//тут амёбы не догадались насрать другие скобочки, не С++ фигли.

(T t) if (isIntegral!T// а тут у нас какой-то явный особо-одарённый в день принятия этого великолепного решения в хату заполз с бананом на пару. Похоже он этот банан сюда и засунули.

)

Да и вообще - какого хрена у нас тут впердолился иф, при этом после имени функции? Кря-кря?

А сделать они не через жопу это так же не смогли? Допустим, введя возможность ограничивать подходящие под T типы. Сложно?

Ну, если сравнивать, то современный C++:

template<class T>
std::enable_if_t<std::is_floating_point_v<T>, T>
foo1(T t)
{
    std::cout << "foo1: float\n";
    return t;
}
 
template<class T>
std::enable_if_t<std::is_integral_v<T>, T>
foo1(T t)
{
    std::cout << "foo1: int\n";
    return t;
}

Ну а если подобные конструкции приходится писать неоднократно, то можно сократить себе объем писанины:

template<typename T>
using ensure_floating = std::enable_if_t<std::is_floating_point_v<T>, T>;

template<typename T>
using ensure_integer = std::enable_if_t<std::is_integral_v<T>, T>;

template<class T>
ensure_floating<T> foo1(T t)
{
    std::cout << "foo1: float\n";
    return t;
}
 
template<class T>
ensure_integer<T> foo1(T t)
{
    std::cout << "foo1: int\n";
    return t;
}

C++17:

template<class T>
auto foo1(T t) -> enable_if_t<is_floating_point_v<T>, T>
{
    std::cout << "foo1: float\n";
    return t;
}
 
template<class T>
auto foo1(T t) -> enable_if<is_integral_v<T>, T>
{
    std::cout << "foo1: int\n";
    return t;
}

Это именно шибка инстанцирования - невалидная синтаксически конструкция.

Больной совсем поплохел. Второе основное отличие шаблонов от макросов: шаблон представляет всегда валидный с++ код (но утиный), в нём не бывает синтаксических ошибок...

Самая же методика основана на том, что что это невалидное не попадает в кандидаты для перегрузки и всё это существует уже после инстанцирования.

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

SFINAE работает только для вывода типов параметров шаблона и не работает во время инстанцирования.

Да и шаблоны как раз таки не типизированы - ты опять всё напутал

Параметры шаблона типизированы контекстом (ограничениями сейчас и явными концептами в с+20 если повезёт) и прямо таки обычными типами при специализации.

Принципы работы шаблонов и макросов одинаковые.

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

Что ты своими убогими потугами пытаешься сказать - неясно

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

В Python отличный тернарный оператор, который соотносится с, например, существовавшим еще до него синтаксисом guard'ов в list comprehension...

Из наличия общего токена в грамматиках guard'ов и тернарного оператора не следует семантической близости конструкций. И семантической близости между ними действительно нет.

Обобщение синтаксиса хорошо когда оно сделано для семантически одинаковых, иди очень близких, сущностей, иначе это идиотизм.

Из наличия общего токена в грамматиках guard'ов и тернарного оператора не следует семантической близости конструкций. И семантической близости между ними действительно нет.

Как же нет? И там, и там это гарды. Тернарный оператор — это и есть гард. Вот пример с сопоставлением с образцом в тернарном операторе:

>>> def pair_from(a): return (a, a)
... 
>>> a, b = pair_from(5) if pair_from(5) > (4, 4) else (1, 1)
>>> a, b
(5, 5)
>>> 

Сравни с:

>>> a, b = [pair_from(a) for a in range(5, 6) if pair_from(a) > (4, 4)].pop()
    ======= ============                      ======================== - общие места
>>> a, b
(5, 5)
>>> 

И там, и там это гарды. Тернарный оператор — это и есть гард.

Прежде всего стоит заменить, что тернарный оператор всегда является простым выражением.

А что ты называешь guard'ми в питоне является всего лишь отдельной грамматической конструкцией, не выражением, предиката для filter(...), к традиционным guard'ам она не имеет отношения.

Можно было бы попробовать притянуть аналогию с настоящими guard'ами из функциональщины, но даже так семантическое сходство неполное: тернарный оператор не имеет форм без else части и настоящие guard'ы не всегда являются чисто выражениями (т.е, имеют специальные трактовки в зависимости от языка).

Синтаксис соотносится, смысл — тоже.

Сейчас тебе стоилопообезьянничать в своём традиционном стиле сравнив

def ternary(a, b, c):
    if a:
        return b
    else:
        return c

ternary = lambda a, b, c: b if a else c

Это царь?

Вот не могу сказать. Но царя в голове у сего уважаемого господина видимо нет.

Я слышал, в Development обитает какой-то «Царь». Но ни разу не сталкивался с ним.

Ты сколько уже на ЛОРе, что только «слышал»?

Царь — эдакий эксцентричный чувак. Местами неплохо владеет С, местами газирует лужи. Но процентов на 98 говорит по делу.

я тож :)

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

Так надо не слоупочить или включать удаленные. Модераторы царя не любят.

Но процентов на 98 стонет и неадекватно ноет. Не благодари

«Ну хотя бы тем, что код лаконичнее, т.е более удобный и читаемый.» «На мой взгляд главной изначальной темой была компактность кода. И тут важно, что лямбды такую компактность обеспечивают.» Это мой комментарии выше. Речь идет про код программы, а не только отдельно взятой функции. Вам пример кода с вызовом лямбды и обычной фнукции написать, чтобы было понятно, что код с ламбдами компактее или сами справитесь? Читайте всю ветку.

да никакая это не идеология. точнее, не такая, чтобы что-то там захватить. ну, прыгают там пара студентов, которые ниасилили сишечку. ну и пусть прыгают. хорошее дело ржавчиной не назовут, для начала. это маргинальное название и язык изначально рассчитывался для маргиналов. для понтов. ну, пусть понтуются. выше головы не прыгнешь и все эти памперсы (i.e. GC) - признак неосиляторства и изначальной неспособности написать что-то существенное. так что я не рассматриваю это, как вообще нечто хоть отдалённо сравнимое с сишечкой или с плюсами. это очередная песочница.

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

Знаете, хороший человек и Железным жуком не назовётся, коли на то пошло.

Хороший человек в свой ник не лепит год рождения ☺

И вообще, мелкота, что ты тут суешься со своим «авторитетным мнением»? Было бы тебе хотя бы лет 45-50!!!

так что я не рассматриваю это, как вообще нечто хоть отдалённо сравнимое с сишечкой или с плюсами. это очередная песочница.

Дело не в том, что рассматриваешь ты. Дело в том, что рассматриваются хомячки. Я уже всё это разъяснял.

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

Эдди, царь, Iron_Bug. Я смотрю, на ЛОРе появилось неплохое лобби C/old-style-C++.

Впрочем, на ЛОРе всегда любили древность.

Ну во-первых тебе емнип тоже еще не 40, а во-вторых ты тоже ни о чем кроме embedded-C не знаешь, но мнение суешь повсюду :D

Оказывается ты мне тут насрал что-то.

Больной совсем поплохел. Второе основное отличие шаблонов от макросов: шаблон представляет всегда валидный с++ код (но утиный), в нём не бывает синтаксических ошибок...

Новую ахинею придумал? Макрос из себя то же всегда представляет валидный С++-код.

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

Ни к какому выводу типов никаких ошибки отношения не имеют. Это синтаксическая некорректность. К типам она имеет отношение только через то, что работает она на уровне типов, но это просто ограничение. Ограничение и того, что компилятор не смотрит вообще в код до выбора окончательного кандидата. Его логика обязывает смотреть только на сигнатуру. Ограничение и того, что логика просто и не должна распространяться далее.

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

SFINAE работает только для вывода типов параметров шаблона и не работает во время инстанцирования.

SFINAE - это ошибка инстанцирования. Вернее методика использования нюансов работу инстанцирования, в рамках которого - невалидная сигнатура инстанса - не инстанс.

Параметры шаблона типизированы контекстом (ограничениями сейчас и явными концептами в с+20 если повезёт) и прямо таки обычными типами при специализации.

Ламерок, типизированы контекстом только инстансы. Шаблоны никакой типизации не имею - на то они и шаблоны, балаболка. А концепты - это и есть типизация шаблонов.

auto v; - это не типизация. Типизация будет только тогда, когда это будет инициализировано. Так же работает и с шаблонами.

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

Зачем ты, ламерок мне что-то кудахчешь? Ты прочитал букварик, обосрался. Для тебя, ламерка, в твоём букварике сделали допущение. Чтобы ты, малоразвитая амёба, это понял. Либо просто те, кто писали твой букварь - ламерки.

За примерами далеко ходить не надо. T::type в предоставленным выше коде - типичный тому пример. T::type для типа, в котором нет поля-типа type - это синтаксически некорректная конструкция. Ты можешь её сам, ламерок, можешь написать.

И именно подобные ошибки и авойдит SFINAE. И работает это именно так.

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

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

SFINAE работает только для вывода типов параметров шаблона и не работает во время инстанцирования.

Ну чтоб два раза не вставать:

struct ya_lamerok {
  static constexpr bool lamerok = false;
};

template<typename T> void f(decltype(T{}.lamerok) = false) {}
template<typename T> void f(decltype(T{}.lamerokx2) = false) {}


f<ya_lamerok>();

Пыхтон был песочницей для студентов

и в этом повторил путь Unix|C сёрёдки волосатых 70ых.

Имею право, ибо теперь под анонимом трещу =D

И, кстати, при чем здесь emmbedded C? У меня от силы 5% наберется эмбеддщины. Все остальное — десктопные/сетевые приложения и демоны для веб-морд.

Однако, Unix|C раскрутились и стали офигенскими, а пхытон как был говном, так говном и останется.

Хороший человек в свой ник не лепит год рождения ☺

Юзернейму 10 лет. Иди поучи уму-разуму того паренька, который его придумывал. Думаю, ей примерно в два раза больше годков, чем мне тогда. И человек на полном серьезе выдает аналитику «мне не нра, как назвали эту каку». Стыдно, товарищи.

И вообще, мелкота, что ты тут суешься со своим «авторитетным мнением»? Было бы тебе хотя бы лет 45-50!!!

Чтобы быть таким же неадекватом, как ты сейчас?

А что тебе так не нравится в питоне? Или вообще скриптовые не любишь, только си, только хардкор?

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

Вместо этого говна есть более приличные средства обработки данных: Octave, Iraf, MIDAS, IDL…

А что тебе так не нравится в питоне?

Он написал несколько скриптов для какой-то свободной САПР, FreeCAD, емнип, и это оставило неизгладимый след на его психике. Код там тоже вышел неважняцкий, к слову.

и в этом повторил путь Unix|C сёрёдки волосатых 70ых.

Неверно. У си/юникса никогда не было подобного пути. Да и реализует он совершенно другую идеологию. Си - это не криптуха язык.

Хотя на самом деле в си больше от скриптухи, но это не та скриптуха. Си - это динамический язык, но в своей логике. Это уникальная вещь. Она просто на голову выше понимания рядового адепта, да и не рядового.

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

Там точно так же пацаны не понимали того, что безопасность и ограничения - это разные вещи. Хотя радует, что есть те, кто понимает. Хотя читая пацана в другой теме - я даже не знаю как адекватность одновременно уживается с полным неадекватом. Хотя скорее всего тут дело в том, что всё это - ретрансляция, а не осознанная позиция. Запрет - это не безопасность. Запрет должен быть управляемым, а не постоянным. Нельзя забрать возможность делать скриншоты и назвать это безопасностью.

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

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

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

видимо тебе прямые цитыты из РичиДениса и тех кто в той комнате сидел и участвовал в разработке прикладного софта для лицензионого отдела атт не авторитеты

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

видимо тебе прямые цитыты из РичиДениса и тех кто в той комнате сидел и участвовал в разработке прикладного софта для лицензионого отдела атт не авторитеты

Естественно, что для меня всё это не является авторитетом, да и какие там могут быть цитаты. Но в целом да, рождение сишки произошло вопреки. Возможно в текущих реалиях она бы не родилась, но она родилась.

А то, что авторы языка на языке писать не могли - это факт. Но из этого мало что следует. Я уже давно не ассоциирую плоды творчества людей с ими самими. Это явно как-то не так работает. Зачастую люди сами не понимают того, что они, собственно, родили.

а вообще ты бы действительно определи что за ЦарьСи язык ты почитаешь

ЦарьСи - это не язык, это подход. Это идеология. Язык это лишь следствие.

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

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

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

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

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

А вот та же гнусишка интегрируется с компиляторм и в тандеме с компилятором - это совершенно иные возможности. Как уровня самого языка, так и именно связки. Для тебя язык - это не абстрактная херня, а конкретный язык управления кодогенерацией.

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

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

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

То же самое со всем остальными статическими возможностями языка. Это ещё ближе приближает нас к единообразию, к предсказуемости. У нас отношения объектов и их типов определяются чётко и ясно. Здесь и сейчас. Не в неведомой жопе.

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

В ситуации же когда всё чётко, когда всё ограничено. Когда нет ничего лишнего. Нет ничего из вне. В идеальном случае - это и позволяет воспринимать что-то целостное. Ты убрал из контекста всё лишнее.

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

Именно на этом построено восприятия ламерков. Всё что ламерок не понимает - для него рандом и божество. Случайно работает ОС, процессор, аллокаторы, компилятор случайно оптимизирует. Это такой уровень развития -2тыщи лет.

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

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

Т.е. У нас есть неопределённость с разными компиляторами? Выпиливаем их. Они не нужны. У нас есть неопределённость, либо невозможность получения желаемого результата? Мы используем возможности для решения этих проблем. asm/builtins.

То же самое и с подходом к написанию кода. Мы эту тему уже десять раз обсуждали. Когда ламерки тебе рассказывают про nullptr и прочее. Они просто не способны понять, что вменяемый человек да и вообще любая система не может действовать без доверия внутренним структурам.

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

В конечном итоге, думаю, что понятно тебе разъяснил тему разницу между истиннымСИ и истинным-запилом и плебейСи и плебей-запилом.

исчерпывающе.

однако возник связанный с повторимостью восприятия вопрос:

что-бы наличный в тебе скил отличения ЦарьСи от ХарамПыхтонNULLptr не сгинул вместе с жертвой сбитой автобусом

как достигнуть идентичного тобой описанного понимания+восприятия

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

хы. сорян если чутка похоже на см «google:ПРИТЧИ О ЛУНЕ И УЧИТЕЛЕ..»

что-бы наличный в тебе скил отличения ЦарьСи от ХарамПыхтонNULLptr не сгинул вместе с жертвой сбитой автобусом

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

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

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

Т.е. формализованное учение - это примеры и только примеры. Пока что - у меня ничего нет нужного уровня. Будет - хорошо, а не будет - ну дак что поделать. Балабол. Тут фундаментальная проблема. В одного ничего серьёзного не делается, а не в одного - тебя никто слушать не будет. Всё итак всё лучше знают. Поэтому тут есть некая ловушка.

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

палата №7

все эти памперсы (i.e. GC) - признак неосиляторства и изначальной неспособности написать что-то существенное.

В расте нет GC. Есть RAII и smart pointers, GC нету.

GC упомянул царь в комменте, на который она отвечала, в связи с Go: Продуктивность разработки на C++. (комментарий)