Re[23]: Они сделали дерьмо опять - C/C++

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

K>Например iostream. По словам Страуструпа была написанная кем-то на спор.

Цитату бы.

K>Или stl. Минуя продакшн сразу в стандарт.

Если вы не в курсе, то STL допиливался до состояния, в котором его приняли в стандарт, несколько лет. И в 1996-1997-ом годах свободные реализации STL (вроде бы от RogueWare) уже активно использовались в продакшене.

K>>>Приведите хоть один реальный случай случая когда нельзя было бы обойтись префиксами.

S>>Попробуйте выразить std::chrono::milliseconds через префиксы. Или std::chrono::steady_clock::time_point. А так же попробуйте придумать на префиксах адекватную замену для, например, using namespace std::chrono_literals.

K>Да в легкую. Например std_chrono_milliseconds.

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

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

K>Можете возразить, что длинно, но до auto stl-юзеры писали километровые std::map<..........., ...........>::const_iterator и не потели.

Многие знали про typedef.

K>Что касается литералов, то это фантастически бесполезная лабуда.

Очередной бред.

K>Вы опять на личности хотите перейти?

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

K>Я вам привел в пример один из неисправленных дефектов языка.

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

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

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

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

K>>Например iostream. По словам Страуструпа была написанная кем-то на спор.

S>Цитату бы.

Это было в книге Страуструпа "язык С++" или "дизайн и эволюция С++" точно не помню. Со слов Старуструпа, один персонаж утверждал, что средствами языка нельзя сделать нормальную библиотеку ввода вывода. В общем-то он прав т.к. для нормальной библиотеки ввода вывода в языке должна быть рефлексия. В ответ на этот вызов была написана библиотека iostream. Непродуманная студенческая поделка ограниченной функциональности. Я помню еще студентом пытался воспользоваться этим изделием для организации ввода вывода,
когда понял, что библиотека для ввода-вывода полностью не работоспособна:

    std::string s = "Hello World!";
    std::stringstream ss;
    ss << s; // поехали
    ss >> s; // приехали

как и любой здравомыслящий человек решил от поделий этого цирка шапито держатся подальше. Причем std::quoted было добавлено только в с++14, и около 20 лет программисты мучились, наступали на грабли, а сектанты все это время кричали нинужно.

K>>Или stl. Минуя продакшн сразу в стандарт.

S>Если вы не в курсе, то STL допиливался до состояния, в котором его приняли в стандарт, несколько лет. И в 1996-1997-ом годах свободные реализации STL (вроде бы от RogueWare) уже активно использовались в продакшене.

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

K>>>>Приведите хоть один реальный случай случая когда нельзя было бы обойтись префиксами.

S>>>Попробуйте выразить std::chrono::milliseconds через префиксы. Или std::chrono::steady_clock::time_point. А так же попробуйте придумать на префиксах адекватную замену для, например, using namespace std::chrono_literals.

K>>Да в легкую. Например std_chrono_milliseconds.

S>Вы в очередной раз несете бред.
Нет вы. Смотрите сами. Простой пример:

//1
class storage
{
    class blob
    {
    };
};

//2
namespace storage
{
    class storage;
    class blob;
}

//3
class storage;
class storage_blob;

Из всех видов описаний только описание через вложенный класс storage::blob самое нормальное и естественное, гораздо лучше чем пространство имен storage::storage+storage::blob и лучше формы storage_blob. Но для вложенного класса нет опережающего описания и его потребуется всегда включать через #include. Т.е. чтобы в данном случае программист не написал это будет говнокодом. Написать нормально язык не позволит

K>>Что касается литералов, то это фантастически бесполезная лабуда.

S>Очередной бред.

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

на фоне вот этих вопиющих дыр полный бред тратить усилия на такие бесполезные параши как литералы.

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

S>>Цитату бы.

K>Это было в книге Страуструпа "язык С++" или "дизайн и эволюция С++" точно не помню.

