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

S>>А вот когда новичкам что-то в C++ объясняешь, то временами приходится прибегать к приему "просто запомните и все".
K>Приведи 5 проблем.

Почему 5, а не 10? Или не 3?

Ну, например, попробуйте объяснить новичкам в языке различия между:

template<typename T>
void f(T && v) {...}

template<typename T>
struct C {
  ...
  void f(T && v) {...}
};

или

const A & f();
...
auto a1 = f();
const auto & a2 = f();

или

struct S1 {
  void f();
};

struct S2 : S1 {...};

S2 s2;
s2.f();

class C1 {
public:
  void f();
};

class C2 : C1 {...};

C2 c2;
c2.f(); // Oops!

или почему для perfect forwarding нужно использовать std::forward<T>, а для перемещения std::move, но при этом сам std::move ничего не перемещает, более того, std::move можно применять и к константным ссылкам.

или почему в языке есть const_cast, static_cast, reinterpret_cast, но приведение в стиле Си не под запретом, но пользоваться им нельзя.

S>>Какие-то вещи в C++ хотелось бы поправить. Правила инициализации переменных, например.
K>Что с ними не так?

Их слишком много и они не очевидны.

T();
T{};
T a;
T a();
T a{};
T a(x);
T a{x};
T a = x;
T a(x, y);
T a{x, y};

S>>Или вот идея Саттера на счет in, out и inout параметров. Здравая же вроде.
K>Склероз его замучил. Пусть вспомни как оно было.

Это вы сейчас себя круче Саттера возомнили? Смело.
Позвольте нескромный вопрос: а вы вообще программировать умеете, хоть что-то про C++ знаете? Чем докажите?

У in и out есть несколько преимуществ, которые я не знаю как достичь в современном синтаксисе.

Момент первый.

Эффективность передачи значений. Например, если у меня есть:

template<typename T>
void f(const T & a) {...}

то насколько этот способ эффективен в зависимости от конкретного T? На конкретной 32-х битовой платформе, на конкретной 64-битовой? А через 10 лет? А через 20?

Тогда как:

template<typename T>
void f(in T a) {...}

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

Ну и in T защищает вот от таких опечаток:

void f(const std::string v); // Хотели &, но забыли.

опечатки такие, к сожалению, имеют место быть.

Момент второй.

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

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

A>Показалось интересным: Can C++ be 10x Simpler &amp; Safer? &mdash; Herb Sutter &mdash; CppCon 2022
A>Презентация от Герба Саттера о развитии синтаксиса для С++.

Вот оно что...
Вот откуда растут ноги всех этих Rust'ов...:

The Department of Commerce of the United States issued guidance that in response to this executive order: "... some programming languages such as C and C++ are not memory safe..." "... where possible do not use memory unsafe languages..."

— это где-то между 40-ой и 44-ой минутами из этой презентации.

До чего мы дожили!
Политики будут нам указывать на каком языке писать программы!
Маразм крепчал по всей планете
и в разных видах проявлял
ковидлы гиблые симптомы.

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

S>Почему 5, а не 10? Или не 3?
Потому что после 3 проблемы заканчиваются обычно.
Хотел тебе написать по каждой, но влом. Могу только сказать, что у тебя какие-то личные счёты с С++, твои проблемы — надуманные, а новички у тебя занимаются вуду-программированием(so-программированием) не понимая что происходит в разных точках кода, а иногда не понимая что они вообще хотят от того что написали.

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

A>Презентация от Герба Саттера о развитии синтаксиса для С++.
Как же они заколебали. Ну хочется им новый язык, ну сделайте. Зачем корёжить то, что и так нормально работает? Зачем делать из С++ ещё один синтаксический go?

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

K>Зачем корёжить то, что и так нормально работает?

Не все работает нормально, увы.
Когда много лет живешь в обнимку с C++, то кажется, что нормально.
А вот когда новичкам что-то в C++ объясняешь, то временами приходится прибегать к приему "просто запомните и все".

K>Зачем делать из С++ ещё один синтаксический go?

