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

P>С C++ будет непросто. А сишные функции я еще из Фортрана вызывал. Как и фортрановские из Сей.
С'шные конечно можно, но в Go interop с С действительно на серьёзном уровне. Тем не менее, не вижу особой проблемы, если int будет разным, потребует конечно дополнительного внимания. Вот только такую платформу нужно еще найти.

В Go исходники на Си можно просто включать в проект, а можно куски на Си включать в исходный файл на Go

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

A>>Насколько я понимаю, это сейчас везде так и помогает заменить операторы выражениями. Что даёт много вкусных плюшек, декларативность, главным образом.
FLY>Не понимаю, о чем речь? Вот, например, int a = b + c; разве не выражение?

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

А вообще, вот тут целый обзор на эту тему: https://softwareengineering.stackexchange.com/questions/316217/why-does-the-type-go-after-the-variable-name-in-modern-programming-languages

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

S>Вы уж определитесь к чему у вас претензии.
У меня претензии к излишней многословности и кучи знаков, которые загромождают код и нафиг не нужны. Чтобы не читать и не писать постоянно то, что и так подразумевается. Но там, где нужно акцентировать внимание, то почему бы и нет?

S>Смысл-то в том, что сишный стиль декларации переменных, скажем политкорректно, изживает себя.
По этому вернемся к Паскалевской декларации? Мы тут полвека промучались и поняли, что это тупик, давайте еще дальше откинемся.

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

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

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

A>>Язык нацелен на совместную работу с С++ с последующей заменой последнего.
CC>Ещё одного хоронить...

А кто умер-то? Rust, например, взлетел.

Недавно Страуструп проговорился, что на modern C++ мало кто пишет. Пишут на Си-с-классами. Нетрудно догадаться, за счёт кого у Rust'а появилась аудитория.

A>>Наконец-то, Array называется Array, а не вектор-шмектор
CC>Если у тебя самая большая боль это название класса в по сути вспомогательной опциональной библиотеке то это ж исправляется банальным define

Во-первых.

Не то, чтобы боль... Но это признак определённой культуры. Где простые вещи называют и делают сложным и неочевидным путём. Недавно тут читал статью, как перебирать члены enum'а в C++. Раньше ты добавлял в конец Last, и итерировался от 0 до Last. Имея следующие проблемы:

1. Надо руками писать Last.
2. Не поддерживаются флаги и окна (нужен сплошной диапазон).
3. Плохо смешивать техническое поле Last и семантические поля в одном скоупе.
4. При добавлении в будущем в язык рефлексии или чего-то подобного, Last сломает enum.

Человек показал своё решение. Навертел сорок бочек арестантов. Мне стало интересно: ну хоть Last-то теперь писать не надо? Оказалось, надо писать не только Last но и First. Збс. Письня ради письни.

Во-вторых.

Нормально ты так назвал стандартную библиотеку — вспомогательная опциональная. Вон вверху тоже спрашивают, причём тут язык. А при том, что какой хороший язык ни будь, без стандартной библиотеки с её паттернами кому он нужен? Кому нужен C# без BCL?

В-третьих. Спроси у so5team, если бы он был моим начальником, а я бы написал свои define'ы, через сколько минут я бы отправился собирать манатки? (Но я бы, кстати, не стал писать define'ы).

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

M>Да, немного: Новый убивец С++

Хороша болезнь склероз: ничего не болит и новости каждый день.

M>Но там похоже даже документации нет.
M>https://github.com/carbon-language/carbon-lang/tree/trunk/docs#guides
M>

M>The guides/ directory contains to-be-written end-user documentation for developers writing programs in Carbon.