Т.е. вместо цитаты опять нужно полагаться на ваши слова.

S>>Если вы не в курсе, то STL допиливался до состояния, в котором его приняли в стандарт, несколько лет. И в 1996-1997-ом годах свободные реализации STL (вроде бы от RogueWare) уже активно использовались в продакшене.

K>Если вы не в курсе от раннего stl-мазохизма в продакшене активно отказывались и пересаживались на собственные разработки. Это уже веский повод не торопится с добавлением такой сомнительной библиотеки.

В курсе. Даже в курсе причин, по которым это происходило. Самой важной из которых была отсталось большинства тогдашних компиляторов. Поэтому если нужно было делать что-нибудь серьезное и переносимое, то до начала 2000-х собственные велосипеды были самым надежным способом. Только это не потому, что STL плохой, а потому что многие компиляторы даже слова template не понимали. А из тех, что понимали, понимать могли по-разному.

Вторая причина, по которой от STL (или кусков STL) отказываются до сих пор -- это то, что нельзя сделать универсальный инструмент, который эффективен всегда. Поэтому в каких-то конкретных условиях нужно предпочесть что-то стороннее функционалу из STL (яркие примеры std::unordered_map и std::regex).

Третья причина -- это NIH синдром.

K>Смотрите сами. Простой пример:

K>

K>//1
K>class storage
K>{
K>    class blob
K>    {
K>    };
K>};

K>//2
K>namespace storage
K>{
K>    class storage;
K>    class blob;
K>}

K>//3
K>class storage;
K>class storage_blob;

K>

Простите, а это пример чего? Почему я должен думать, что все эти описания равноценны? Если вы считаете, что второй вариант является аналогом первого, то вы что-то делаете явно не так и в первом варианте нет смысла вкладывать blob в storage.

K>Из всех видов описаний только описание через вложенный класс storage::blob самое нормальное и естественное

Сразу уточним: нормальное и естественное по вашему мнению. Которое можно смело отправлять в /dev/null на основании тех перлов, которые вы наговорили ранее.

K>Но для вложенного класса нет опережающего описания и его потребуется всегда включать через #include.

Э... Простите, а как же тогда классический pimpl работает?

class A {
   struct impl;
   std::unique_ptr<impl> impl_;

private:
   ~A();
   ...
};

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

K>Когда у вас в языке нет:
K>рефлексии
K>модульности
K>оператора возведения в степерь
K>нет стандартной формы библиотеки, т.е невозможно организовать стандартные репозитарии библиотек как в других языках
K>и т.д и т.п.

K>на фоне вот этих вопиющих дыр полный бред тратить усилия на такие бесполезные параши как литералы.

Только на моей памяти:

* в C++ не было ни исключений, ни пространств имен, ни шаблонов;
* в C++ не было ни шаблонов с переменным количеством параметров, ни лямбда-функций, ни move-semantic-и, ни регулярных выражений;
* в С++ не было ни модульности, ни рефлексии, ни менеджера пакетов...

Вы сами можете подставить в этот список отметку "сейчас мы здесь". И можно со 100% уверенностью сказать что когда в C++ завезут модули, рефлексию, сильно обогатят стандартную билиотеку и в конце-концов выживет всего один де-факто стандартный менеджер пакетов, то персонажи вроде вас все равно будут перечислять то, что им должны обязательно дать вот прямо сейчас и бесплатно просто по праву того, что они соизволили обратить свой взгляд на C++.

По поводу литералов: если они вам не нужны (или вы ими не пользуетесь) ну так и не пользуйтесь. Зачем поливать говном то, что облегчает жизнь другим C++ разработчикам?

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

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

S>>>Цитату бы.

K>>Это было в книге Страуструпа "язык С++" или "дизайн и эволюция С++" точно не помню.

S>Т.е. вместо цитаты опять нужно полагаться на ваши слова.

Вы не привыкли джентльменам верить на слово?