Какие-то вещи в C++ хотелось бы поправить. Правила инициализации переменных, например.

Или вот идея Саттера на счет in, out и inout параметров. Здравая же вроде.

Может поиграются в cppfront и придумают как в C++ это перетащить с учетом выявленных проблем. Или докажут, что хрен редьки не слаще.

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

S>>Так и Саттер пытается делать тоже самое, только копирования синтаксиса из Rust-а

FR>Ну чукча не смотритель видео, но запомнилось почему-то что Саттер хотел сам С++ домучить

К сожалению, видео посмотреть придется, т.к. хороших описаний cpp2 в репозитории самого Саттера нет

Зато уже можно на godbolt поиграться.

Показалось интересным: Can C++ be 10x Simpler &amp; Safer? &mdash; Herb Sutter &mdash; CppCon 2022
Презентация от Герба Саттера о развитии синтаксиса для С++.

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

S>Ну, например, попробуйте объяснить новичкам в языке различия между:
S>

S>template<typename T>
S>void f(T && v) {...}

S>template<typename T>
S>struct C {
S>  ...
S>  void f(T && v) {...}
S>};
S>

Это объяснить не так уж и сложно (мне приходилось это делать). Принципиальное отличе в том, что, при инстанцировании, в первом случае тип T выводит компилятор, а во втором случае задает явно сам программист (ну и далее рассказ про perfect forwarding).

Остальные примеры также объясняются довольно просто.

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

BFE>До чего мы дожили!
BFE>Политики будут нам указывать на каком языке писать программы!

Вообще это хорошая идея. Я бы ещё IPv4 запретил.

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

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

K>>Как же они заколебали. Ну хочется им новый язык, ну сделайте. Зачем корёжить то, что и так нормально работает? Зачем делать из С++ ещё один синтаксический go?

FR>Так же хотят и не переписывать огромную кодовую базу на C++ и новый язык одновременно.
Всё равно придётся переписывать как Mozilla на Rust. Попытка усидеть на двух стульях приводит к печальный последствиям. Лучше бы думали как это спаять безболезненно, а народ перепишет потом. Всё равно делать нечего т.к. всё уже написано .
FR>Тут думаю было бы правильнее делать более безопасную надстройку над C++ максимально с ним совместимую, некий аналог TypeScript для C++, этот вариант никого не должен обидеть . Гугл вроде начал пытаться это делать со своим корбоном.
Ну да, в итоге надо знать и TypeScriptС⁺⁺ и JavaScriptС++.

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

S>>>Какие-то вещи в C++ хотелось бы поправить. Правила инициализации переменных, например.
K>>Что с ними не так?

S>Их слишком много и они не очевидны.
S>

S>T();
S>T{};
S>T a;
S>T a();
S>T a{};
S>T a(x);
S>T a{x};
S>T a = x;
S>T a(x, y);
S>T a{x, y};
S>

А есть еще праздник с std::initializer_list:

std::vector<int> v1{3, 4}; // 3, 4 
std::vector<int> v2(3, 4); // 4, 4, 4

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

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

YV>>Это должен оптимизировать компилятор, а это константа при любой форме передачи.

S>

YV>>Это не опечатки, а нормальное использование оптимизирующего компилятора. Для программиста без разницы каким образом попала константа в функцию.

S>

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

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

R>Принципиальное отличе в том, что...

Спасибо, мы в курсе

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

K>Как же они заколебали. Ну хочется им новый язык, ну сделайте. Зачем корёжить то, что и так нормально работает? Зачем делать из С++ ещё один синтаксический go?

Так же хотят и не переписывать огромную кодовую базу на C++ и новый язык одновременно.
Тут думаю было бы правильнее делать более безопасную надстройку над C++ максимально с ним совместимую, некий аналог TypeScript для C++, этот вариант никого не должен обидеть . Гугл вроде начал пытаться это делать со своим корбоном.

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

A>Показалось интересным: Can C++ be 10x Simpler &amp; Safer? &mdash; Herb Sutter &mdash; CppCon 2022
A>Презентация от Герба Саттера о развитии синтаксиса для С++.

