Здравствуйте, A13x, Вы писали:
A>Презентация от Герба Саттера о развитии синтаксиса для С++.
Как же они заколебали. Ну хочется им новый язык, ну сделайте. Зачем корёжить то, что и так нормально работает? Зачем делать из С++ ещё один синтаксический go?
Здравствуйте, Kernan, Вы писали:
K>Как же они заколебали. Ну хочется им новый язык, ну сделайте. Зачем корёжить то, что и так нормально работает? Зачем делать из С++ ещё один синтаксический go?
Так же хотят и не переписывать огромную кодовую базу на C++ и новый язык одновременно.
Тут думаю было бы правильнее делать более безопасную надстройку над C++ максимально с ним совместимую, некий аналог TypeScript для C++, этот вариант никого не должен обидеть . Гугл вроде начал пытаться это делать со своим корбоном.
Здравствуйте, FR, Вы писали:
K>>Как же они заколебали. Ну хочется им новый язык, ну сделайте. Зачем корёжить то, что и так нормально работает? Зачем делать из С++ ещё один синтаксический go?
FR>Так же хотят и не переписывать огромную кодовую базу на C++ и новый язык одновременно. FR>Тут думаю было бы правильнее делать более безопасную надстройку над C++ максимально с ним совместимую, некий аналог TypeScript для C++, этот вариант никого не должен обидеть . Гугл вроде начал пытаться это делать со своим корбоном.
Так и Саттер пытается делать тоже самое, только копирования синтаксиса из Rust-а
Здравствуйте, FR, Вы писали:
S>>Так и Саттер пытается делать тоже самое, только копирования синтаксиса из Rust-а
FR>Ну чукча не смотритель видео, но запомнилось почему-то что Саттер хотел сам С++ домучить
Вот оно что...
Вот откуда растут ноги всех этих 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-ой минутами из этой презентации.
До чего мы дожили!
Политики будут нам указывать на каком языке писать программы!
Маразм крепчал по всей планете
и в разных видах проявлял
ковидлы гиблые симптомы.
не понял, почему вдруг он решил что тип в конце будет "simpler".
В остальном поддерживаю. Можно даже забить на новый синтаксис и ошибки не писать. Пусть компилятор пишет ворнинги ("В конце каждой улицы поставить турникеты. Да просто так. Пусть пока пропускают.").
Да и много вопросов остаются. Вот хорошо, добавили cpp2::is<T>. Но ведь аналогичные проверки были и раньше. Что поменялось?
o: std::optional<int> = {};
if(! (o is int))
std::cout << o as int;
ушёл ли здесь UB? Если нет, то никакого решения memory safety я не вижу.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Kernan, Вы писали:
K>>Как же они заколебали. Ну хочется им новый язык, ну сделайте. Зачем корёжить то, что и так нормально работает? Зачем делать из С++ ещё один синтаксический go?
FR>Так же хотят и не переписывать огромную кодовую базу на C++ и новый язык одновременно.
Всё равно придётся переписывать как Mozilla на Rust. Попытка усидеть на двух стульях приводит к печальный последствиям. Лучше бы думали как это спаять безболезненно, а народ перепишет потом. Всё равно делать нечего т.к. всё уже написано . FR>Тут думаю было бы правильнее делать более безопасную надстройку над C++ максимально с ним совместимую, некий аналог TypeScript для C++, этот вариант никого не должен обидеть . Гугл вроде начал пытаться это делать со своим корбоном.
Ну да, в итоге надо знать и TypeScriptС++ и JavaScriptС++.
Здравствуйте, Kernan, Вы писали:
K>Зачем корёжить то, что и так нормально работает?
Не все работает нормально, увы.
Когда много лет живешь в обнимку с C++, то кажется, что нормально.
А вот когда новичкам что-то в C++ объясняешь, то временами приходится прибегать к приему "просто запомните и все".
K>Зачем делать из С++ ещё один синтаксический go?
Какие-то вещи в C++ хотелось бы поправить. Правила инициализации переменных, например.
Или вот идея Саттера на счет in, out и inout параметров. Здравая же вроде.
Может поиграются в cppfront и придумают как в C++ это перетащить с учетом выявленных проблем. Или докажут, что хрен редьки не слаще.
Здравствуйте, 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 написал, из-за того что он именно безболезненно позволяет в обе стороны работать.
Но это не язык в языке как я понимаю.
Здравствуйте, Kernan, Вы писали:
S>>А вот когда новичкам что-то в C++ объясняешь, то временами приходится прибегать к приему "просто запомните и все". K>Приведи 5 проблем.
Почему 5, а не 10? Или не 3?
Ну, например, попробуйте объяснить новичкам в языке различия между:
или почему для 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, то компилятор может бить по рукам в ситуациях, когда у нас выходной параметр, но мы из него читаем еще до того, как что-то записали.
Здравствуйте, Nuzhny, Вы писали:
N>Ещё добавлю, что круглыми скобками нечаянно вместо переменной можно функцию объявить. Вот это вообще совсем неочевидная штука.
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, то тут ССЗБ. А вообще использование этой фигни заменяет возврат множественных значений.