C's printf family of functions is an effective and often convenient I/O mechanism.
It is not, however, type-safe or extensible to user-defined types (classes and enumera-
tions). Consequently, I started looking for a type-safe, terse, extensible, and efficient
alternative to the printf family. Part of the inspiration came from the last page and
a half of the Ada Rationale [Ichbiah,1979], which argues that you cannot have a terse
and type-safe I/O library without special language features to support it. I took that as
a challenge. The result was the stream I/O library that was first implemented in 1984
and presented

K>>Если вы не в курсе от раннего stl-мазохизма в продакшене активно отказывались и пересаживались на собственные разработки. Это уже веский повод не торопится с добавлением такой сомнительной библиотеки.

S>В курсе. Даже в курсе причин, по которым это происходило. Самой важной из которых была отсталось большинства тогдашних компиляторов. Поэтому если нужно было делать что-нибудь серьезное и переносимое, то до начала 2000-х собственные велосипеды были самым надежным способом. Только это не потому, что STL плохой, а потому что многие компиляторы даже слова template не понимали. А из тех, что понимали, понимать могли по-разному.

Самой важной причиной является то, что stl криво спроектированная библиотека. В ней плохо практически все. Даже индекс и размер контейнера и тот умудрилось сделать unsigned создав программистам кучу проблем на ровном месте. Наличие совершенно бесполезных надуманных вещей таких как valarray выдает в ней академическую разработку, написанную для диссера или научной статьи. В качестве стандартной библиотеки языка эта экспериментальная разработка категорически не годится.

S>Третья причина -- это NIH синдром.
Знаете есть вещи хорошо сделанные, которыми приятно пользоватся и писать собственный велосипед желания не возникнет. stl напротив образчик плохого дизайна и анти-эстетики.

K>>Смотрите сами. Простой пример:

K>>

K>>//1
K>>class storage
K>>

S>Простите, а это пример чего? Почему я должен думать, что все эти описания равноценны? Если вы считаете, что второй вариант является аналогом первого, то вы что-то делаете явно не так и в первом варианте нет смысла вкладывать blob в storage.

K>>Из всех видов описаний только описание через вложенный класс storage::blob самое нормальное и естественное

S>Сразу уточним: нормальное и естественное по вашему мнению. Которое можно смело отправлять в /dev/null на основании тех перлов, которые вы наговорили ранее.

И по вашему в том числе. Нотацию с префиксами вы сами забраковали постами выше, ну а класс storage в пространстве имен storage и комментариев не требует.

K>>Но для вложенного класса нет опережающего описания и его потребуется всегда включать через #include.

S>Э... Простите, а как же тогда классический pimpl работает?
S>

S>class A {
S>   struct impl;
S>   std::unique_ptr<impl> impl_;

S>private:
S>   ~A();
S>   ...
S>};
S>

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

Мне трудно говорить с человеком который не понимает термин "опережающее описание (forward declaration)".

//Storage.h
struct Storage
{
    struct Blob
    {

    };
};

Класс Storage мы можем использовать без включения хедера Storage.h для этого нужно опережающее описание

struct Storage;
void foo(Stroage *stg);

С вложенным классом Storage::Blob такой номер не пройдет т.к. в языке С++ нет механизма опережающих описаний. Это баг уровня языка который нужно исправлять. Как бы вы тут не распинались, что это и не нужно.

struct Storage::Blob;
void foo(Storage::Blob *blob);

S>Только на моей памяти:

S>* в C++ не было ни исключений, ни пространств имен, ни шаблонов;
S>* в C++ не было ни шаблонов с переменным количеством параметров, ни лямбда-функций, ни move-semantic-и, ни регулярных выражений;
S>* в С++ не было ни модульности, ни рефлексии, ни менеджера пакетов...