Если из этого доклада выкинуть очевидные вещи освещённые в любом гайде, в gsl, то останется 20 процентов болезненного бреда индуцированного растом.

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

K>Могу только сказать, что у тебя какие-то личные счёты с С++, твои проблемы — надуманные

Резюмируя: у меня личные счеты с C++, в C++ проблем нет, вы знаете C++ лучше Саттера.

Аминь.

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

Q>А есть еще праздник с std::initializer_list:

Q>std::vector<int> v1{3, 4}; // 3, 4 
Q>std::vector<int> v2(3, 4); // 4, 4, 4

В чём ваша проблема?! Объясните мне? Вы же понимаете что делает код?

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

A>Презентация от Герба Саттера о развитии синтаксиса для С++.
A>синтаксиса

Деградация какая-то.
Я не про сами предложения.
А про саму идею поменять... какой-то синтаксис, то есть на более важные вещи уже махнули рукой?

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

K>>Как же они заколебали. Ну хочется им новый язык, ну сделайте. Зачем корёжить то, что и так нормально работает? Зачем делать из С++ ещё один синтаксический go?

FR>Так же хотят и не переписывать огромную кодовую базу на C++ и новый язык одновременно.
FR>Тут думаю было бы правильнее делать более безопасную надстройку над C++ максимально с ним совместимую, некий аналог TypeScript для C++, этот вариант никого не должен обидеть . Гугл вроде начал пытаться это делать со своим корбоном.

Так и Саттер пытается делать тоже самое, только копирования синтаксиса из Rust-а

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

S>Так и Саттер пытается делать тоже самое, только копирования синтаксиса из Rust-а

Ну чукча не смотритель видео, но запомнилось почему-то что Саттер хотел сам С++ домучить

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

A>Показалось интересным: Can C++ be 10x Simpler &amp; Safer? &mdash; Herb Sutter &mdash; CppCon 2022
A>Презентация от Герба Саттера о развитии синтаксиса для С++.

не понял, почему вдруг он решил что тип в конце будет "simpler".
В остальном поддерживаю. Можно даже забить на новый синтаксис и ошибки не писать. Пусть компилятор пишет ворнинги ("В конце каждой улицы поставить турникеты. Да просто так. Пусть пока пропускают.").
Да и много вопросов остаются. Вот хорошо, добавили cpp2::is<T>. Но ведь аналогичные проверки были и раньше. Что поменялось?

o: std::optional<int> = {};
if(! (o is int))
    std::cout << o as int;

ушёл ли здесь UB? Если нет, то никакого решения memory safety я не вижу.

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

FR>>Так же хотят и не переписывать огромную кодовую базу на C++ и новый язык одновременно.
K>Всё равно придётся переписывать как Mozilla на Rust.

Как то она не особо в этом торопиться.

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

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

FR>>Тут думаю было бы правильнее делать более безопасную надстройку над C++ максимально с ним совместимую, некий аналог TypeScript для C++, этот вариант никого не должен обидеть . Гугл вроде начал пытаться это делать со своим корбоном.
K>Ну да, в итоге надо знать и TypeScriptС⁺⁺ и JavaScriptС++.

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

S>А вот когда новичкам что-то в C++ объясняешь, то временами приходится прибегать к приему "просто запомните и все".
Приведи 5 проблем.

S>Какие-то вещи в C++ хотелось бы поправить. Правила инициализации переменных, например.
Что с ними не так?

S>Или вот идея Саттера на счет in, out и inout параметров. Здравая же вроде.
Склероз его замучил. Пусть вспомни как оно было.

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

FR>Как то она не особо в этом торопиться.
Ну так они нищие фриварники с 2% рынка браузеров.

FR>Да ну вебщики вроде вполне живут с проектами где старый код и библиотеки на JavaScript, а все новое уже на TypeScript.
Живут, но разве это жизнь?

