Здравствуйте, Shmj, Вы писали: S>Замечали ли вы, что на голом Си проекты получаются как бы более компактными и выразительными? Но нужно уметь писать, не пытаться в ООП и пр. извраты.
А разве .NET не уделывает сишный компилятор по оптимизациям?
В оптимизацию JVM тоже вбухано большое количество средств, в т.ч. профессура со скубентами.
Здравствуйте, 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 приходится макрить.
Не могу гарантировать, что у автора того кода именно эта проблема, но вероятность не ноль.