S>Вы сами можете подставить в этот список отметку "сейчас мы здесь". И можно со 100% уверенностью сказать что когда в C++ завезут модули, рефлексию, сильно обогатят стандартную билиотеку и в конце-концов выживет всего один де-факто стандартный менеджер пакетов, то персонажи вроде вас все равно будут перечислять то, что им должны обязательно дать вот прямо сейчас и бесплатно просто по праву того, что они соизволили обратить свой взгляд на C++.

Ложечка хороша к обеду. Вы можете не дожить до того момента когда в С++ завезут все что нужно. Или С++ не доживет.
То с какой скоростью и как комитет проектирует этот язык напоминает издевательство. Было бы честнее либо заморозить С++ в актуальной версии и начать новый С++2.0 несовместимый со старым как это сделали в питоне, либо совсем отказаться от разработки языка объявив его deprecated. С моей точки зрения существующий труп смысла насиловать уже не имеет.

S>По поводу литералов: если они вам не нужны (или вы ими не пользуетесь) ну так и не пользуйтесь. Зачем поливать говном то, что облегчает жизнь другим C++ разработчикам?

Эти литералы сделаны в угоду нескольким фрикам, которым не терпелось добавить в stl константы типа в минуте 60 секунд. В остальном это лишнаяя сущность и как обычно в традициях С++ совершенно беспомощная. Попбробуйте завести литерал Н/м^2 и не говорите что нинужно. Секунды завезли, а чем паскали хуже?

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

K>Когда у вас в языке нет:
K>рефлексии
А можно пример продукта, где широко используется рефлексия и который используется более 10 лет?

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

K>Вы не привыкли джентльменам верить на слово?

Нет. Тем более, что здесь нет джентельменов.

K>C's printf family of functions is an effective and often convenient I/O mechanism.
K>It is not, however, type-safe or extensible to user-defined types (classes and enumera-
K>tions). Consequently, I started looking for a type-safe, terse, extensible, and efficient
K>alternative to the printf family. Part of the inspiration came from the last page and
K>a half of the Ada Rationale [Ichbiah,1979], which argues that you cannot have a terse
K>and type-safe I/O library without special language features to support it. I took that as
K>a challenge. The result was the stream I/O library that was first implemented in 1984
K>and presented

Все это сильно отличается от вашей интерпретации "По словам Страуструпа была написанная кем-то на спор." Потому что "я воспринял это как вызов" и "я сделал это наспор" сильно различаются по смыслу.

K>Самой важной причиной является то, что stl криво спроектированная библиотека. В ней плохо практически все. Даже индекс и размер контейнера и тот умудрилось сделать unsigned создав программистам кучу проблем на ровном месте. Наличие совершенно бесполезных надуманных вещей таких как valarray выдает в ней академическую разработку, написанную для диссера или научной статьи. В качестве стандартной библиотеки языка эта экспериментальная разработка категорически не годится.

Можно предположить, что вы считаете свое мнение непогрешимым и единственно правильным.

Но это не так. И авторы STL не единственные люди, которые считают, что размеры и индексы должны быть беззнаковыми.

K>Знаете есть вещи хорошо сделанные, которыми приятно пользоватся и писать собственный велосипед желания не возникнет. stl напротив образчик плохого дизайна и анти-эстетики.

Например? Неужели Qt?

K>И по вашему в том числе. Нотацию с префиксами вы сами забраковали постами выше,

Нотация с префиксами -- это негибко и немасштабируемо. Тут даже нет места для моего субъективизма.

K>ну а класс storage в пространстве имен storage и комментариев не требует.

Речь не про storage в пространстве storage. Речь про взаимоотношения storage и blob. Но для человека с такой непогрешимой верой в собственное мнение, может быть и непонятно.

K>>>Но для вложенного класса нет опережающего описания и его потребуется всегда включать через #include.

S>>Э... Простите, а как же тогда классический pimpl работает?
S>>

S>>class A {
S>>   struct impl;
S>>   std::unique_ptr<impl> impl_;

S>>private:
S>>   ~A();
S>>   ...
S>>};
S>>

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