FR>Я же не зря именно про TypeScript написал, из-за того что он именно безболезненно позволяет в обе стороны работать.
Но это не язык в языке как я понимаю.

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

S>Их слишком много и они не очевидны.

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

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

N>Ещё добавлю, что круглыми скобками нечаянно вместо переменной можно функцию объявить. Вот это вообще совсем неочевидная штука.

Такой пример там есть

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


S>Момент первый.

S>Эффективность передачи значений. Например, если у меня есть:
S>

S>template<typename T>
S>void f(const T & a) {...}
S>

S>то насколько этот способ эффективен в зависимости от конкретного T? На конкретной 32-х битовой платформе, на конкретной 64-битовой? А через 10 лет? А через 20?
Это должен оптимизировать компилятор, а это константа при любой форме передачи.

S>Ну и in T защищает вот от таких опечаток:
S>

S>void f(const std::string v); // Хотели &, но забыли.
S>

S>опечатки такие, к сожалению, имеют место быть.
Это не опечатки, а нормальное использование оптимизирующего компилятора. Для программиста без разницы каким образом попала константа в функцию.

S>Момент второй.

S>Если аргумент помечен как out, то компилятор может бить по рукам в ситуациях, когда у нас выходной параметр, но мы из него читаем еще до того, как что-то записали.
Если это выходной параметр, то его можно только модифицировать в функции, остальное подозрительно. Если это inout, то тут ССЗБ. А вообще использование этой фигни заменяет возврат множественных значений.

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

YV>Это должен оптимизировать компилятор, а это константа при любой форме передачи.



YV>Это не опечатки, а нормальное использование оптимизирующего компилятора. Для программиста без разницы каким образом попала константа в функцию.



Матчасть подучите.

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

S>>

S>>T a(x, y);
S>>T a{x, y};
S>>

Q>А есть еще праздник с std::initializer_list:
Q>

Q>std::vector<int> v1{3, 4}; // 3, 4 
Q>std::vector<int> v2(3, 4); // 4, 4, 4
Q>

Это и подразумевалось в двух примерах выше.

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

S>Это и подразумевалось в двух примерах выше.

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

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

Q>Просто в общем случае — это разный синтаксис вызова одного и того же конструктора.

Это вообще может и не быть вызовом конструктора, а частью aggregate initialization. Можно посмотреть на пример из cppreference для вдохновения:

#include <string>
#include <array>
#include <cstdio>
 
struct S
{
    int x;
 
    struct Foo
    {
        int i;
        int j;
        int a[3];
    } b;
};
 
