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

S>У меня же опыт за последние лет 12-13 такой, что когда приходится возвращаться на стандарт-два назад, то это вызывает боль и неудобства. Например, при возврате с C++11 на C++98 не хватает лямбд и variadic templates, при возврате с C++14 на C++11 не хватает обобщенных лямбд, при возврате с C++17 на C++11 не хватает if constexpr и structured binding, при возврате с C++20 на C++17 не хватает концептов, spaceship operator и designated intitializers...

the only way to do good, efficient, and system-level and
portable C++ ends up to limit yourself to all the things that are
basically available in C. And limiting your project to C means that people
don't screw that up, and also means that you get a lot of programmers that
do actually understand low-level issues and don't screw things up with any
idiotic "object model" crap.

So I'm sorry, but for something like git, where efficiency was a primary
objective, the "advantages" of C++ is just a huge mistake. The fact that
we also piss off people who cannot see that is just a big additional
advantage.

If you want a VCS that is written in C++, go play with Monotone. Really.
They use a "real database". They use "nice object-oriented libraries".
They use "nice C++ abstractions". And quite frankly, as a result of all
these design decisions that sound so appealing to some CS people, the end
result is a horrible and unmaintainable mess.

(C) Сами-знаете-кто.

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

Аё>(C) Сами-знаете-кто.

И почему его мнение должно кого-то волновать? Тем более в конце 2024-го года?

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

S>Сейчас уже не субъективно. Раз его не может решить GPT — то это объективно сложно.

Попробуй допустить, что твой критерий верный: "Если Чат не может, значит сложно. Если сложно, значит плохо."
Представь, что станет с индустрией, которая будет жить по такому правилу, перестанет делать более сложные вещи. Ведь сам Чат не сможет больше развиваться, он дошёл до текущего уровня средней руки программиста только на том, что учился в том числе и на коде лучших.
Знаешь, что мы получим? Медленную стагнацию и деградацию. Как по мне, тот же С++ времён 2003 стандарта и расцвета книг Александреску был намного сложнее, чем сейчас. То, что Александреску делал своими многоуровневыми шаблонами, сейчас стало проще. Управление памятью в С++ стало проще. И многое другое. А всё почему? Потому что такие люди, как Александреску показывали своими сложными вещами, в какую сторону надо развивать (и упрощать!) язык.

Поэтому самый верный путь — развивайся! Не можешь развиваться в рамках С++ — переходи на другой язык и другие задачи, сейчас мир программирования так широк и глубок, что тебя ничто не ограничиает. Поэтому вместо ограничения других выбирай расширение себя. Это самый правильный путь.

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

N>Поэтому самый верный путь — развивайся! Не можешь развиваться в рамках С++ — переходи на другой язык и другие задачи, сейчас мир программирования так широк и глубок, что тебя ничто не ограничиает. Поэтому вместо ограничения других выбирай расширение себя. Это самый правильный путь.

Я не против сложных вещей. Но я против усложнения на пустом месте — где можно сделать просто — нельзя усложнять.

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

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

S>Счетчик вызовов должен занимать одну строчку, иначе с языком что-то не то.

Счётчик вызовов и можно сделать просто и в одну строчку, но не compile time. Но кому нужен изврат, на который язык не расчитывался, те и делают его через изврат (например, как Александреску в своё время). Если решение оказывается востребованным, то допиливают язык. А ты как видишь решение такой проблемы?
Какой язык, по-твоему, хорош? Попробуй на нём сделать задачу, для которой его не проектировали, посмотри на результат. Язык от этого стал прохим?

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

S>И какое из описанных там искажений позволило увидеть вам в моих словах "чрезмерное обобщение"?
Что до понятности, то регулярно приходится встречать код на Си с классами от разработчиков с десятками лет "типа опыта" за плечами, разобраться в котором может разве что сам автор. И то не факт.

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

S>>И какое из описанных там искажений позволило увидеть вам в моих словах "чрезмерное обобщение"?
V>Что до понятности, то регулярно приходится встречать код на Си с классами от разработчиков с десятками лет "типа опыта" за плечами, разобраться в котором может разве что сам автор. И то не факт.

Сперва вы не поняли то, что я вам написал (как раз ту самую цитату, которую вы в очередной раз повторили). Речь там шла о том, что в жизни есть примеры, когда сознательное ограничение в выразительных средствах не приводит к повышению понятности кода.

ХЗ где вы увидели там обобщение.

