Здравствуйте, Shmj, Вы писали:
S>Вот вроде бы все так безобидно начиналось — макросы. Ну это же, можно сказать, почти тупая замена текста. Ну ОК, добавили параметры макроса, это чуть более сложная замена текста. S>А сейчас что? Шаблоны, constexpr и иже с ними — это фактически урезанный C++ поверх C++ S>Но, простите, как это отлаживать? Если обычный С++ можно в дебагере пройтись по шагам и все станет ясно — то тут мы просто имеем ошибку без всякой возможности понять причину ее возникновения (окромя как догадаться). S>Тот же GPT не смог ответить правильно скомпилируется ли программа и почему. А может это еще и зависит от... S>А вы сможете? Как вы это поймете? Просто догадаться нужно? А если кода сотни строк времени компиляции?
Очередная "проблема", высосанная хер знает откуда, для того, чтоб пословоблудить.
P.S. И что, какой-то придурок тебе за это деньги платит?
--
Справедливость выше закона. А человечность выше справедливости.
Я на С++ лишь любитель, так что моё мнение нужно воспринимать, конечно, аккуратно.
Лично я считаю, что код времени компиляции в общем случае это плохо.
Он уместен лишь в очень небольших объёмах там, где его использование очевидно, понятно и подчиняется неким общепринятым паттернам.
Тот же static assert идеален там, где и без него вылезет ошибка. Но со static_assert эта ошибка будет понятной, не на 5 экранов инстанцирования шаблонов, в которых потом полчаса будешь вкуривать, что, собственно, пошло не так.
А когда на коде времени компиляции делают, к примеру, полноценные парсеры, это полная дичь и таким даже пользоваться не стоит, не то, что самому такое делать.
Если хочется делать что-то сложное до компиляции, то надо генерировать исходный код. Т.е. написать отдельную программу, которая будет генерировать код. Вот и весь сказ. И эту отдельную программу можно уже отлаживать как душе угодно.
То, что что-то можно сделать, не означает, что это нужно делать.
В>может это какой-нибудь клон ChatGPT и он на нас «учится»?
Я мог бы так подумать, если бы не общался с ним здесь, лет десять уже. В том-то и трудность, что нифига он не учится. Специальная модификация нейронки — необучаемая. Для задалбывания.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, Shmj, Вы писали:
S>И вот приходит ваш начальник и говорит — ребят, мы получили 15 млн. долларов инвестиций. Теперь нужно сделать так, чтобы сайт загружался за 0.2 сек.
S>Ваши действия?
А какие тут могут быть варианты? Нужно прямиком идти на РСДН и попросить пример кода, чтоб просто глянул на экран
Здравствуйте, Shmj, Вы писали:
S>>Да и вообще код на C++ не пишите. Серьезно.
S>А на чем писать то?
Вы не с той стороны к снаряду подходите. Для аналогии: вы узнали про опасную бритву и решили, что это классный инструмент. Вот только этот инструмент противопоказан людям с тремором. А у вас тремор. Вам нельзя опасную бритву в руки брать.
Может у вас IQ 180, докторская степень по физике и куча открытий в квантовой механики. Может в каких-то областях вам вообще нет равных.
Но вот то, что и как вы пишете о программировании вообще (и о программировании на C++ в частности), наводит на мысль, что программированием на C++ вам лучше не заниматься. А то получится как вот здесь
ув.тов.netch80 написал.
S>На C++ можно написать сразу под 6 платформ:
Боюсь вас разочаровать, но изрядная часть софта на C++ разрабатывается всего под одну платформу. А какая-то часть и вообще под конкретную версию конкретной программно-аппаратной платформы.
S>Ведь дело не только в языке
Дело не в языке, дело в мозгах. Ну что поделать, если под C++ мозги не у всех заточены.
Здравствуйте, Разраб, Вы писали:
Р>Я не в курсе, но разве ГПТ не может автоматом имея спецификацию двух ЯП сконвертировать код?
На практике не работает. Он может небольшой кусок простого кода сконвертировать, и то часто с ошибками. Сконвертировать целый проект с учетом особенностей связанных библиотек, режимов сборки и т.д. — это уже нужен полноценный сильный интеллект, который вообще всех на свете лишит работы.
Вот вроде бы все так безобидно начиналось — макросы. Ну это же, можно сказать, почти тупая замена текста. Ну ОК, добавили параметры макроса, это чуть более сложная замена текста.
А сейчас что? Шаблоны, constexpr и иже с ними — это фактически урезанный C++ поверх C++
Но, простите, как это отлаживать? Если обычный С++ можно в дебагере пройтись по шагам и все станет ясно — то тут мы просто имеем ошибку без всякой возможности понять причину ее возникновения (окромя как догадаться).
Вот, для примера:
template <class T1>
struct TestStruct1
{
constexpr TestStruct1()
{
constexpr int a = sizeof(T1) + 1;
constexpr int b = sizeof(T1);
if (a < b)
static_assert(sizeof(T1) != a - 1, "Error 1");
}
};
int main()
{
TestStruct1<short> t;
}
Тот же GPT не смог ответить правильно скомпилируется ли программа и почему. А может это еще и зависит от...
А вы сможете? Как вы это поймете? Просто догадаться нужно? А если кода сотни строк времени компиляции?
Сейчас мы наблюдаем психологическую реакцию на изучение нового материала. Так как изучение нового требует умственной работы, то мозг подсознательно придумывает аргументы её не делать, а если уж и делать, то с чужой помощью.
Постоянное использование чужих мозгов приводит к слабоумию, постоянное использование только своих мозгов делает из человека чудака (ака гик).
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>... сама идея и макросов, И шаблонов ...
Дальше можно не читать. Одно только то, что ты ставишь макросы и шаблоны в один ряд, красноречиво говорит о твоей квалификации. Как говорится, у Вас не тридцатилетний опыт — у Вас годичный опыт, повторенный тридцать раз.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, vsb, Вы писали:
vsb>На C это и буду делать, ибо оно вкомпилируется бесшовно во всё это, с минимальными усилиями и с поддержкой тулзов. Ни на чём другом это не разумно делать.
Не сомневаюсь в том, что на C++ это все можно было бы сделать и быстрее, и проще, и надежнее. Но с такой ненавистью к C++ не получится, да. Поэтому лучше наговнякать еще несколько килотонн лапши на чистой Сишечке, чтобы это все потом текло и падало.
Здравствуйте, Shmj, Вы писали:
S>Вот вроде бы все так безобидно начиналось — макросы. Ну это же, можно сказать, почти тупая замена текста. Ну ОК, добавили параметры макроса, это чуть более сложная замена текста.
S>А сейчас что? Шаблоны, constexpr и иже с ними — это фактически урезанный C++ поверх C++
S>А вы сможете? Как вы это поймете? Просто догадаться нужно? А если кода сотни строк времени компиляции?
Кажется, я начинаю догадываться, как появляются мысли, что чёрных, гомосеков и нормальных должно быть в равном количестве на работе. Кто вообще сказал, что любой код можно пройти по шагам в отладчике? Есть тысячи вариантов, когда это невозможно, и ничего — как-то живут люди. Несколько примеров:
1. Что-то очень сильно аппаратное.
2. Код, который зависит от времени так, что любой останов в отладчике ломает алгоритм.
3. Распределённые системы.
4. Just-in-time компиляция.
5. Кодогенерация.
А тут простой compile-time: и static_assert можно использовать, и отладочная печать промежуточных значений, и вывод godbolt. Я хоть и негативно отношусь к С++ в целом, но вот этот наезд — вообще мимо.
Здравствуйте, so5team, Вы писали:
S>Может у вас IQ 180, докторская степень по физике и куча открытий в квантовой механики. Может в каких-то областях вам вообще нет равных. S>Но вот то, что и как вы пишете о программировании вообще (и о программировании на C++ в частности), наводит на мысль, что программированием на C++ вам лучше не заниматься. А то получится как вот здесь
C++ просто объективно сложнее среднестатистического ЯП. Примерно в 3 раза:
+ добавляются указатели и управление памятью — это еще столько же времени, сколько полноценный ЯП
+ добавляются шаблоны и метапрограммирование — это еще один новый язык.
Тут не в том дело что мозги не подходят. Если у вас n лет опыта разработки, то второй язык освоите где-то за 3 месяца плотной работы. С++ потребует 9 месяцев плотной работы. У меня где-то месяца 3 набралось, т.к. работаю не плотно.
S>>На C++ можно написать сразу под 6 платформ:
S>Боюсь вас разочаровать, но изрядная часть софта на C++ разрабатывается всего под одну платформу. А какая-то часть и вообще под конкретную версию конкретной программно-аппаратной платформы.
Однако если вам потребуется кросс-платформа — то альтернатив фактически просто нет в нашем мире
Ну разве что голый C, но хрен редьки не слаще. На нем то тоже пишут в ООП-стиле, только велосипедят. А это еще хуже.
S>>Ведь дело не только в языке S>Дело не в языке, дело в мозгах. Ну что поделать, если под C++ мозги не у всех заточены.
Затачивать нужно где-то месяцев 9 после обычного ЯП.
Много лет делают и никто не может честно признать — ничего не получается. Как друзья вы не садитесь — слишком большой размер бинаря и мало пригодно для реального использования
Я понимаю что как бы влюбились в язык и все такое — но правда есть правда — не выдержало проверку практикой.
Медленно, просто нервирует. Понятно что разработчику как бы кажется что все-равно круто, ведь там столько всего под капотом, что можно и потерпеть 5-7 секунд. Но нет, пользователю это медленно.
Здравствуйте, Muxa, Вы писали:
M>Ты программист или где? M>Такой код тоже можно отлаживать в дебагере. Собираешь себе компилятор с дебажными символами и запускаешь компиляцию своего кода с компайл-тайм вычислениями под дебагером.
M>
S>>Это сейчас ты ждешь 5-7 секунд. Через год уже нет.
ЕМ>Странно, но я помню времена, когда большинство сайтов грузилось гораздо быстрее даже через соединение в сотни кбит/с. Чем дальше, тем больше сайтов грузится раздражающе долго. А еще многие сайты сделаны так, что визуальные элементы перемещаются в процессе загрузки. Только нацелился кликнуть кнопку или ссылку — бац, она уехала в сторону, или вообще за пределы экрана. Раньше за такое бы сразу загнобили, а теперь привыкли.
Это из-за того, что функциональность растет. Нельзя же всякие ангулары, реакты придумывают.
Раньше статическая страница без всяких CSS и JS прекрасно работали.
S>>Развиваются как эффективность кода, так и обрезание лишнего функционала, сжатие и скорсть интернета.
ЕМ>Из всего перечисленного, в основном наблюдаю только последнее.
Ну если смотреть на блазор то он развивается реально. Другое дело, что вэб не развивается. Все тот же HTML, CSS и JS.
Нужен аналог .Net или Java с нормальным языком, визуальными компонентами. Причем большая часть подписанных сборок изначально хранится на компе. Используется песочница.
Но воз то и ныне там. Тот же wasm уже сколько по человечески сделать не могут.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, andrey.desman, Вы писали:
S>>А вы сможете? Как вы это поймете? Просто догадаться нужно? А если кода сотни строк времени компиляции?
AD>Попытка под runtime if затащить compile-time static_assert declaration. AD>Слишком много квалии для простого девелопера...
После запуска — стало очевидно. Однако никаких предупреждений я не получил при сборке. GPT тоже посчитал что if может быть выполнен на этапе компиляци:
При компиляции программы, включая прекомпиляцию (если используется), компилятор обрабатывает условные конструкции, в том числе if-условия. Однако, в данном случае, условие if (a < b) является константным выражением, которое можно вычислить во время компиляции.
Компилятор может проводить оптимизации на этапе прекомпиляции и поэтому в данном случае он может упростить и удалить условную конструкцию, так как она всегда имеет ложное условие.
В результате, компилятор будет обрабатывать только оставшуюся часть программы, которая не зависит от условия if (a < b). Таким образом, статическое утверждение static_assert не будет учтено компилятором, и программа скомпилируется успешно.
Однако, важно отметить, что различные компиляторы могут иметь разные уровни оптимизации и могут вести себя по-разному в подобных ситуациях. В общем случае, использование условий внутри статических утверждений может привести к непредсказуемому поведению и ошибкам компиляции.
Здравствуйте, Разраб, Вы писали:
S>>Вопрос в том как все это отлаживать? Р>Переходите на zig:
В языке главное — кодовая база. Когда кода много — его нужно кому-то поддерживать. Машина пока не умеет. Перевести код с одного языка на другой — тоже не умеет, тем более такой причудливый язык как ++.
Кодовая база — это ваш хлеб.
Какая кодовая база у zig? Много ли библиотек на нем написано?
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Разраб, Вы писали:
S>>>Вопрос в том как все это отлаживать? Р>>Переходите на zig:
S>В языке главное — кодовая база. Когда кода много — его нужно кому-то поддерживать. Машина пока не умеет. Перевести код с одного языка на другой — тоже не умеет, тем более такой причудливый язык как ++.
S>Кодовая база — это ваш хлеб.
S>Какая кодовая база у zig? Много ли библиотек на нем написано?
Система сборки зига умеет компилить и си и кресты. сам зиг еще в стадии разработки. совместимость тоже есть. кросс компиляция из коробки.
вообщем по ссылке перевод фичей(там внизу страницы ссылки на переводы).
Здравствуйте, Разраб, Вы писали:
Р>Система сборки зига умеет компилить и си и кресты. сам зиг еще в стадии разработки. совместимость тоже есть. кросс компиляция из коробки. Р>вообщем по ссылке перевод фичей(там внизу страницы ссылки на переводы).
Основная работа все-равно будет — исправить баг в той или иной С++ -библиотеке, добавить некую новую функциональность. Нужно в первую очередь знать тот язык, на котором основная кодовая база.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Разраб, Вы писали:
Р>>Система сборки зига умеет компилить и си и кресты. сам зиг еще в стадии разработки. совместимость тоже есть. кросс компиляция из коробки. Р>>вообщем по ссылке перевод фичей(там внизу страницы ссылки на переводы).
S>Основная работа все-равно будет — исправить баг в той или иной С++ -библиотеке, добавить некую новую функциональность. Нужно в первую очередь знать тот язык, на котором основная кодовая база.
Я не в курсе, но разве ГПТ не может автоматом имея спецификацию двух ЯП сконвертировать код?
И фактически один и тот же код будет работать. В том числе есть и GUI-приложения — есть кодовая база и библиотеки для этого.
Вот взять тот же .Net — в теории вроде можно для WebAssembly. Но почему-то размер бинаря в пол гигабайта, ну ладно в 200 Мб. — кажется великоватым.
Вот тот же Rust вроде хорош — а где кодовая база? Много ли на нем написали уже? Где гарантия что он будет востребован, а не уйдет в небытие, будучи заменен на Mojo или там zig.
Ведь дело не только в языке — важен объем кодовой базы.
Здравствуйте, Shmj, Вы писали:
S>Но, простите, как это отлаживать?
а что тут отлаживать? Оно же не компилиируется. Не компилируется из-за связки if + static_assert. Замените if на if constexpr
Если же ошибка в логике, тогда сложнее. В основном я отлаживаюсь выводами в cout и static_assert. Причём последний чтобы только удостовериться, что код может быть выполнен в compile time
Здравствуйте, cppguard, Вы писали:
C>Есть тысячи вариантов, когда это невозможно, и ничего — как-то живут люди. Несколько примеров:
C>1. Что-то очень сильно аппаратное. C>2. Код, который зависит от времени так, что любой останов в отладчике ломает алгоритм. C>3. Распределённые системы. C>4. Just-in-time компиляция. C>5. Кодогенерация.
Вспомнилось, как я когда-то ловил ошибку: проблема была в кривой синхронизации между потоками. Так вот и в отладчике не поймаешь, и, что самое подлое, любая отладочная печать вносила синхронизацию и ошибка переставала воспроизводиться. Это было в 2006 году, давненько уже, но в память врезалось хорошо.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, Shmj, Вы писали:
S>>Да и вообще код на C++ не пишите. Серьезно.
S>А на чем писать то?
скажу не совсем популярную вещь, но есть такой язык как Delphi (Pascal).
Он до сих пор живее всех живых и прямо из коробки умеет компилить код для
1. Windows
2. MacOS
3. Linux
4. iOS
5. Android
Здравствуйте, Вертер, Вы писали:
В>скажу не совсем популярную вещь, но есть такой язык как Delphi (Pascal). В>Он до сих пор живее всех живых и прямо из коробки умеет компилить код для В>1. Windows В>2. MacOS В>3. Linux В>4. iOS В>5. Android
В>На счёт этого не уверен: В>6. WebAssembly.
Во-первых, намного намного меньше кодовая база. Во-вторых, особо ничем не лучше. Кроме того можно сказать язык проприетарный, поддерживает одна контора, которая может загнуться.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>>У блазора есть аж три варианта. Интерпретатор MSIL, AOT и гибрид интерпретатора и AOT S>>https://learn.microsoft.com/ru-ru/aspnet/core/blazor/host-and-deploy/webassembly?view=aspnetcore-7.0
S>>Ну и Настройка средства обрезки для ASP.NET Core Blazor
S>Много лет делают и никто не может честно признать — ничего не получается. Как друзья вы не садитесь — слишком большой размер бинаря и мало пригодно для реального использования
S>Я понимаю что как бы влюбились в язык и все такое — но правда есть правда — не выдержало проверку практикой.
Какой практикой? илазору вэбассембли пару лет. И там интерпретатор изначачально. Там размер мизерый. Посмотри на мсиловские сборки.
AOT да жрет, но если не использовать рефлекшин или оставлять рефлекшн только тот что используется, там прекрасно режется. И АОТ всего 1 год.
Собираются делать гибрид АОТ и интерпретатора.
S>Во-первых, намного намного меньше кодовая база. Во-вторых, особо ничем не лучше. Кроме того можно сказать язык проприетарный, поддерживает одна контора, которая может загнуться.
да не, кодовая база не такая уж и маленькая. При этом никто не запрещает использовать сторонние библиотеки (dll).
Есть ещё FreePascal и Lazarus.
Здравствуйте, Serginio1, Вы писали:
S>Ну файлы Blazor WebAssembly передаются клиенту в сжатом виде.Сжатие раза в 4. S>То есть не 200 а всего 40 с обрезанием и сжатием. Вполне себе приемлемо
Дайте пример работающего сайта. Все что я открывал — это боль
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>>Ну файлы Blazor WebAssembly передаются клиенту в сжатом виде.Сжатие раза в 4. S>>То есть не 200 а всего 40 с обрезанием и сжатием. Вполне себе приемлемо
S>Дайте пример работающего сайта. Все что я открывал — это боль
Надо свои сайты делать и на них тренироваться
Кстати в .Net 8 говорят и размер подправили и запуск https://www.infoq.com/news/2023/04/asp-net-core-net-8/
Публикация приложения в качестве встроенного AOT улучшает время запуска и размер приложения. В ходе эксперимента время запуска сократилось на 80%, а размер приложения — на 87%.
), что сама идея и макросов, и шаблонов сама по себе не предполагает непременно функционального принципа обработки. Она может быть и процедурно-функциональной, и даже чисто процедурной, где проблем с пониманием логики работы и отладкой почти не возникает, а объем и сложность кода, генерируемого на этапе компиляции, могут быть гораздо выше (те же разнообразные таблицы).
vsb>Тот же static assert идеален там, где и без него вылезет ошибка.
Это как? Вот есть, например, enum с набором констант, и есть таблицы, которые этими константами индексируются. Если не ставить возле каждой таблицы конструкцию вроде static_assert (LengthOfArray (Table) == Enum::Total), то где именно "вылезет ошибка"?
vsb>Если хочется делать что-то сложное до компиляции, то надо генерировать исходный код. Т.е. написать отдельную программу, которая будет генерировать код.
Именно это и делается в C++, только для написания "отдельной программы" предлагается настолько жуткий встроенный язык, что часто действительно оказывается проще использовать другой.
vsb>То, что что-то можно сделать, не означает, что это нужно делать.
Здравствуйте, Shmj, Вы писали:
S>Медленно, просто нервирует. Понятно что разработчику как бы кажется что все-равно круто, ведь там столько всего под капотом, что можно и потерпеть 5-7 секунд. Но нет, пользователю это медленно.
Угу посмотри сколько приложение нормальное запускается. Намного больше 5-7 секунд. Кстати на тех же мобилках вэб приложения практически отсутствуют. Все нативно.
Причем все кэшируется. И следующий запрос уже работает значительно быстрее.
На самом деле когда прикрутят GC к WebAssembly да еще и построение DOM то все может выглядеть и по другому. Просто все течет и эволюционирует. А вот писать на С++ для всего ...
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>Медленно, просто нервирует. Понятно что разработчику как бы кажется что все-равно круто, ведь там столько всего под капотом, что можно и потерпеть 5-7 секунд. Но нет, пользователю это медленно. S> Угу посмотри сколько приложение нормальное запускается. Намного больше 5-7 секунд. Кстати на тех же мобилках вэб приложения практически отсутствуют. Все нативно. S> Причем все кэшируется. И следующий запрос уже работает значительно быстрее.
Пользователи будут голосовать ногами.
S> На самом деле когда прикрутят GC к WebAssembly да еще и построение DOM то все может выглядеть и по другому. Просто все течет и эволюционирует. А вот писать на С++ для всего ...
Здравствуйте, Serginio1, Вы писали:
S> посмотри сколько приложение нормальное запускается. Намного больше 5-7 секунд.
В нормальном приложении тупо нечему запускаться дольше долей секунды, максимум — одной-двух секунд. Если приложению нужно больше — оно просто кривое.
S> Причем все кэшируется. И следующий запрос уже работает значительно быстрее.
Да, это признание того, что большинство разработчиков не в состоянии делать правильные приложения, и надо хоть как-то исправлять ситуацию с кривыми.
S>> посмотри сколько приложение нормальное запускается. Намного больше 5-7 секунд.
ЕМ>В нормальном приложении тупо нечему запускаться дольше долей секунды, максимум — одной-двух секунд. Если приложению нужно больше — оно просто кривое.
Угу. Посмотри например на 1С. S>> Причем все кэшируется. И следующий запрос уже работает значительно быстрее.
ЕМ>Да, это признание того, что большинство разработчиков не в состоянии делать правильные приложения, и надо хоть как-то исправлять ситуацию с кривыми.
Ну вот на мобильных устройствах практически нет вэб приложений. Значит они все кривые?
Да страницу легче загрузить, но нужно её отпарсить, вычислить все css и наконец отрендерить. Посмотри сколько страница занимает места.
По моему это тоже криво. Нежели загрузить уже готовый код. Опять же если мы говорим о 5g то 5-7 секунд превращаются в доли секунды.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Shmj, Вы писали:
S>>>Медленно, просто нервирует. Понятно что разработчику как бы кажется что все-равно круто, ведь там столько всего под капотом, что можно и потерпеть 5-7 секунд. Но нет, пользователю это медленно. S>> Угу посмотри сколько приложение нормальное запускается. Намного больше 5-7 секунд. Кстати на тех же мобилках вэб приложения практически отсутствуют. Все нативно. S>> Причем все кэшируется. И следующий запрос уже работает значительно быстрее.
S>Пользователи будут голосовать ногами.
Если контент пользователю интересен, то он может ждать сколько угодно, главное потом все быстро и надежно. S>> На самом деле когда прикрутят GC к WebAssembly да еще и построение DOM то все может выглядеть и по другому. Просто все течет и эволюционирует. А вот писать на С++ для всего ...
S>C++ тоже постепенно изменяется.
Угу. Пока макросы, шаблоны с перегрузкой операторов и прочая генерацией кода не исчезнут он останется тем же языком.
А вот управляемые языки для АОТ кстати используют генерацию C++ и компиляторы С++. Скорее всего в таком качестве он более интересен.
и солнце б утром не вставало, когда бы не было меня
S>Но, простите, как это отлаживать? Если обычный С++ можно в дебагере пройтись по шагам и все станет ясно — то тут мы просто имеем ошибку без всякой возможности понять причину ее возникновения (окромя как догадаться).
Ты программист или где?
Такой код тоже можно отлаживать в дебагере. Собираешь себе компилятор с дебажными символами и запускаешь компиляцию своего кода с компайл-тайм вычислениями под дебагером.
Здравствуйте, Ip Man, Вы писали:
IM>Если не нравится метапрограммирование — пишите на Java, там дженерики стирают тип
И это правильно, на С++ можно писать только от большой нужды. Один из худших языков в индустрии. Я бы даже сказал, С++ это одна из самых больших проблем IT.
Здравствуйте, Serginio1, Вы писали:
S>Посмотри например на 1С.
Зачем мне на него смотреть? Это все из серии "адвокат лжет, если у него открыт рот". Если тот 1С запускается дольше пары секунд — значит, он кривой, без вариантов. И это никак не связано с его способностью выполнять свою основную работу. Многие кривые изделия успешно справляются со своими задачами, не переставая быть кривыми.
S>Ну вот на мобильных устройствах практически нет вэб приложений. Значит они все кривые?
Не понял, какая связь тормознутости с типом приложения. Приложение любого типа можно сделать прямым и достаточно быстрым, а можно — кривым и медленным.
S>Да страницу легче загрузить, но нужно её отпарсить, вычислить все css и наконец отрендерить.
Потребные для этого ресурсы очень сильно зависят от того, как страница построена. Можно построить очень по-разному.
S>Посмотри сколько страница занимает места.
В тексте, или в том виде, в который ее превращает браузер?
S>По моему это тоже криво. Нежели загрузить уже готовый код.
Так ведь и готовый код умудряются делать так, что он грузится до минуты. Причем общий вид морды показывает довольно быстро, но остальное время до окончания загрузки на нее можно только смотреть, делать ничего нельзя.
S>Опять же если мы говорим о 5g то 5-7 секунд превращаются в доли секунды.
Ну дык, коню понятно, что почти все это тестируется и отлаживается сугубо на топовом железе с SSD, гигабитными локалками и оптикой в интернет. Ведь разработчик не будет себя уважать, ежели прогнется под юзеров с другой конфигурацией.
Здравствуйте, vsb, Вы писали:
vsb> Я бы даже сказал, С++ это одна из самых больших проблем IT.
Да ну ладно. Сейчас C++ это нишевый и непопулярный язык, с ограниченным числом вакансий и всё меньшим числом нормальных разработчиков.
Не знаю, как он может влиять на всё IT. Те, кому не нравится, просто не работают с ним — благо, полно других языков.
Касательно хейтеров C++ — хз, я знал отличных инженеров, которые ненавидели C++ и таких же отличных инженеров-фанатов языка. Наверное, нет правильного ответа на вопрос "хороший ли язык C++".
Здравствуйте, Ip Man, Вы писали:
vsb>> Я бы даже сказал, С++ это одна из самых больших проблем IT.
IM>Да ну ладно. Сейчас C++ это нишевый и непопулярный язык, с ограниченным числом вакансий и всё меньшим числом нормальных разработчиков.
Умирать он не собирается, появляются всё новые проекты на нём. Да и те, что написали. Это всё куча багов, куча уязвимостей. В каждой ОС всё от начала до конца на C/C++ за очень редким исключением. Я жму на клавиатуре кнопку, она по по блютузу улетает в макбук, по всему стеку доходит до хрома, потом уходит в видеокарту и на всём этом пути работают миллионы строк С/С++. И это не изменится ни через 10 лет, ни через 50.
Если бы IT пошло по пути безопасных языков, с комплайл и рантайм проверками в 80-х, если бы C был примерно таким же явлением, как сейчас ассемблер, если бы процессоры проектировали для того, чтобы все эти проверки работали достаточно быстро, огромного числа багов можно было бы избежать. И в прошлом и в будущем.
IM>Не знаю, как он может влиять на всё IT. Те, кому не нравится, просто не работают с ним — благо, полно других языков.
А как я могу с ним не работать, если мне надо работать с интерфейсами ОС, которые написаны на C. Это предлагать не работать с JS, работая с браузером. Но если JS не фатально плох и все его проблемы в целом уже исправили, а те, что исправить невозможно — можно запомнить, то с C++ так не получится.
Я не в абстрактном мире живу. Вот сейчас мне надо кучку кода запускать одновременно в Go, в браузере, в Java, в node.js. На C это и буду делать, ибо оно вкомпилируется бесшовно во всё это, с минимальными усилиями и с поддержкой тулзов. Ни на чём другом это не разумно делать. Но не потому, что C хороший, а потому, что эти тулзы писали последние 30 лет. И первое, с чем делает интеграцию любой ЯП, это с C.
IM>Касательно хейтеров C++ — хз, я знал отличных инженеров, которые ненавидели C++ и таких же отличных инженеров-фанатов языка. Наверное, нет правильного ответа на вопрос "хороший ли язык C++".
Я думаю, что те, кто специализируются на C++, без хлеба с икрой до старости не останутся.
Здравствуйте, Serginio1, Вы писали:
S> Если контент пользователю интересен, то он может ждать сколько угодно, главное потом все быстро и надежно.
Т.е. вы как бы издеваетесь над пользователем — тебе нужно ты и жди.
А что если кто-то другой предоставит то что ему нужно, но ждать не потребуется? И вы НИЧЕГО сделать не сможете — ваш бизнес, даже если это многомиллиардная корпорация — придется закрывать. Или переписать на другом языке, где ждать не нужно.
Тут фишка в том что НИЧЕГО не поможет — просто нет способа сделать нормально за любые деньги.
Если на C++ будет стоить дороже сама разработка — то на C# за миллиарды денег — ничего нельзя изменить в принципе.
Здравствуйте, vsb, Вы писали:
vsb>И это правильно, на С++ можно писать только от большой нужды. Один из худших языков в индустрии. Я бы даже сказал, С++ это одна из самых больших проблем IT.
А как же JS?
Тут дело вот в чем — сама наша реальность кривая, она нам не нравится. Чем лучше язык отражает свойства этой реальности — тем он больше вызывает раздражения, но тем проще и лучше на нем получается решать реальные проблемы — тем более популярным он становится.
S>>Посмотри например на 1С.
ЕМ>Зачем мне на него смотреть? Это все из серии "адвокат лжет, если у него открыт рот". Если тот 1С запускается дольше пары секунд — значит, он кривой, без вариантов. И это никак не связано с его способностью выполнять свою основную работу. Многие кривые изделия успешно справляются со своими задачами, не переставая быть кривыми.
Ну значит пусть будут кривыми, но справляться со своими обязанностями. Конкуренция. Были бы плохими то их вытеснили прямые приложения.
S>>Ну вот на мобильных устройствах практически нет вэб приложений. Значит они все кривые?
ЕМ>Не понял, какая связь тормознутости с типом приложения. Приложение любого типа можно сделать прямым и достаточно быстрым, а можно — кривым и медленным.
Ну как бы парсинг HTML,CSS, JS это ну никак от тпа приложения не зависит?
S>>Да страницу легче загрузить, но нужно её отпарсить, вычислить все css и наконец отрендерить.
ЕМ>Потребные для этого ресурсы очень сильно зависят от того, как страница построена. Можно построить очень по-разному.
Угу сам браузер жрет ресурсы. Но вот факт, что на мобильных устройствах практически не используют вэб приложения. S>>Посмотри сколько страница занимает места.
ЕМ>В тексте, или в том виде, в который ее превращает браузер?
Конечно в который превращает браузер.
S>>По моему это тоже криво. Нежели загрузить уже готовый код.
ЕМ>Так ведь и готовый код умудряются делать так, что он грузится до минуты. Причем общий вид морды показывает довольно быстро, но остальное время до окончания загрузки на нее можно только смотреть, делать ничего нельзя.
Ну все течет все меняется. Скоро уже браузеров в том виде, что сейчас не будет. Все будет выполняться в облаке, а клиенту будут передаваться экраны.
S>>Опять же если мы говорим о 5g то 5-7 секунд превращаются в доли секунды.
ЕМ>Ну дык, коню понятно, что почти все это тестируется и отлаживается сугубо на топовом железе с SSD, гигабитными локалками и оптикой в интернет. Ведь разработчик не будет себя уважать, ежели прогнется под юзеров с другой конфигурацией.
Ты упустил 5g. Все течет и все меняется. Я помню когда принять 100 кб на модемах без докачки было проблемой . Помню пол дня ждали.
и солнце б утром не вставало, когда бы не было меня
S>> Если контент пользователю интересен, то он может ждать сколько угодно, главное потом все быстро и надежно.
S>Т.е. вы как бы издеваетесь над пользователем — тебе нужно ты и жди.
S>А что если кто-то другой предоставит то что ему нужно, но ждать не потребуется? И вы НИЧЕГО сделать не сможете — ваш бизнес, даже если это многомиллиардная корпорация — придется закрывать. Или переписать на другом языке, где ждать не нужно.
Ну это же основа эволюции. Но тут вопрос что важнее подождать 5-7 секунд или контент?
На том же блазоре проще создавать приложения. Одна кодовая база для сервера и клиента итд.
S>Тут фишка в том что НИЧЕГО не поможет — просто нет способа сделать нормально за любые деньги.
S>Если на C++ будет стоить дороже сама разработка — то на C# за миллиарды денег — ничего нельзя изменить в принципе.
Не понял? Смотрим на популярность С++ и C#. Понятно, что стоимость разработки на C# значительно дешевле.
Это и интеллисенс, отладка, мощность и выразительность языка. https://survey.stackoverflow.co/2023/#most-popular-technologies-language-prof
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Ну это же основа эволюции. Но тут вопрос что важнее подождать 5-7 секунд или контент? S> На том же блазоре проще создавать приложения. Одна кодовая база для сервера и клиента итд.
А что если ваш конкурент даст и контент и не нужно ждать 5-7 сек?
И вот приходит ваш начальник и говорит — ребят, мы получили 15 млн. долларов инвестиций. Теперь нужно сделать так, чтобы сайт загружался за 0.2 сек.
Ваши действия?
S>>Если на C++ будет стоить дороже сама разработка — то на C# за миллиарды денег — ничего нельзя изменить в принципе. S> Не понял? Смотрим на популярность С++ и C#. Понятно, что стоимость разработки на C# значительно дешевле.
Только см. пример выше. Можно сделать дешево, но будут неустранимые принципиально тормоза.
Тут https://www.tiobe.com/tiobe-index/ С++ — опережает. Но дело даже не в этом. Интеллисенс и отладка есть и в С++. Мощности хоть отбавляй.
Тут дело в другом — часто на C# даже за +10000% надбавку денег к проекту — ну не получится реализовать то, что можно на С++. К примеру, те же 5-7 сек. загрузки убрать.
S>> Ну это же основа эволюции. Но тут вопрос что важнее подождать 5-7 секунд или контент? S>> На том же блазоре проще создавать приложения. Одна кодовая база для сервера и клиента итд.
S>А что если ваш конкурент даст и контент и не нужно ждать 5-7 сек?
Если бы да бы. Нужна прежде всего скорость разработки и функционал. Это сейчас ты ждешь 5-7 секунд. Через год уже нет.
Развиваются как эффективность кода, так и обрезание лишнего функционала, сжатие и скорсть интернета.
S>И вот приходит ваш начальник и говорит — ребят, мы получили 15 млн. долларов инвестиций. Теперь нужно сделать так, чтобы сайт загружался за 0.2 сек.
S>Ваши действия?
Еще раз есть кэширование. Да в первый раз может дольше. Но на установку приложения ты тоже время тратишь. Зато потом все летает. Здесь тоже самое.
Если сайт никакой, то делать его можно на чем угодно, если же функционал сложный то выбираются инструменты для быстрого кодирования.
S>>>Если на C++ будет стоить дороже сама разработка — то на C# за миллиарды денег — ничего нельзя изменить в принципе. S>> Не понял? Смотрим на популярность С++ и C#. Понятно, что стоимость разработки на C# значительно дешевле.
S>Только см. пример выше. Можно сделать дешево, но будут неустранимые принципиально тормоза.
Вот для тебя это неустранимые тормоза, а для 80% вполне нормально S>На C++ сделаете на 50% дороже, скажем. Однако тормозов не будет. Попытаетесь сделать подобное на C# — окажется что даже за +1000% это не возможно в принципе.
Ну вот практика показывает, хотя на C++ быстрее в основном кодируют на Java и C#
S>>Это и интеллисенс, отладка, мощность и выразительность языка. S>>https://survey.stackoverflow.co/2023/#most-popular-technologies-language-prof
S>Тут https://www.tiobe.com/tiobe-index/ С++ — опережает. Но дело даже не в этом. Интеллисенс и отладка есть и в С++. Мощности хоть отбавляй.
Ну тиобе то извесный своей достоверностью сайт. JS аж на 7 месте! И Бэйсик опережает JS! А TS на 44 месте! S>Тут дело в другом — часто на C# даже за +10000% надбавку денег к проекту — ну не получится реализовать то, что можно на С++. К примеру, те же 5-7 сек. загрузки убрать.
Да ну? Еще раз я тебе показал пример урезания и сжатия. Второе можно показать некий функционал загружая минимальный контент для показа. Который может быть на любом языке и технологиях. Все остальное в фоне.
Пока ты сморишь на начальную страницу нужный код уже погрузится.
Вариантов куча.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vsb, Вы писали:
vsb>Это всё куча багов, куча уязвимостей.
Уязвимости не потому, что на C++, а потому, что с использованием его небезопасных возможностей. Если нужна безопасность, всегда можно выбрать подмножество, одновременно достаточно мощное и безопасное. Но за этим кто-то должен следить.
vsb>Я жму на клавиатуре кнопку, она по по блютузу улетает в макбук, по всему стеку доходит до хрома, потом уходит в видеокарту и на всём этом пути работают миллионы строк С/С++.
Да ладно, на таком пути и десятков тысяч-то не наберется.
vsb>И это не изменится ни через 10 лет, ни через 50.
А надо?
vsb>Если бы IT пошло по пути безопасных языков, с комплайл и рантайм проверками в 80-х
Так нет же никаких проблем встроить все это в C/C++, кроме нежелания и лени. Кое-что встраивают, но как-то очень несерьезно.
Здравствуйте, Serginio1, Вы писали:
S> Ну как бы парсинг HTML,CSS, JS это ну никак от тпа приложения не зависит?
Мы разве исключительно про веб-приложения? Вроде как изначально не было оговорено, что речь только о них. Но даже и веб-приложение можно сделать сильно по-разному, и ресурсов для парсинга/рендеринга будет требоваться от умеренного количества до невменяемого.
S> на мобильных устройствах практически не используют вэб приложения.
Не потому ли, что там [пока] нет такого количества халявных ядер, гигагерц и гигабайт?
S>>>Посмотри сколько страница занимает места. ЕМ>>В тексте, или в том виде, в который ее превращает браузер? S>Конечно в который превращает браузер.
А она непременно должна занимать именно столько? Если на том же C/C++ целочисленную последовательность {123, 510, 278, 304} записать как {L"one hundred twenty-three" , L"five hundred ten", L"two hunred seventy-eight", L"three hundred four"} — можно будет утверждать, что она представлена в оптимальном виде?
S> Ну все течет все меняется. Скоро уже браузеров в том виде, что сейчас не будет. Все будет выполняться в облаке, а клиенту будут передаваться экраны.
И что это изменит? Всего-то будет тормозить и на обработке, и на передаче.
S> Ты упустил 5g.
Во-первых, 5G — система массового обслуживания, которая приемлемо работает лишь до определенного уровня загрузки, а затем очень быстро валится практически в неработоспособное состояние. Во-вторых, как известно, IT развивается в сторону способности занять все доступные ресурсы, и конца этому не видно.
Здравствуйте, Serginio1, Вы писали:
S>Это сейчас ты ждешь 5-7 секунд. Через год уже нет.
Странно, но я помню времена, когда большинство сайтов грузилось гораздо быстрее даже через соединение в сотни кбит/с. Чем дальше, тем больше сайтов грузится раздражающе долго. А еще многие сайты сделаны так, что визуальные элементы перемещаются в процессе загрузки. Только нацелился кликнуть кнопку или ссылку — бац, она уехала в сторону, или вообще за пределы экрана. Раньше за такое бы сразу загнобили, а теперь привыкли.
S>Развиваются как эффективность кода, так и обрезание лишнего функционала, сжатие и скорсть интернета.
Из всего перечисленного, в основном наблюдаю только последнее.
S>> Ну все течет все меняется. Скоро уже браузеров в том виде, что сейчас не будет. Все будет выполняться в облаке, а клиенту будут передаваться экраны.
ЕМ>И что это изменит? Всего-то будет тормозить и на обработке, и на передаче.
S>> Ты упустил 5g.
ЕМ>Во-первых, 5G — система массового обслуживания, которая приемлемо работает лишь до определенного уровня загрузки, а затем очень быстро валится практически в неработоспособное состояние. Во-вторых, как известно, IT развивается в сторону способности занять все доступные ресурсы, и конца этому не видно.
Ну вот облако будет в каждом доме в подвале. Оно и будет обработкой видео заниматься и прочим заниматься. А гигабита уже достаточно, что бы и 4К смотреть.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, so5team, Вы писали:
vsb>>На C это и буду делать, ибо оно вкомпилируется бесшовно во всё это, с минимальными усилиями и с поддержкой тулзов. Ни на чём другом это не разумно делать.
S>Не сомневаюсь в том, что на C++ это все можно было бы сделать и быстрее, и проще, и надежнее.
А я уверен, что всё с точностью до наоборот.
S>Но с такой ненавистью к C++ не получится, да.
У меня всё получается. Но хватает мудрости делать правильный выбор.
S>Поэтому лучше наговнякать еще несколько килотонн лапши на чистой Сишечке, чтобы это все потом текло и падало.
Выделений памяти в этом коде не будет, поэтому течь он не сможет. Падать он теоретически сможет, но ровно так же, как в С++, в котором какие-то утырки протащили undefined behaviour даже в STL, вместо того, чтобы понатыкать везде неотключаемых проверок. Поэтому идиоматичный C++ не даст ничего. Кроме кучи усилий по тому, чтобы сдерживать рост прикомпиливаемого рантайма, который неизбежно будет (а в C максимум, что прикомпилится, это какой-нибудь memcpy, который компилятор суёт куда ни попадя, но это мелочи). А изобретать свою библиотеку коллекций ради нескольких сотен строк числовых алгоритмов — неправильный выбор.
Здравствуйте, Евгений Музыченко, Вы писали:
S>> Ну вот облако будет в каждом доме в подвале.
ЕМ>Часть облака, или все целиком?
Ну конечно часть. В основном как кэш часто используемых приложений, сайтов. S>> А гигабита уже достаточно, что бы и 4К смотреть.
ЕМ>Не переживайте — придумают, чем забить и десяток гигабит.
Ну это точно. Но суть в том, что у телефонов теплоотдача плохая. Много процессоров то не засунешь.
Поэтому будут брать на себя тепловыделения облачные сервера.
Возможно все изменится с революционными открытиями.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vsb, Вы писали:
S>>Не сомневаюсь в том, что на C++ это все можно было бы сделать и быстрее, и проще, и надежнее.
vsb>А я уверен, что всё с точностью до наоборот.
При таких раскладах каждый остается при своем мнении.
S>>Но с такой ненавистью к C++ не получится, да.
vsb>У меня всё получается.
"У меня все работает" (с) Да.
vsb>Выделений памяти в этом коде не будет, поэтому течь он не сможет. vsb>А изобретать свою библиотеку коллекций ради нескольких сотен строк числовых алгоритмов — неправильный выбор.
А зачем вам своя библиотека коллекций, если у вас память выделяться не будет?
Здравствуйте, so5team, Вы писали:
S>А зачем вам своя библиотека коллекций, если у вас память выделяться не будет?
1. Поставить проверки в operator[]. Это единственная существенная польза от С++, которую я могу представить. На С заменять каждую индексацию функцией с проверкой это чересчур.
2. Добавить всякие умножения вектора на число, перемножения векторов, ну то, что уместно для тех алгоритмов. Тут не могу точно сказать, я их видел вскользь, ну что-то можно добавить. На С это будут обычные функции, наверное с операторами это будет чуть-чуть красивей. Хотя ручаться не буду.
3. Возможно исключения. Я их люблю, но сколько байтов они добавят в wasm-сборку, не представляю.
Т.е. даже на масштабе проблемы в 500 строк (условно) уже видны преимущества C++.
Хотя, если речь идет о проектах такого размера, то преимущества языков обсуждать вообще как-то странно.