int main()
{
    S s1 = {1, {2, 3, {4, 5, 6}}};
    S s2 = {1, 2, 3, 4, 5, 6};  // same, but with brace elision
    S s3{1, {2, 3, {4, 5, 6}}}; // same, using direct-list-initialization syntax
    S s4{1, 2, 3, 4, 5, 6}; // error until CWG 1270:
                            // brace elision only allowed with equals sign

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

YV>Того же вам советую

Т.е. это знание матчасти вам подсказывает, что вот здесь:

template<typename T>
void f(const T & a) {...}

"а это константа при любой форме передачи." (c)

А вот здесь то же самое знание матчасти не позволяет вам заметить непреднамеренного копирования:

void f(const std::string v); // Хотели &, но забыли.

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

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

R>Это объяснить не так уж и сложно (мне приходилось это делать). Принципиальное отличе в том, что, при инстанцировании, в первом случае тип T выводит компилятор, а во втором случае задает явно сам программист (ну и далее рассказ про perfect forwarding).

Простите, а в чем смысл вашего комментария? Вы мне это объясняете? Или вы мне объясняете как лучше косяки в дизайне C++ объяснять новичкам?

Ну так остается присоединиться к T4r4sB: "спасибо, мы в курсе"

По факту же в языке есть rvalue reference и universal reference, используются для совершенно разных задач, но внешне выглядят одинаково. Выяснить что есть что можно только исходя из контекста. Вот это и нужно просто запомнить.

R>Остальные примеры также объясняются довольно просто.

А еще лучше было бы, если бы объяснять не приходилось.

И если в результатов экспериментов с Carbon или cppfront получится язык, в котором все эти тонкости не придется объяснять (по крайней мере в первые 10 лет их существования), то это будет просто здорово. ИМХО.

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

R>>Это объяснить не так уж и сложно (мне приходилось это делать). Принципиальное отличе в том, что, при инстанцировании, в первом случае тип T выводит компилятор, а во втором случае задает явно сам программист (ну и далее рассказ про perfect forwarding).

S>Простите, а в чем смысл вашего комментария? Вы мне это объясняете? Или вы мне объясняете как лучше косяки в дизайне C++ объяснять новичкам?

Мой комментарий — это ответ на ваш вопрос (предложение): "Попробуйте объяснить новичку...". Мне показалось, что вы хотите сказать, что это объяснить слишком сложно, я в свою очередь выражаю мнение, что это не так уж и сложно и предлагаю подход к объяснению, который заходит достаточно легко, по моему опыту. Что вам кажется нелогичным? И как можно по-другому интерпретировать то, что я написал?

P.S. "Косяки в дизайне C++" вы пытаетесь обосновать сложностью объяснения некоторых фич языка новичкам. Но ваше обоснование выглядит не очень убедительным, на мой взгляд. А других обоснований у вас нет, насколько я могу судить. Следовательно и сам вывод о косяках в дизайне — это просто ваша эмоциональная оценка, не более.

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

R>Мой комментарий — это ответ на ваш вопрос (преложение): "Попробуйте объяснить новичку". Мне показалось, что вы хотите сказать, что это объяснить сложно

Я не говорил про сложность, речь шла про то, что какие-то вещи приходится просто предлагать запомнить и все, логичного объяснения мне лично не ведомо. Вот же полная цитата:

А вот когда новичкам что-то в C++ объясняешь, то временами приходится прибегать к приему "просто запомните и все".

R>Что вам кажется нелогичным?

Нелогичным в ваших словах или нелогичным в некоторых аспектах языка C++?
Ваши слова логичны, но мне было непонятно как они соотносятся с моими примерами.

R>И как можно по-другому интерпретировать то, что я написал?

Как минимум, двумя вариантами:

a) вы объясняете разницу между universal reference и rvalue reference лично мне, предполагая, что я ее не знаю;

b) вы приводите мне пример объяснения, которое можно дать новичку, чтобы рассказать чем отличаются universal reference от rvalue reference.

R>P.S. "Косяки в дизайне C++" вы пытаетесь обосновать сложностью объяснения некоторых фич языка новичкам.

Нет. На мой взгляд, в языке есть свои косяки. Какие-то из них влияют на сложность языка (сильно), какие-то нет (или не сильно).

Вот те же universal references и rvalue references. На мой взгляд, явный косяк языка в том, что и для тех, и для других использовали одинаковую лексему. Задействовали бы, скажем, @@ или ^^ для обозначения universal references, было бы проще.

Universal initialization syntax сделан так, что невольно задаешься вопросом: что это было, диверсия или, что хуже, глупость?

Вот такая запись: T obj();, как по мне, так косяк. И то, что он такой же древний, как сам C++, его не оправдывает.

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

R>Следовательно и сам вывод о косяках в дизайне — это просто ваша эмоциональная оценка, не более.

Это уж как угодно. Просто я один из тех немногих, кто в C++ остается, использует C++ с удовольствием и не имеет с C++ проблем. Очень многие из тех, с кем я работал или просто общался уже давным-давно из С++ ушли и довольны. Меня C++ не особо напрягает. А вот то, что новички (особенно не зеленая молодежь, а разработчики со стажем в других языках) осваивают C++ не очень легко, для меня лично объективная реальность. Если у вас не так, то остается только позавидовать вашим условиям.

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

R>>Мой комментарий — это ответ на ваш вопрос (преложение): "Попробуйте объяснить новичку". Мне показалось, что вы хотите сказать, что это объяснить сложно