И календарные планы какие-то дикие (

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

A>>>Язык нацелен на совместную работу с С++ с последующей заменой последнего.
CC>>Ещё одного хоронить...
A>А кто умер-то? Rust, например, взлетел.
Ну не то чтоб взлетел. Хайпует, да, но это не взлёт. Язык сам с довольно маразматической идеей всё усложнить и простое сделать сложным.

A>Недавно Страуструп проговорился, что на modern C++ мало кто пишет.
А что, ему докладывают?
И что это такое — modern C++?
Всегда на плюсах писали используя ровно то, что было нужно. Что не нужно — не использовали. В "modern" коммитет уже напихал столько что если это всё сразу заюзать то потом хрен поймёшь что там наворочено.

A> Пишут на Си-с-классами. Нетрудно догадаться, за счёт кого у Rust'а появилась аудитория.
Из сишников. Которые не освоили даже базово плюсы и потому хреначат raw pointers везде, от чего и страдают.

A>Не то, чтобы боль... Но это признак определённой культуры.
STL написан ужасно, да. Но это не интегральная часть С++, у меня вон вообще своя имплементация всего что мне надо из контейнеров, работает местами заметно быстрее стандартной, более гибко там, где мне надо, нет излишеств там, где мне не надо. Уже второй десяток лет горя не знаю, дописываю туда что из нового где подсмотрел или что понадобилось.

A>Недавно тут читал статью, как перебирать члены enum'а в C++. Раньше ты добавлял в конец Last, и итерировался от 0 до Last.
А зачем их перебирать в общем случае?
Я понимаю если есть конкретная необходимость — всегда можно сделать подходящее локально решение. А вот generic перебиралку нахрена городить? Любой generic код тем хуже чем больше частных случаев в него запихано, а в enum легко могут быть и битовые флаги и очень сильно отличающиеся диапазоны.

A>Человек показал своё решение. Навертел сорок бочек арестантов. Мне стало интересно: ну хоть Last-то теперь писать не надо? Оказалось, надо писать не только Last но и First. Збс. Письня ради письни.
Человеку было нехрен делать, бывает

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

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

A> Кому нужен C# без BCL?
Без понятия кому надо C# в целом, я на нём не пишу.

A>Спроси у so5team
У него уже есть своё мнение "как правильно", смысла начинать этот срач заново нет никакого.

A> если бы он был моим начальником
Ты не хочешь чтоб он был твоим начальником.

A> а я бы написал свои define'ы, через сколько минут я бы отправился собирать манатки?
Не беда. Впрочем это был бы лучший вариант для тебя же.
Не стоит работать с пуристами, они за деревьями не видят леса и норовят всем Прокруст-стайл обрубить руки по минимальному знаменателю под соусом "как бы не случилось чего".
Такого хорошо ставить пасти и усмирять дикую молодёжь, и то потом толковых у него следует отбирать и показывать им волю.

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

Pzz>Я чё-то не понял. А зачем у них int гвоздями прибит к i32?
А зачем? int прибитый к платформе это проблема портирования. Например, было же коде int i = 0xFFFFFFFF для 32 битов, в при порте на 64 получалось UB. Для таких вещей надо специальный тип делать чтобы было ясно что тут планируется исполнить.

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

Pzz>>Я чё-то не понял. А зачем у них int гвоздями прибит к i32?
K>А зачем? int прибитый к платформе это проблема портирования. Например, было же коде int i = 0xFFFFFFFF для 32 битов, в при порте на 64 получалось UB. Для таких вещей надо специальный тип делать чтобы было ясно что тут планируется исполнить.

Угу. И этот специальный тип называется int. И main возвращает именно его.

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

S>Чтобы можно было отличать переменные от констант.
Для этого уже есть слово const.

S>вот тут стоп. В современном коде тип указывается все реже и реже.
И качество кода от этого становится всё хуже и хуже.

S> Вписывать auto или const auto -- это тоже самое, что и вписывать var или let.
Нет.

S>Потому что сейчас вместо int f(int) зачастую приходится писать что-то вроде:
S>

S>template<typename T>
S>[[nodiscard]] constexpr typename T::value_type
S>f(T && v) noexcept;
S>

S>Что выглядит так себе.
Это надо писать только в случае, если есть реальная необходимость написать именно так.
Если же надо int foo () то и написано будет int foo ()
Но ты у нас известный любитель всё переусложнить на ровном месте пуризма ради.

S>Особенно в коде тех утырков
Слово за слово, так so5team коленку и сломали

S> которые застряли в "Си с классами" и продолжают лепить имя функции на той же строке, что и тип возвращаемого значения
Я вообще крайне редко что либо переношу, у меня и декларации и вызовы в одну строку
Страдай, пурист!

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

S>Еще раз. Сейчас все чаще приходится писать:
S>auto i = 0;
S>const auto j = 42;

Приходится?
И кто же тебя заставляет так писать кроме твоего хронического пуризма?
Я, когда только auto появилось тоже попробовал так делать но быстро перестал ибо код становится просто отвратительным.
Почему не

int i = 0;
const int j = 42;

?

S>Ну да. И в общем случае начинать описание локальных переменных с var лучше, чем с имени типа.
S>

S>std::vector<some_type>::const_iterator start = v.begin();
S>

А вот какого хрена тут auto нету?
Почему не

auto start = v.begin();

?

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

S>Смысл-то в том, что сишный стиль декларации переменных, скажем политкорректно, изживает себя.
Да ладно! Он ещё на твоих похоронах простудится.

S>Чем меньше исключений и частных случаев, тем лучше. А то если начинаешь разбираться сколькими способами в C++ можно проинициализировать переменную или сколькими способами можно указать использование концепта, так что-то совсем невесело становится.
Не вижу проблемы. Используй тот, что наиболее удобен для конкретной ситуации.

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

CC>Приходится?

Да.

CC>И кто же тебя заставляет так писать кроме твоего хронического пуризма?

Типы данных, которые ХЗ что из себя представляют. Типа:

auto keys = std::views::keys(some_container);

или:

auto parser = produce< authorization_value_t >(
         token_p() >> to_lower() >> &authorization_value_t::auth_scheme,
         maybe(
            repeat( 1, N, space() ),
            produce< auth_param_t >(
                  alternatives( token68_seq, params_seq )
            ) >> &authorization_value_t::auth_param
         )
   );

или совсем уж примитивное:

void f() {
  ...
  const auto inner_func = [&](int v) { ... /* do something with v */ };
  ...
}

CC>Я, когда только auto появилось тоже попробовал так делать но быстро перестал ибо код становится просто отвратительным.

Ну что поделать, если руки кривые. Да еще и за всех не отучились говорить.

S>>Ну да. И в общем случае начинать описание локальных переменных с var лучше, чем с имени типа.
S>>

S>>std::vector<some_type>::const_iterator start = v.begin();
S>>

CC>А вот какого хрена тут auto нету?

Потому что это пример. Нет мозгов это понять, давайте я вам другой пример напишу, в котором типы опускать не получается (из текущего проекта, но слегка изменен):

mdx::expression_tree::abstract_cell_provider_uptr provider = std::make_unique<mdx::expression_tree::cell_providers::distinct>(...);

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

S>>Чтобы можно было отличать переменные от констант.
CC>Для этого уже есть слово const.

Точно?

const int * p{};

p -- это переменная, не константа.

CC>Это надо писать только в случае, если есть реальная необходимость написать именно так.

Ну надо же! А мужики-то и не знают.

CC>Если же надо int foo () то и написано будет int foo ()

Скорее всего надо будет [nodiscard]] int foo().

S>> которые застряли в "Си с классами" и продолжают лепить имя функции на той же строке, что и тип возвращаемого значения
CC>Я вообще крайне редко что либо переношу, у меня и декларации и вызовы в одну строку

Идиотизм, он может проявляться в разных ситуациях. Можно считать, что твоя точка зрения единственно верная. Можно декларации и вызовы в одну строку запихивать. Можно #define для констант в современном C++ использовать. И сишные-касты вместо C++ных.

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

S>>Чем меньше исключений и частных случаев, тем лучше. А то если начинаешь разбираться сколькими способами в C++ можно проинициализировать переменную или сколькими способами можно указать использование концепта, так что-то совсем невесело становится.
CC>Не вижу проблемы.

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

CC>Используй тот, что наиболее удобен для конкретной ситуации.

template<std::integral T>
void f1(T /*v*/) {}

void f2(std::integral auto /*v*/) {}

template<typename T>
void f3(T /*v*/) requires std::integral<T> {}

Попробуйте объяснить какой из этих вариантов наиболее удобен и почему.

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

_>В Go исходники на Си можно просто включать в проект, а можно куски на Си включать в исходный файл на Go

Значит, при проектировании Go предусмотрели возможность подключения к нему сишных модулей. С Фортраном все сложнее, потому что Фортран и Си проектировались для разных задач, на разном железе. И в MS DOS можно было собирать Си с Фортраном с использованием компиляторов одного производителя, например MS, либо NDP. А из Borland C++ мне удалось вызвать подпрограмму на Фортране только однажды. Причем она ничего не принимала и не возвращала.
А проблема с int решалась просто. В Фортране объявляем переменные INTEGER без указания размера. Смотрим, какой размер int у компилятора C. И задаем такой же опцией компилятора Фортрана. Строки (в Фортране 77 появились строковые переменные) доставляли гораздо больше головняка.

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

