Ох уж эти оптимизаторы писанины хреновы. Любители макросов обдолбанные
#define LOOP(i, j) for (int i = 0; i < j; i++)
Вот сложно да, каждый раз «for” писать??? Неее. Будет вводить свои слова, что читающий каждый раз вспоминал, что ты там за слова напридумывал.
Придурки
По стилистике это писал "бородатый физик в свитере с оленями". Хотя в своей области он может быть весьма ученым мужем, к разработке его лучше не допускать.
S>>Замечали ли вы, что на голом Си проекты получаются как бы более компактными и выразительными? Но нужно уметь писать, не пытаться в ООП и пр. извраты. BFE>Выразительными? BFE>Что, по вашему, выражает автор этого кода следующими строчками? BFE>
// argv[1] stores the name of the model we're loading
// tmp will map 124M -> 0, 355M -> 1, 775M -> 2, 1558M -> 3
// Note that if you change the name of the file then this will break.
У меня такое мировоззрение. Хотя я и Си не одобряю, но из доступного-популярного он ближе остальных к "идеалу". C и Go, в зависимости от уместности GC.
Здравствуйте, Shmj, Вы писали:
S>Замечали ли вы, что на голом Си проекты получаются как бы более компактными и выразительными? Но нужно уметь писать, не пытаться в ООП и пр. извраты.
Проблема в том, что код на Си выглядит просто и компактно, но в каждой строчки возможна проблема работы с памятью, и без многолетнего опыта объективно оценить качество кода практически невозможно.
Здравствуйте, Shmj, Вы писали:
S>Замечали ли вы, что на голом Си проекты получаются как бы более компактными и выразительными? Но нужно уметь писать, не пытаться в ООП и пр. извраты.
Ага, примерно как на Perl — написать один раз можно, а вот отлаживать или разбираться в таком коде не очень хочется.
Такие проекты начал писать чуть пораньше Андрей Карпаты: llm.c и llama2.c.
S>Замечали ли вы, что на голом Си проекты получаются как бы более компактными и выразительными? Но нужно уметь писать, не пытаться в ООП и пр. извраты.
И... бесполезны. Потому что на практике вылезает куча нюансов и разветвлений, которые не укладываются в первоначальную абстракцию и требуют расширения. А тут либо ООП, либо что-то ещё, чего в С особо и нет из коробки.
S>Встречали ли вы таких? Как относитесь?
Фабрис Беллар сразу всплывает в памяти, как яркий представитель и с чьим кодом в виде ffmpeg имел дело. Отношусь хорошо, для практического применения такого кода всегда приходится писать удобные обёртки. Но внутри он достаточно прост и читабелен, если им просто пользоваться, а не поддерживать.
Здравствуйте, Shmj, Вы писали: S>Замечали ли вы, что на голом Си проекты получаются как бы более компактными и выразительными? Но нужно уметь писать, не пытаться в ООП и пр. извраты.
А разве .NET не уделывает сишный компилятор по оптимизациям?
В оптимизацию JVM тоже вбухано большое количество средств, в т.ч. профессура со скубентами.
Здравствуйте, Нomunculus, Вы писали:
Н>Ох уж эти оптимизаторы писанины хреновы. Любители макросов обдолбанные
Н>Вот сложно да, каждый раз «for” писать???
C++ шаблонами и переопределением операторов вывел способность запутать на новый уровень. Собственно, шаблоны — это и есть типизированные макросы.
Замечали ли вы, что на голом Си проекты получаются как бы более компактными и выразительными? Но нужно уметь писать, не пытаться в ООП и пр. извраты.
Интересно же — существуют true-сишники, особый стиль жизни даже — которые гневно не одобряют всякие излишества в языках, приравнивая их к джинсам и жвачке времен СССР. При этом знают тонкости системы, железа на глубочайшем уровне и знают как сделать проще или вообще не делать. Наслышан о таких, но, к сожалению, познакомиться не довелось.
Здравствуйте, Anton Batenev, Вы писали:
AB>По стилистике это писал "бородатый физик в свитере с оленями". Хотя в своей области он может быть весьма ученым мужем, к разработке его лучше не допускать.
Но он может достаточно ясно выразить в коде идею. Пусть оно будет и не оптимально, без соблюдения Code Conventions и пр. Но будет работать и идея будет сохранена. Потом уже не так сложно привести к нормальному виду и оптимизировать.
Здравствуйте, Shmj, Вы писали:
S>Интересно же — существуют true-сишники, особый стиль жизни даже — которые гневно не одобряют всякие излишества в языках, приравнивая их к джинсам и жвачке времен СССР. При этом знают тонкости системы, железа на глубочайшем уровне и знают как сделать проще или вообще не делать.
Бородатые олдфаги, единственные, кто умеет писать ядра операционок, драйвера и системные службы, демонстративно отказываются учить что-то ещё. На самом деле, любой уважающий себя сишник знает не только С++, но и ещё с десяток других языков, главным образом для того, чтобы их обсирать. А на Си они любят писать потому, что код в таком случае получается короче и прямее.
AN>Бородатые олдфаги, единственные, кто умеет писать ядра операционок, драйвера и системные службы, демонстративно отказываются учить что-то ещё. На самом деле, любой уважающий себя сишник знает не только С++, но и ещё с десяток других языков, главным образом для того, чтобы их обсирать. А на Си они любят писать потому, что код в таком случае получается короче и прямее.
Да уж, Си прост, как калоша. Не то что эти ваши Swift'ы с какими-то guard'ами, reference cycle'ами и async'ами — пока разберешься, проще на сях свой компилятор написать.
Здравствуйте, Shmj, Вы писали:
S>Вот пример проекта: https://github.com/carlini/c-chat-gpt-2/blob/main/c_chat_gpt_2.chttps://habr.com/ru/articles/879662/
S>Замечали ли вы, что на голом Си проекты получаются как бы более компактными и выразительными?
Смотря какие проекты. Как я уже говорил — если у вас стоит задача сделать портабельную библиотеку для использования из разных языков, то C будет одним из наилучших вариантов выбора.
А вот, к примеру, какой-нибудь более-менее современный компилятор писать на C — это боль и страдания.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Компактными и выразительными по сравеннию с чем? Можешь показать тоже самое на другом языке, менее или более компактно и выразительно?
Мне кажется, что ты клонишь в сторону излишней многословности плюсов, особенно всяких "компайлтаимовых штучек (C)". Ну так те штучки пишутся в библиотечном, а не в прикладном коде. Здесь же код прикладной. И на плюсах мог бы выглядеть и компактнее и выразительнее.
Был бы, например, std::ifstream, вместо fopen/fclose. Всякие макро, типа LOOP, UNARY, BINARY были бы записаны какими-нибудь лямбдами. Хотя LOOP тут — это пппц .
S> Но нужно уметь писать, не пытаться в ООП и пр. извраты.
Н>Вот сложно да, каждый раз «for” писать??? Неее. Будет вводить свои слова, что читающий каждый раз вспоминал, что ты там за слова напридумывал. Н>Придурки
Это что, чатгопота подсказала? В любом случае всё упирается в это "как бы". Какой-то особой выразительности в приведённом коде я не вижу.
Лично я использовал Си в качестве высокоуровневого ассемблера. Сделать вставку в фортрановской программе или JNI.
не замечал. Обычно какие-то огромные портянки функций на десяток страниц, с глобальными переменными и непонятно где определенными константами и прочими макросами.
Пытался как-то разобраться в одном из аспектов драйвера NVidia под linux — не смог, чисто WriteOnly код повсюду
Здравствуйте, student__, Вы писали:
__>А разве .NET не уделывает сишный компилятор по оптимизациям? __>В оптимизацию JVM тоже вбухано большое количество средств, в т.ч. профессура со скубентами.
Уверен, что в JavaScript вбухано ещё больше. Сейчас активно вбухивают в Питон.
Здравствуйте, Anton Batenev, Вы писали:
AB>По стилистике это писал "бородатый физик в свитере с оленями". Хотя в своей области он может быть весьма ученым мужем, к разработке его лучше не допускать.
Если ты когда-нибудь видел стандарты про криптографию, там обычно приводятся в приложениях примеры кода. Как раз в стиле "с оленями". Этот код все же гораздо лучше
Здравствуйте, opfor, Вы писали:
O>Да уж, Си прост, как калоша. Не то что эти ваши Swift'ы с какими-то guard'ами, reference cycle'ами и async'ами — пока разберешься, проще на сях свой компилятор написать.
Коммитет по стандартизации упорно работает над тем, чтобы Си перестал быть простым, как калоша. И у них получается...
Здравствуйте, vsb, Вы писали:
vsb>У меня такое мировоззрение. Хотя я и Си не одобряю, но из доступного-популярного он ближе остальных к "идеалу". C и Go, в зависимости от уместности GC.
Go, однако, прекрасен тем, что прикидываясь языком высокого уровня, типа Питона, он взял, однако, из Си некоторые особенности, делающие жизнь интересной.
data := []byte("hello")
data = append(data, []byte(", world!")...)
hello := data
data = append(data, []byte(" Oo")...)
copy(data, []byte("12345"))
fmt.Printf("%s\n", hello)
Что в итоге напечатается, зависит от количества байтов, которые добавляются в 4-й строке.
Для сишника это очевидно, а как это понимают люди, не умеющие в Си, ума не приложу...
Ну и не будем забывать, что bytes.Buffer.Bytes() возвращает "указатель" (вернее, слайс) на внутренний буфер...
Здравствуйте, student__, Вы писали:
Pzz>>Для сишника это очевидно, а как это понимают люди, не умеющие в Си, ума не приложу...
__>Для сишника здесь вообще ничего не очевидно, потому что он не знает семантики операций со слайсами. Откуда вот это обожествление сишников?
Зато сишник совершенно свободно живет в мире, в котором разные указатели могут ссылаться на пересекающуюся память.
Здравствуйте, student__, Вы писали:
S>>Замечали ли вы, что на голом Си проекты получаются как бы более компактными и выразительными? Но нужно уметь писать, не пытаться в ООП и пр. извраты.
__>А разве .NET не уделывает сишный компилятор по оптимизациям?
Здравствуйте, Pzz, Вы писали:
Pzz>Коммитет по стандартизации упорно работает над тем, чтобы Си перестал быть простым, как калоша. И у них получается...
Здравствуйте, student__, Вы писали: __>Например, векторизация циклов с учётом самой мощной версии SIMD.
А разве в CLR уже завезли векторизацию циклов?
Когда я смотрел на это в последний раз, фича была низко в списке приоритетов.
Авто-векторизация — очень хрупкий процесс, даже в AOT компиляторах, у которых нет ограничений по бюджету на оптимизацию.
Если у вас есть задача, которая может выиграть от векторизации, то в CLR вы делаете векторизацию руками, и у вас есть некоторая гарантия, что код останется векторизованным, даже если что-то вокруг него изменится.
В частности, некоторые конкретные идиому (вроде поиска элемента в массиве или арифметики с типами Vector<T>) векторизованы на уровне C#-кода, что позволяет получить преимущества от SIMD даже тем разработчикам, которые не интересуются интринсиками.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pzz, Вы писали:
Pzz>В этой программе чуть больше, чем 300 строк. Когда размер растет, требуется немного побольше архитектуры. А то подохнешь.
Ну так в этой программе уже овердохрена архитектуры. В частности ФВП эмулируются макросами
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, student__, Вы писали:
__>А разве .NET не уделывает сишный компилятор по оптимизациям? __>В оптимизацию JVM тоже вбухано большое количество средств, в т.ч. профессура со скубентами.
Возьмите консольное приложение на C и на .Net. Запустите. Просто пустое консольное. Заметите тормоза при запуске невооруженным глазом.
Здравствуйте, Нomunculus, Вы писали:
Н>Ох уж эти оптимизаторы писанины хреновы. Любители макросов обдолбанные
Н>
Н>#define LOOP(i, j) for (int i = 0; i < j; i++)
Н>Вот сложно да, каждый раз «for” писать??? Неее. Будет вводить свои слова, что читающий каждый раз вспоминал, что ты там за слова напридумывал. Н>Придурки
Есть люди, которым сложно следить за тем, чтобы, например, в for (int i = 0; i < j; i++) все три раза упоминалась одна и та же переменная `i`, а не разные.
Для таких придумали foreach во всяких C#, for (var : range) в C++, ну а в C приходится макрить.
Не могу гарантировать, что у автора того кода именно эта проблема, но вероятность не ноль.
Здравствуйте, Нomunculus, Вы писали:
Н>Ну обозвал бы хоть FOR_LOOP. Потому что LOOP(i, j) вполне можем значить while(i<j)
Если это автор 2-3 программ в одном стиле и ничего больше, он о таком не думает. И это вполне естественно — каждый ограничен своим опытом, и пока не наступит на новую форму граблей, не задумывается, что она в принципе может где-то быть.
Здравствуйте, Shmj, Вы писали:
S>Возьмите консольное приложение на C и на .Net. Запустите. Просто пустое консольное. Заметите тормоза при запуске невооруженным глазом.
Запускаю .NET хелло ворлд в виртуалочке, никаких тормозов вообще. Ноль.
S>>Возьмите консольное приложение на C и на .Net. Запустите. Просто пустое консольное. Заметите тормоза при запуске невооруженным глазом. __>Запускаю .NET хелло ворлд в виртуалочке, никаких тормозов вообще. Ноль.
Ноль целых ноль десятых?
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Shmj, Вы писали:
S>Вот пример проекта: https://github.com/carlini/c-chat-gpt-2/blob/main/c_chat_gpt_2.chttps://habr.com/ru/articles/879662/
S>Замечали ли вы, что на голом Си проекты получаются как бы более компактными и выразительными? Но нужно уметь писать, не пытаться в ООП и пр. извраты.
S>Интересно же — существуют true-сишники, особый стиль жизни даже — которые гневно не одобряют всякие излишества в языках, приравнивая их к джинсам и жвачке времен СССР. При этом знают тонкости системы, железа на глубочайшем уровне и знают как сделать проще или вообще не делать. Наслышан о таких, но, к сожалению, познакомиться не довелось.
S>Встречали ли вы таких? Как относитесь?
Знаем веб-мессенджер целиком на C++ написанный, веб-часть частично на Си и скомпилена в WebAssembly.
Летает просто жесть.
Относимся к такому с ненавистью, потому что не можем сделать лучше на своих быдло-языках и люто завидуем. https://nanochat.ru/main
Здравствуйте, student__, Вы писали:
__>А зачем мне окно? Я предпочитаю консольку.
Попробуй двойным кликом запустить .Net консольное приложение в Windows а потом консольное приложение на .Net. Разница в скорости видна невооруженным глазом. И при увеличении приложения разница все более заметна.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, student__, Вы писали:
__>>А зачем мне окно? Я предпочитаю консольку.
S>Попробуй двойным кликом запустить .Net консольное приложение в Windows а потом консольное приложение на .Net. Разница в скорости видна невооруженным глазом. И при увеличении приложения разница все более заметна.
вранье. я видел 2 проекта, которые делали одно и тоже — эмуляция игровой консоли Nintendo Switch — Yuzu (C++) и Ryujinx (C#).
До того, как их нинтендо забанило, я их сравнивал, и по производительности C++ сосал
(дополню — и там и там была эмуляция ARM64 кода, в нативный x64 и MSIL соответственно)
Здравствуйте, ononim, Вы писали:
S>>>Замечали ли вы, что на голом Си проекты получаются как бы более компактными и выразительными? Но нужно уметь писать, не пытаться в ООП и пр. извраты. BFE>>Выразительными? BFE>>Что, по вашему, выражает автор этого кода следующими строчками? BFE>>
Здравствуйте, Нomunculus, Вы писали:
Н>Здравствуйте, Shmj, Вы писали:
Н>Ох уж эти оптимизаторы писанины хреновы. Любители макросов обдолбанные
Я тоже не понимаю что прямо хорошего в этом коде. Мое бы ревью он не прошел
Здравствуйте, Артём, Вы писали:
Аё>C++ шаблонами и переопределением операторов вывел способность запутать на новый уровень. Собственно, шаблоны — это и есть типизированные макросы.
Здравствуйте, Shmj, Вы писали:
S>Возьмите консольное приложение на C и на .Net. Запустите. Просто пустое консольное. Заметите тормоза при запуске невооруженным глазом.
А давай вооружонным!? Зачем "на глаз", если можно измерить время и даже посмотреть что именно происходит — на что уходит время.
Предоставишь проги?
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, student__, Вы писали:
__>>Запускаю .NET хелло ворлд в виртуалочке, никаких тормозов вообще. Ноль.
S>Теперь сравни с прогой на C. Даже не увидишь как окно закрылось.
$ time ./hello-sharp.exe
Hello
real 0m0.140s
user 0m0.015s
sys 0m0.062s
$ time ./hello-c.exe
Hello
real 0m0.116s
user 0m0.000s
sys 0m0.047s
Здравствуйте, amironov79, Вы писали:
a> S>Сорри, ранее были другие результаты. Сейчас, похоже ускорили.
a> В dotnet в последние годы многое сделано в плане производительности, и надо всё заново проверять
До Free Pascal все равно как до луны:
$ time ./project1
Hello
real 0m0,001s
user 0m0,001s
sys 0m0,000s
Здравствуйте, AleksandrN, Вы писали:
AN> На benchmark game сравнивают языки по времени работы одного и того-же алгоритма, реализованного на разных языках. Лидеры — C, C++, Rust.
If the fastest programs are flagged * possible hand-written vector instructions or "unsafe" or naked ffi, does the host language matter?
А на чём пилить UI, чтобы он открывался всех девайсах, осях, не выносил мозг установками, обновлениями, экзотическими версиями форточуи не говоря о маках и линухах?
Здравствуйте, Артём, Вы писали:
Аё>Здравствуйте, flаt, Вы писали:
F>>Говорит человек, который перешёл на JS, в котором typeof(null) == 'object' и прочие https://www.destroyallsoftware.com/talks/wat.
Аё>А на чём пилить UI, чтобы он открывался всех девайсах, осях, не выносил мозг установками, обновлениями, экзотическими версиями форточуи не говоря о маках и линухах?
Здравствуйте, rudzuk, Вы писали:
S>> QT предлагают QML, который по сути JS. R>QML — опция.
Так именно кросс-платформа, в т.ч. моб. даже в примерах — сделаны на новом Qt Quick, который QML. Старый Qt Widgets — уже морально устарел даже по внешнему виду.
Здравствуйте, Shmj, Вы писали:
S>>> QT предлагают QML, который по сути JS. R>>QML — опция. S>Так именно кросс-платформа, в т.ч. моб. даже в примерах — сделаны на новом Qt Quick, который QML. Старый Qt Widgets — уже морально устарел даже по внешнему виду.
Ну да, ты прав. Но это одновременно и минус, и плюс — на GUI можно натравить web-макак, которые сделают все по красоте, а начинку можно писать на православном c++
Здравствуйте, wl., Вы писали:
S>>Так именно кросс-платформа, в т.ч. моб. даже в примерах — сделаны на новом Qt Quick, который QML. Старый Qt Widgets — уже морально устарел даже по внешнему виду. wl.>Ну да, ты прав. Но это одновременно и минус, и плюс — на GUI можно натравить web-макак, которые сделают все по красоте, а начинку можно писать на православном c++