S>Я не говорил про сложность, речь шла про то, что какие-то вещи приходится просто предлагать запомнить и все, логичного объяснения мне лично не ведомо. Вот же полная цитата:
S>

А вот когда новичкам что-то в C++ объясняешь, то временами приходится прибегать к приему "просто запомните и все".

Ну я именно это и понял как "объяснить слишком сложно, поэтому просто запомните". А как это по-другому можно понять?

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

S>>

А вот когда новичкам что-то в C++ объясняешь, то временами приходится прибегать к приему "просто запомните и все".

R>Ну я именно это и понял как "объяснить слишком сложно, поэтому просто запомните". А как это по-другому можно понять?

Тем, что у меня нет логичного объяснения почему так. Ну, например, почему для rvalue references и universal references не были взяты разные лексемы. Логичного объяснения у меня нет.

А вообще это отсылка к бородатому анекдоту времен СССР:

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

Ну и т.к. это всего лишь анекдот, то в словах есть только доля шутки.

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


S>Тем, что у меня нет логичного объяснения почему так.

Ну вот я и рассказал о том самом логичном объяснении.

S>Ну, например, почему для rvalue references и universal references не были взяты разные лексемы. Логичного объяснения у меня нет.

Потому что нет в языке C++ никаких "universal references", можете воспользоваться поиском по стандарту языка, если не верите. Есть правила type matching и reference collapsing при выведении шаблонных параметров из фактических параметров функции. Возможно, эти правила и не самые простые и потребуют некоторого напряжения внимания. Но это не тот случай, который невозможно объяснить.

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

S>>Тем, что у меня нет логичного объяснения почему так.

R>Ну вот я и рассказал о том самом логичном объяснении.

Я все еще не понимаю зачем, потому что разницу в приведенных мной примерах я понимаю.

S>>Ну, например, почему для rvalue references и universal references не были взяты разные лексемы. Логичного объяснения у меня нет.

R>Потому что нет в языке C++ никаких "universal references"

"жопа есть, а слова нет" (с)

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

S>>>Тем, что у меня нет логичного объяснения почему так.

R>>Ну вот я и рассказал о том самом логичном объяснении.

S>Я все еще не понимаю зачем, потому что разницу в приведенных мной примерах я понимаю.

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

R>>Потому что нет в языке C++ никаких "universal references"
S>"жопа есть, а слова нет" (с)

Этот термин был введен Мейерсом, как раз как один из способов объяснения новых фич языка. Но в последствии не прижился, поскольку, похоже, больше запутывал, чем объяснял. То есть, "жопа" не пригодилась.

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

R>Ну вот вы сами пишете: "понимаю, но объяснить не могу".

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

R>>>Потому что нет в языке C++ никаких "universal references"
S>>"жопа есть, а слова нет" (с)

R>Этот термин был введен Мейерсом, как раз как один из способов объяснения новых фич языка.

Очень удачный термин, как по мне.

R>Но в последствии не прижился

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

R>То есть, "жопа" не пригодилась.

Жаль, что я живу в какой-то другой вселенной.

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

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

А... Ну, значит, я действительно не совсем правильно понял ваше высказывание.

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

Q>>А есть еще праздник с std::initializer_list:
K>

Q>>std::vector<int> v1{3, 4}; // 3, 4 
Q>>std::vector<int> v2(3, 4); // 4, 4, 4
K>

K>В чём ваша проблема?! Объясните мне? Вы же понимаете что делает код?

Я то понимаю, а джуниору как объяснить?
Напоминает тот мем про девочку и сложение в javascript.

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

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

BFE>>До чего мы дожили!
BFE>>Политики будут нам указывать на каком языке писать программы!

С>Вообще это хорошая идея. Я бы ещё IPv4 запретил.
А что с ним не так?

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

С>>Вообще это хорошая идея. Я бы ещё IPv4 запретил.
A>А что с ним не так?

Повсеместный NAT и сопутствующее превращение интернета в телевизор. Это в РФ хорошо — публичный статический адрес получить легко, но так далеко не везде.

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