Потом вы не поняли вопрос. А вопрос состоял в том, какое именно искажение позволило увидеть "чрезмерное обобшение" там, где его не было в принципе.

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

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

R>>Ссылку на моё собственное сообщение? Зачем? Вопрос же в обосновании твоего эпитета "изврат".
S>Тогда сам мне скажи — считаешь ли что твой (как и любой другой, по сути) код счетчика в компил-тайм — не изврат. Просто скажи и я поверю тебе на слово.

Конкретно тот код основывается на так называемых loop holes, по сути баге/недосмотру в стандарте, позволяющему хранить и модифицировать состояние компилятора. Х.з., смогут ли они провернуть фарш назад и пофиксить это, потому как на этих лупхолах уже наковыряли всяких "фишек", хоть и не массово.
Да, считаю лупхолы извратом, и конкретно этот счетчик тоже. Как и любое другое состояние компилятора в момент компиляции, включая твои статические переменные в constexpr-функциях. Всё же компайл-тайм в плюсах функциональный и чистый (pure), и лучше бы он таким и оставался.

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

S>Тогда сам мне скажи — считаешь ли что твой (как и любой другой, по сути) код счетчика в компил-тайм — не изврат. Просто скажи и я поверю тебе на слово.

Ты в доктора Стравинского решил со мной поиграть?

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

Если для тебя изврат — это всё, чего нельзя добыть в готовом виде в Chat GPT, то вряд ли мы с тобой до чего-то договоримся.

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

S>Счетчик вызовов должен занимать одну строчку, иначе с языком что-то не то.

Что-то не распарсил. Что за счётчитк вызовов? И что именно должно занимать одну строчку? Если какой-то абстрактный "счетчик" помогает в решении каких-то задач, при этом он прост в использовании, то кого волнует, сколько строчек занимает реализация этого счётчика?

P.S. Если разговор всё ещё идет про мой компайл-тайм счётчик

Автор: rg45
Дата: 27.11 18:42

(в чём я не уверен), то следует понимать, что число строк в этой реализации существенно избыточно. И сделано это намеренно — для того, чтобы лучше был понятен принцип действия этого счётчика (хотя, всё это без толку, как я вижу). Минимизированная реализация выглядит существенно более компактной:

http://coliru.stacked-crooked.com/a/af944f20258845e4

template <typename T, size_t I>
struct Declaration { friend constexpr auto value(Declaration); };

template <typename T, size_t I>
struct Definition : Declaration<T, I> {friend constexpr auto value(Declaration<T, I>) { return I; }};

template <typename T, size_t I, typename E>
concept Defined = requires {{sizeof(decltype(value(Declaration<T, I>{})))}; typename E; };

template<typename T, size_t I, typename E>
constexpr size_t firstUndefined() {
   if constexpr(Defined<T, I, E>) return firstUndefined<T, I + 1, E>();
   else return I;
}

template <typename T, typename E = decltype([]{})>
inline constexpr size_t peek = firstUndefined<T, 0, E>();

template <typename T, typename E = decltype([]{})>
inline constexpr size_t tick = value(Definition<T, peek<T, E>>{});

Ну, и в чём трагедия, иметь эти 20 строк кода в отдельном файле, в который даже заглядывать не обязательно? Ведь использование этого счётчика выглядит проще некуда: compile_time::tick<class X> — всё!. В чём твоя проблема — только в том, что Chat GPT не предоставил тебе разжёванного решения на блюдечке?

Да специфика С++ такова, что работать на нём с выключенными мозгами не получается, как правило. Если тебе это не подходит, ну, возможно, тебе следует поискать для себя более "приятные" языки.

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

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

R>Ну, и в чём трагедия, иметь эти 20 строк кода в отдельном файле, в который даже заглядывать не обязательно? Ведь использование этого счётчика выглядит проще некуда: compile_time::tick<class X> — всё!. В чём твоя проблема — только в том, что Chat GPT не предоставил тебе разжёванного решения на блюдечке?

Проблема как обычно. Это работает только на C++20 и возможно выше если ничего не сломается.

Лучше бы сделали плагины на скриптовом языке для расширения функционала, а не это вот всё. То есть вместо гнобления макросов, следовало бы их развивать.

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

_>Проблема как обычно. Это работает только на C++20 и возможно выше если ничего не сломается.
_>Лучше бы сделали плагины на скриптовом языке для расширения функционала, а не это вот всё.