K>Мне трудно говорить с человеком который не понимает термин "опережающее описание (forward declaration)".

Пипец. А вот это что в примере, который вы, очевидно, не поняли:

class A {
   struct impl;
   std::unique_ptr<impl> impl_;

K>struct Storage;
K>void foo(Stroage *stg);
K>

Где здесь использование?

K>С вложенным классом Storage::Blob такой номер не пройдет т.к. в языке С++ нет механизма опережающих описаний. Это баг уровня языка который нужно исправлять. Как бы вы тут не распинались, что это и не нужно.

K>

K>struct Storage::Blob;
K>void foo(Storage::Blob *blob);
K>

Так может вы наконец-то разродитесь примером того, где это реальная проблема?

K>То с какой скоростью и как комитет проектирует этот язык напоминает издевательство. Было бы честнее либо заморозить С++ в актуальной версии и начать новый С++2.0 несовместимый со старым как это сделали в питоне, либо совсем отказаться от разработки языка объявив его deprecated. С моей точки зрения существующий труп смысла насиловать уже не имеет.

Ну так сделайте. Кто вам мешает?

C++ развивается силами добровольцев. Если есть идеи вы можете продвинуть их в C++.

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

K>Эти литералы сделаны в угоду нескольким фрикам, которым не терпелось добавить в stl константы типа в минуте 60 секунд.

Значит этих фриков, как минимум, на одного больше.

K>Попбробуйте завести литерал Н/м^2 и не говорите что нинужно. Секунды завезли, а чем паскали хуже?

Ну заведите. Кто вам запрещает?

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

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

K>>Когда у вас в языке нет:
K>>рефлексии
BFE>А можно пример продукта, где широко используется рефлексия и который используется более 10 лет?

В objective-c рефлексия с 1983г

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

K>>>Когда у вас в языке нет:
K>>>рефлексии
BFE>>А можно пример продукта, где широко используется рефлексия и который используется более 10 лет?
K>В objective-c рефлексия с 1983г

Допустим. Повторюсь: можете назвать продукт (не язык, а программу), где широко используется рефлексия и который используется более 10 лет?

Здравствуйте, B0FEE664, Вы писали:
BFE>Допустим. Повторюсь: можете назвать продукт (не язык, а программу), где широко используется рефлексия и который используется более 10 лет?

В Java фреймворках используется, не в курсе что ли? И софта на них может больше, чем на С++.

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

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

K>>Вы не привыкли джентльменам верить на слово?

S>Нет. Тем более, что здесь нет джентельменов.

K>>C's printf family of functions is an effective and often convenient I/O mechanism.
K>>It is not, however, type-safe or extensible to user-defined types (classes and enumera-
K>>tions). Consequently, I started looking for a type-safe, terse, extensible, and efficient
K>>alternative to the printf family. Part of the inspiration came from the last page and
K>>a half of the Ada Rationale [Ichbiah,1979], which argues that you cannot have a terse
K>>and type-safe I/O library without special language features to support it. I took that as
K>>a challenge. The result was the stream I/O library that was first implemented in 1984
K>>and presented

S>Все это сильно отличается от вашей интерпретации "По словам Страуструпа была написанная кем-то на спор." Потому что "я воспринял это как вызов" и "я сделал это наспор" сильно различаются по смыслу.

Никакой принципиальной разницы нет т.к. мотивация была не рациональной, а эмоциональной. Личное спортивное достижение, которое нужно было скромно положить на полочку, а не тащить в стандарт языка.

K>>Самой важной причиной является то, что stl криво спроектированная библиотека. В ней плохо практически все. Даже индекс и размер контейнера и тот умудрилось сделать unsigned создав программистам кучу проблем на ровном месте. Наличие совершенно бесполезных надуманных вещей таких как valarray выдает в ней академическую разработку, написанную для диссера или научной статьи. В качестве стандартной библиотеки языка эта экспериментальная разработка категорически не годится.

S>Можно предположить, что вы считаете свое мнение непогрешимым и единственно правильным.
S>Но это не так. И авторы STL не единственные люди, которые считают, что размеры и индексы должны быть беззнаковыми.

Конечно, считаю правильным и единственно верным. И авторы java так считают. И авторы С#. В них индексы знаковые. Это вполне разумное и очевидное решение чтобы избежать проблем смешанной арифметики

K>>Знаете есть вещи хорошо сделанные, которыми приятно пользоватся и писать собственный велосипед желания не возникнет. stl напротив образчик плохого дизайна и анти-эстетики.

S>Например? Неужели Qt?

K>>И по вашему в том числе. Нотацию с префиксами вы сами забраковали постами выше,

S>Нотация с префиксами -- это негибко и немасштабируемо. Тут даже нет места для моего субъективизма.

Просто у вас не хватает воображения. Есть проекты на ~100Мб кода которые с префиксами вполне живут и хорошо масштабируются.

K>>ну а класс storage в пространстве имен storage и комментариев не требует.

S>Речь не про storage в пространстве storage. Речь про взаимоотношения storage и blob. Но для человека с такой непогрешимой верой в собственное мнение, может быть и непонятно.

K>>>>Но для вложенного класса нет опережающего описания и его потребуется всегда включать через #include.

S>Пипец. А вот это что в примере, который вы, очевидно, не поняли:
S>

S>class A {
S>   struct impl;
S>   std::unique_ptr<impl> impl_;
S>

K>>

K>>struct Storage;
K>>void foo(Stroage *stg);
K>>

Вот теперь попробуйте вынести его за пределы класса.

S>Где здесь использование?

K>>С вложенным классом Storage::Blob такой номер не пройдет т.к. в языке С++ нет механизма опережающих описаний. Это баг уровня языка который нужно исправлять. Как бы вы тут не распинались, что это и не нужно.

K>>

K>>struct Storage::Blob;
K>>void foo(Storage::Blob *blob);
K>>

S>Так может вы наконец-то разродитесь примером того, где это реальная проблема?

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

K>>То с какой скоростью и как комитет проектирует этот язык напоминает издевательство. Было бы честнее либо заморозить С++ в актуальной версии и начать новый С++2.0 несовместимый со старым как это сделали в питоне, либо совсем отказаться от разработки языка объявив его deprecated. С моей точки зрения существующий труп смысла насиловать уже не имеет.

S>Ну так сделайте. Кто вам мешает?
S>C++ развивается силами добровольцев. Если есть идеи вы можете продвинуть их в C++.
S>Но есть ощущение, что дальше самовлюбленного высказывания собственного бреда на RSDN, вы дальше пройти не сможете. В принципе.

Мне есть на что тратить время.

K>>Эти литералы сделаны в угоду нескольким фрикам, которым не терпелось добавить в stl константы типа в минуте 60 секунд.

S>Значит этих фриков, как минимум, на одного больше.

Вот это то и плохо.

K>>Попбробуйте завести литерал Н/м^2 и не говорите что нинужно. Секунды завезли, а чем паскали хуже?

S>Ну заведите. Кто вам запрещает?

Как минимум то, что в С++ нет оператора возведения в степень

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

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

K>>>>Когда у вас в языке нет:
K>>>>рефлексии
BFE>>>А можно пример продукта, где широко используется рефлексия и который используется более 10 лет?
K>>В objective-c рефлексия с 1983г

BFE>Допустим. Повторюсь: можете назвать продукт (не язык, а программу), где широко используется рефлексия и который используется более 10 лет?

Вот здесь тысячи их
https://apps.apple.com/ru/genre/mac/id39?mt=12

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

K>Конечно, считаю правильным и единственно верным.

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

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

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

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

K>>Конечно, считаю правильным и единственно верным.

S>На этих словах смыл разговора с вами окончательно пропал. Бесполезно объяснять что-то персонажам, не допускающим существование альтернативных точек зрения.

Вы просто не успеваете за линией партии.
Начиная с С++20 вводится signed size, как обычно начинают исправлять баги спустя 20 лет
https://en.cppreference.com/w/cpp/iterator/size

S>Тем более, что даже примеров кода из вас вытащить не представляется возможным.
Примеров было достаточно. Да и сама проблема не сложнее выеденного яйца.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0289r0.pdf

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

BFE>>Допустим. Повторюсь: можете назвать продукт (не язык, а программу), где широко используется рефлексия и который используется более 10 лет?
lpd>В Java фреймворках используется, не в курсе что ли? И софта на них может больше, чем на С++.

Да неужели? Вот, возьмём Eclipse. Допустим с его помощью я редактирую текстовый файл. Как и для чего используется Рефлексия в этом случае?

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

K>Вот здесь тысячи их
K>https://apps.apple.com/ru/genre/mac/id39?mt=12
И как же они использую рефлексию и для чего?

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

BFE>Да неужели? Вот, возьмём Eclipse. Допустим с его помощью я редактирую текстовый файл. Как и для чего используется Рефлексия в этом случае?

Рефлексия используется для DI-контейнеров. Самое очевидное применение. Затем идёт сериализация-десериализация.

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

K>Вот здесь тысячи их
K>https://apps.apple.com/ru/genre/mac/id39?mt=12

какая-то странная ссылка. Вроде должны быть приложения, но ни одного нет.

Здравствуйте, Kluev, Вы писали:
K>Вы просто не успеваете за линией партии.
K>Начиная с С++20 вводится signed size, как обычно начинают исправлять баги спустя 20 лет
K>https://en.cppreference.com/w/cpp/iterator/size

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

Такой код https://wandbox.org/permlink/emWjupaUQ0OMxca7

int main() 
{
    std::vector<int> v = { 3, 1, 4 };

    // since C++20 the signed size (ssize) can avail
    int i = ssize(v);
    for (--i; i != -1; --i) {
        std::cout << v[i] << ' ';
    }
    std::cout << "\n" "i = " << i << '\n';
}

Выдаст предупреждение там где ssize_t не ялвяется int (т.е. практически на всех современных платформах):

prog.cc: In function 'int main()':
prog.cc:20:18: warning: conversion from 'std::common_type_t<long int, long int>' {aka 'long int'} to 'int' may change value [-Wconversion]
20 | int i = ssize(v);
| ~~~~~^~~

S>>Тем более, что даже примеров кода из вас вытащить не представляется возможным.
K>Примеров было достаточно. Да и сама проблема не сложнее выеденного яйца.

K>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0289r0.pdf

https://botondballo.wordpress.com/2016/03/21/trip-report-c-standards-meeting-in-jacksonville-february-2016/

Proposals for which further work is encouraged:
...
Forward declarations of nested classes. This would allow things like X::A* to appear in a header without requiring a definition for X to also appear in the header (forward-declarations of X and X::A will be sufficient). EWG found the use case compelling, because currently a lot of class definitions to appear in headers only because interfaces defined in the header use pointers or references to nested classes of the type. Several details still need to be worked out. (For example, what happens if a definition of X does not appear in any other translation unit (TU)? What happens if a definition of X appears in another TU, but does not define a nested class A? What happens if it does define a nested class A, but it’s private? The answer to some or all of these may have to be “ill-formed, no diagnostic required”, because diagnosing errors of this sort would require significant linker support.)

"Let's go. In and out. Twenty minute adventure."

От:	so5team	https://stiffstream.com
Дата:	18.06.20 20:21
Оценка:

	От:	Kluev
	Дата:	19.06.20 09:48
	Оценка:	2 (1) +1 -1

От:	so5team	https://stiffstream.com
Дата:	19.06.20 12:46
Оценка:	+1

	От:	Kluev
	Дата:	19.06.20 15:09
	Оценка:	+2

	От:	B0FEE664
	Дата:	19.06.20 15:34
	Оценка: