Здравствуйте, so5team, Вы писали:
S>Код на C++ сразу же сталкивается, например, с размером char-а, int-а и void*, которые на разных платформах могут быть слишком разные (вплоть до того, что sizeof(char) == sizeof(int) и в char 32 бита). Тогда как для Java или C# есть песочница с некоторыми гарантиями от JVM/.NET
А если я напишу программу только с использованием всяких int64_t, то C++ встанет на один уровень с C#, т.к. на разных платформах будет одинаковый размер?
S>Кто-то помнит старый афоризм о том, что "люди считают, что Java кроссплатформенный язык, на самом деле это язык одной платформы" (ну или как-то в этом духе).
Здравствуйте, karbofos42, Вы писали:
S>>Код на C++ сразу же сталкивается, например, с размером char-а, int-а и void*, которые на разных платформах могут быть слишком разные (вплоть до того, что sizeof(char) == sizeof(int) и в char 32 бита). Тогда как для Java или C# есть песочница с некоторыми гарантиями от JVM/.NET
K>А если я напишу программу только с использованием всяких int64_t, то C++ встанет на один уровень с C#, т.к. на разных платформах будет одинаковый размер?
Всяких int64_t может не быть, они опциональные. Тогда скорее уж int_fast64_t/int_least64_t, но тогда придется заморачиваться с их реальными размерностями в случае, если нужно их сериализовывать или как-то оптимально размещать в памяти (например, в разделяемой).
S>>Кто-то помнит старый афоризм о том, что "люди считают, что Java кроссплатформенный язык, на самом деле это язык одной платформы" (ну или как-то в этом духе).
K>А JavaScript под сколько платформ?
Здравствуйте, dmitry_npi, Вы писали:
S>>Вот они сделали, что std::strong_ordering::equal и прочие нельзя было запихнуть в switch case. S>>Но это не проблема, пишем враппер! _>/*много устрашающего кода*/ _>Иногда я думаю, не зря ли я ушёл в C# из C++, всё-таки проприетарщина, а у нас импортозамещение, санкции и всё такое... Но как гляну на это, и думаю — нет, не зря. Плюсовики, вы там совсем свихнулись, что ли? Нельзя это написать как-то попроще? Зачем это вообще? Как потом это разбирать пришедшему на проект?
Конечно можно написать проще:
#include <iostream>
int main()
{
const auto cmp = 0./0. <=> 1. ;
const auto result =
[&]
{
if ( cmp == cmp.less ) return"less";
if ( cmp == cmp.greater ) return"greater";
if ( cmp == cmp.unordered ) return"unordered";
return"equivalent";
}();
std::cout << result << std::endl;
return 0;
}
Просто автор хотел заморочиться. Зачем — это к автору.
S>>>Можно посмотреть на C# работающий без .NET?
K>>Native AOT так-то имеется.
S>При этом подразумевается, что сам .NET должен там же быть скомпилирован в Native AOT.
В свое время когда появился .Net Native для UWP как раз и стали делать .Net Core для того, что бы дробить нетовские сборки.
Кроме того из сборок вырезают только связанный код. А затем переводится в C++ и компилируется с учетом сборки мусора
Здравствуйте, CRT, Вы писали:
BFE>> const auto cmp = 0./0. <=> 1. ;
CRT>что такое <=> я примерно понял CRT>а вот 0./0. выглядит как ноль деленное на ноль,
Это и есть ноль деленное на ноль. Результат этого деления сравнивается с 1.
CRT> что это?
Это заморочки сравнения чисел с плавающей точкой.
Это чтобы получить NaN, т.е. нечисло — одно из особых состояний числа с плавающей запятой.
Сравнение числа с нечислом даёт unordered результат.
Здравствуйте, so5team, Вы писали:
A>>Аргумент: ошибки в комитетовском дизайне C++ (сравнительно с C#) надо простить, потому, что C++ появился намного раньше C#.
S>А давайте вы приведете мою цитату, в которой озвучивался бы именно этот тезис. А?
Пожалуйста:
A>>Почему же в C#, который тоже поддерживает все те же самые парадигмы (static-методы, а главное — развитые инструменты импорта будем считать за процедурщину), всё нормально? Хотя там ФП (LINQ) похлеще будет.
S>А давайте пару-тройку причин сходу озвучим: S>2. C# делался много позже C++ и с учетом проблем C++.
Здравствуйте, Alekzander, Вы писали:
A>>>Аргумент: ошибки в комитетовском дизайне C++ (сравнительно с C#) надо простить, потому, что C++ появился намного раньше C#.
S>>А давайте вы приведете мою цитату, в которой озвучивался бы именно этот тезис. А?
A>Пожалуйста:
A>>>Почему же в C#, который тоже поддерживает все те же самые парадигмы (static-методы, а главное — развитые инструменты импорта будем считать за процедурщину), всё нормально? Хотя там ФП (LINQ) похлеще будет.
S>>А давайте пару-тройку причин сходу озвучим: S>>2. C# делался много позже C++ и с учетом проблем C++.
И? Где здесь про ошибки в дизайне? Где здесь про прощение?
Здравствуйте, so5team, Вы писали:
A>>>>Аргумент: ошибки в комитетовском дизайне C++ (сравнительно с C#) надо простить, потому, что C++ появился намного раньше C#.
S>>>А давайте вы приведете мою цитату, в которой озвучивался бы именно этот тезис. А?
A>>Пожалуйста:
A>>>>Почему же в C#, который тоже поддерживает все те же самые парадигмы (static-методы, а главное — развитые инструменты импорта будем считать за процедурщину), всё нормально? Хотя там ФП (LINQ) похлеще будет.
S>>>А давайте пару-тройку причин сходу озвучим: S>>>2. C# делался много позже C++ и с учетом проблем C++.
S>И? Где здесь про ошибки в дизайне? Где здесь про прощение?
Ты зачем-то решил включить юриста? Ну хорошо.
1. Топикстартер назвал C++ упоротым (доказательство: см. заголовок).
2. Лаптев ему ответил, что C++ упорот из-за своей мультипарадигменности (доказательство: "Просто С++ поддерживает 4 парадигмы ... Вот оно и получается такое" — "оно" это "C++", а "такое" это "упоротое").
3. Я возразил Лаптеву: если дело в мультипарадигменности, цитирую, "Почему же в C#, который тоже поддерживает все те же самые парадигмы, всё нормально?" ("всё нормально" == "он не упорот", причём, в отличие от C++). Иными словами, я спросил Лаптева, почему мультипарадигменный C# не упорот, а мультипарадигменный C++ упорот. Только в более культурных выражениях. Ещё можно заменить слово "упорот" на другое культурное выражение — "содержит ошибки в дизайне". Это ответ на твой вопрос: "Где здесь про ошибки в дизайне".
4. Приходишь ты и отвечаешь на мой вопрос: "А давайте пару-тройку причин сходу озвучим". То есть, ты сходу предлагаешь причины того, почему мультипарадигменный C# не упорот, а мультипарадигменный C++ упорот. Я назвал это поиском причин для прощения. И так оно и есть.
Таков контекст моего диалога с Лаптевым. Если ты его не понял и имел в виду что-то другое, это уже не мои проблемы. Надо сначала понять, о чём говорят два человека, прежде, чем вступать в разговор.
Здравствуйте, Alekzander, Вы писали:
A>2. Лаптев ему ответил, что C++ упорот из-за своей мультипарадигменности (доказательство: "Просто С++ поддерживает 4 парадигмы ... Вот оно и получается такое" — "оно" это "C++", а "такое" это "упоротое").
Я вовсе не уверен, что Лаптев потразумевал именно это. Ну да разговор о другом.
A>4. Приходишь ты и отвечаешь на мой вопрос: "А давайте пару-тройку причин сходу озвучим". То есть, ты сходу предлагаешь причины того, почему мультипарадигменный C# не упорот, а мультипарадигменный C++ упорот.
Не-а. Я назвал причины почему C# получился удачнее C++. Про причины "упоротости" С++ речи не было.
A>Я назвал это поиском причин для прощения.
Т.е. это вы выдумали тезис за меня, а далее по классике "сам тезис оппонента выдумал, сам его и опроверг".
На всякий случай: в языке C++ есть проблемы, при C# эти проблемы учитывали. Все. Из этого не следует ни то, что "проблемы" == "ошибки", ни, тем более, то, что кого-то за что-то нужно прощать.
Если голоса в вашей голове таки диктуют, что "проблемы == ошибки", и "за проблемы нужно прощать", то продолжайте-ка вы разговаривать с этими вашими голосами.
A>Таков контекст моего диалога с Лаптевым.
Здравствуйте, SkyDance, Вы писали:
SD>Rust еще ладно, но Go каким боком тут? Язык существует лишь пока Google как контора имеет большой вес. Если уж на то пошло, C# на порядок лучше.
Я думаю, Go выживет без Гугля. Пока все, к чему прикасался Пайк, в том или ином виде выжило.
S>Мне другое интересно: может ли C# быть скомпилирован в результирующий код без промежуточного MSIL (или как он там)?
А зачем? Compiler passes — нормальная практика во всех компиляторах. У того же GCC с десяток проходов, после каждого из которых представление меняется в нечто специфическое-промежуточное.
Более того, байт-код — хороший вариант для last minute optimization, когда он компилируется в машинный код непосредственно на той машине, где предполагается исполнение.
Здравствуйте, SkyDance, Вы писали:
S>>Мне другое интересно: может ли C# быть скомпилирован в результирующий код без промежуточного MSIL (или как он там)?
SD>А зачем? Compiler passes — нормальная практика во всех компиляторах. У того же GCC с десяток проходов, после каждого из которых представление меняется в нечто специфическое-промежуточное.
Тем не менее, в случае C++ для портирования на новую платформу нужно портировать только компилятор и минимальную часть run-time библиотеки. При этом язык к компилятору не прикручен вообще никак: хочешь gcc, хочешь clang, хочешь msvc, хочешь icc и еще какую-нибудь экзотику.
В случае платформы типа .NET (или JVM) кроме портирования компилятора нужно еще и платформу портировать. Вот и получается, что C# существует в рамках .NET.
Ну а вообще все это отсылки к старому высказыванию (вроде бы Страуструпа), которое звучало как-то так: люди думают, что Java -- это кросс-платформенный язык, а на самом деле Java -- это и есть платформа. Ну или как-то так, за дословную точность, увы, не ручаюсь.
SD>Более того, байт-код — хороший вариант для last minute optimization, когда он компилируется в машинный код непосредственно на той машине, где предполагается исполнение.
Я не копенгаген в компиляторостроении, но, помнится в адрес Java со стороны Вирта и Ко в свое время раздавалась критика не только в том, что Sun-овцы скомуниздили идеи из Oberon-а и Component Pascal-я. Но и в том, что в Java использовалась стековая VM, которая удобна для интерпретации байт-кода, но вызывает сложности при трансляции байт-кода на реальные архитектуры процессоров (типа в том же Component Pascal их промежуточное представление в этом смысле было более удачным).