Ну так это уже не проблемы языка, как такового, а проблемы обратной совместимости с тем, каким язык был когда-то. Это немножко не одно и то же.

_>То есть вместо гнобления макросов, следовало бы их развивать.

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

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

_>Проблема как обычно. Это работает только на C++20 и возможно выше если ничего не сломается.

А кстати, в моей имплементации компайл-тайм счётчика использование концептов ни разу не является ключевым. Эту же идею можно реализовать и на C++11, как минимум. У меня уже этих компайл-тайм счетчиков — как на гуталиновой фабрике, начиная с С++03. И не хватало мне лишь только финта с энтропией, который был доступен, уже начиная с С++11 (не знаю, можно ли найти равноценную замену этому на С++03).

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

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

S>>Ссылкой не поделитесь?
V>"Чрезмерное обобщение — безосновательный перенос характеристик частных или даже единичных случаев на их обширные совокупности. Существует множество видов этого когнитивного искажения" обычно вот это называют "аргументом блондинки".

"Аргумент блондинки" — это "сейчас запла́чу".
А описанное это anecdotal evidence.

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

R>А кстати, в моей имплементации компайл-тайм счётчика использование концептов ни разу не является ключевым. Эту же идею можно реализовать и на C++11, как минимум. У меня уже этих компайл-тайм счетчиков — как на гуталиновой фабрике, начиная с С++03. И не хватало мне лишь только финта с энтропией, который был доступен, уже начиная с С++11 (не знаю, можно ли найти равноценную замену этому на С++03).

Мне обычно __COUNTER__ хватало

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

_>Мне обычно __COUNTER__ хватало

Ну это понятно. Именно это мне и не нравилось во всех моих предыдущих реализациях — участие препроцессора в имплементации.

Я же почему назвал имплементацию честной

Автор: rg45
Дата: 27.11 18:42

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

P.S. Только я обнаружил уже дофига мест, где "нечестная" имплементация работает, а "честная" не хочет. С совершенно невнятными объяснениями причин. Компилер как-будто сам удивляется, что у него есть состояние

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

S>И почему его мнение должно кого-то волновать? Тем более в конце 2024-го года?

Потому, что GIT давно стал стандартом, а написанные на плюсах VCS отправились на помойку истории.

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

S>>И почему его мнение должно кого-то волновать? Тем более в конце 2024-го года?

Аё>Потому, что GIT давно стал стандартом, а написанные на плюсах VCS отправились на помойку истории.

Да, да, да. Это именно потому, что они были написаны на плюсах, а не потому, что GitHub был написан на Ruby-On-Rails, ага.
Кстати, а ведь Mercurial и Fossil не были написаны на плюсах, с ними-то что не так?

Но даже если поверить в то, что Линус тогда не назвиздел и секрет успеха Git именно в том, что в его разработке не применялся C++. Какова актуальность его слов, если я разрабатываю не DVCS и не в 2004-ом, а в 2024-ом?

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

S>В последнее время думаю что не так с C++

А в C++ есть дженерики? По уму можно изначально пользовать дженерики, а когда отладились перевели на шаблоны.
Или условную компиляцию для Debug дженерики для Release шаблоны.
Зато в отладчике интеллисенсе и прочие плюшки статической компиляции
Например в C++/CLI можно использовать и дженерики и шаблоны
Generics and Templates (C++/CLI)

В С# есть Generic math

C# 11.0: Generic Math, C# Operators and Static Abstract/Virtual Interface Members

Смысл использовать перегрузку операторов как метод интерфейса

public interface IAddition<T> where T : IAddition<T>
{
    static abstract T operator +(T left, T right);
}

public class Person : IAddition<Person>
{
    public int Age { get; set; }

    public static Person operator +(Person left, Person right)
    {
        return new Person { Age = left.Age + right.Age };
    }
}

Now, with our new IAddition<T> interface, you can implement a generic Add method like you see it in the code snippet below. Note the generic type constraint that uses the new IAddition<T> interface.

public class Additions
{
    public static T Add<T>(T x, T y) where T : IAddition<T>
    {
        return x + y;
    }
}

This means now that you can use that generic Add method with Person objects. You can see this in the code snippet below.

var thomas = new Person { Age = 26 };
var julia = new Person { Age = 24 };

Person personResult = Additions.Add<Person>(thomas, julia);

var age = personResult.Age; // age is 50;

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


S>Так то когда было? Начинал вопросы задавать я еще не имея опыта особого. Посмотрите сколько времени прошло то...

Сколько? Полгода?