S>const int * p{};
S>p -- это переменная, не константа.
p это указатель на константу.

CC>>Если же надо int foo () то и написано будет int foo ()
S>Скорее всего надо будет [nodiscard]] int foo().
Я конечно понимаю что ты пурист, и все свечки у тебя просто обязаны быть в гондонах, а лучше сразу трёх.
Но вот нахрена тебе там nodiscard для int?

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

S>>>сколькими способами в C++ можно проинициализировать переменную
CC>>Не вижу проблемы.
S>Попробуйте студента научить современному C++ до нормального уровня.
Ты студент?

S>Попробуйте объяснить какой из этих вариантов наиболее удобен и почему.
Все три на помоечку!

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

S>Типы данных, которые ХЗ что из себя представляют.
А примеры ты при этом приводишь на int-ах

S>auto parser = produce< authorization_value_t >(
S> token_p() >> to_lower() >> &authorization_value_t::auth_scheme,
S> maybe(
S> repeat( 1, N, space() ),
S> produce< auth_param_t >(
S> alternatives( token68_seq, params_seq )
S> ) >> &authorization_value_t::auth_param
S> )
S> );

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

CC>>А вот какого хрена тут auto нету?
S>Потому что это пример.
И при этом в другом примере, где auto нахрен не всралось? ты его туда тем не менее влепил.
Q — Consistency!

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

S>>const int * p{};
S>>p -- это переменная, не константа.
CC>p это указатель на константу.

p -- это мутабельная переменная тип которой "const int *". Т.е. просто const недостаточно, чтобы сделать именно константу, а не переменную. ЧТД.

Тогда как в языке, который проектируется с учетом ошибок прошлого, это следует учесть и сделать, например, так:

var p: const int*; // Очевидно, что мутабельная переменная.
let c: int* = ...; // Очевидно, что немутабельная константа.

CC>Но вот нахрена тебе там nodiscard для int?

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

Пожалуй, наиболее очевидный пример -- это builder pattern:

class params {
public:
  params && set_v1(int v1) &&;
  params && set_v2(int v2) &&;
  ...
};

Вот здесь да, для возвращаемого значения nodiscard не нужен. В остальных 90+ процентах случаев nodiscard обязателен и то, что в C++ нет nodiscard-а по умолчанию -- это такой нехилых проёсёр, с которым теперь придется жить до скончания веков.

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

S>>>>сколькими способами в C++ можно проинициализировать переменную
CC>>>Не вижу проблемы.
S>>Попробуйте студента научить современному C++ до нормального уровня.
CC>Ты студент?

Вы идиот?

S>>Попробуйте объяснить какой из этих вариантов наиболее удобен и почему.
CC>Все три на помоечку!

Поздравляю с обосратушками.