Еще года три назад я прям очень бесился, когда мои студенты путали "сдвиг" и "смещение", но сейчас я полностью принял дескриптивный взгляд на лингвистику и считаю, что бороться с такими явлениями невозможно.
Да, для меня странно слышать слово "битЫ", а не "бИты" (когда речь про bits, а не beats) или когда говорят "адрес НА первый элемент массива", вместо "адрес первого элемента", но я не вижу смысла с этим спорить :) Правильность в языке - дело привычки.
Но так же странно было людям 100 лет назад слышать как всех детей (а не только крестьянских) называют "ребята", а мне странной кажется фраза "не умаляя общности" из учебника по матанализу..
Язык меняется и, на мой взгляд, с этим ничего делать не нужно, только стрессовать зря.
(Ну а если конкретнее, придирки в статье мне кажутся уж совсем высосанными из пальца по большей части; разницы между "послать" и "отправить" я вообще не вижу.. что лишний раз демонстрирует субъективность восприятия таких вещей).
На мой взгляд, есть еще очень большая проблема вот какого плана: если гуглить по-английски любые вопросы по С и С++ - попадаешь на stackoverflow и cppreference, а если гуглить по-русски, то оказывается, что ресурсов-то особо и нет!
И в выдаче будет либо машинный перевод того же stackoverflow, либо какой-нибудь простите cyberforum, где точно такие же джуны обмениваются кодом даже не обернутым в теги.
Учебники вроде как есть, но их много и они большие, а вот на короткий простой вопрос ответ хрен найдешь.
И видеокурсов тоже как-то не густо русскоязычных.
Соответственно за эту дорожную карту вам большое спасибо :)
Миллионы несовместимых компиляторов С (и стандартных библиотек, не забывайте еще и про них) - это огромная проблема, причем это проблемы программистов, вы вспомните, сколько ифдефов нужно написать, просто чтобы обеспечить совместимость с gcc/clang/msvc!
Когда появился С - не было интернета, распространить единый компилятор было очень трудно, а книжку - относительно легко, вот все и писали эти компиляторы..
Но это же безумие просто, повторять раз за разом одну и ту же работу, писать сотни раз одну и ту же стандартную библиотеку, наступать на те же грабли - вместо того, чтобы завести один единственно-верный (опенсорсный, разумеется) компилятор. Зачем, ради чего?!
Вот, в посте есть замечательная ссылка на блок члена комитета по стандартизации С - он прямо об этом же пишет:
(краткий пересказ-перевод)
С постоянно продает себя как "простой язык". Но это ложь! На С даже два числа сложить нельзя, не подглядывая в стандарт (ой, а не закралось ли UB?), но менеджменту говорили не это! Им говорили "любой хороший разработчик может сляпать компилятор за пару дней", эту иллюзию поддерживают все нормальные компиляторы (gcc, clang и т.д.), ведь все их оптимизации и проверки - необязательные!
На самом деле стандарт гарантирует так мало, что это просто смешно - но даже это реализовать правильно ужасающе сложно!
Именно поэтому все попытки производителей чипов сделать свой компилятор приводили лишь к забагованным кускам <вырезано цензурой>.
Now now, I say that like the compiler authors are being vindictive. The reality of the matter is that C has repeatedly and perpetually sold itself as being a “simple” language. And I mean…
Is it?
Can’t add 2 numbers together in C without consulting the holy standard about whether or not some UB’s been tripped, let alone with a well-defined way to figure out how to stop it. We recently just had to reinforce a Defect Report where we stated that “yes, even if a compiler can figure out that your array bounds are, in fact, a constant number, we have to treat the creation and usage of the array like a VLA because the Standard’s constant expression parser isn’t smart enough!”.
C is not a simple language.
That’s not what management gets told, of course. What management hears is the spicy dream, the “any good developer can bang out a C compiler drunk out of their mind on a weekend”. The way the Standard supports that dream is by making all of the good stuff people get used to in GCC, Clang, EDG or whatever else “optional” or “recommended”. What’s actually guaranteed to you by the C Standard is so pathetically miniscule it’s sad (and even that tiny little bit is still complex!). It’s why every person who ran off to “write their own C compiler” did a miserable job, why every embedded chipset thought they could roll their own C compilers and ended up with a bug-ridden mess. It’s why there are so many #ifdef __SUN_OS and // TODO: workaround, please removes that end up becoming permanent fixtures for 17 years.
Насчет vendor-specific компиляторов - это ведь реально так, даже ARM сливает свой armcc и вместо него переходит на форк clang'a, потому что сделать свой нормальный компилятор для своей же архитектуры оказалось слишком сложно!
Простите, что-то у меня пригорело слишком сильно..
Да, так вот. Я реально не вижу никаких причин активно поддерживать множество компиляторов для одного языка, это только распыляет усилия людей и создает проблемы переносимости на ровном месте, поэтому мне очень интересно, почему вы считаете, что это хорошо :)
Но рискну предположить, в таком случае, что вы делаете какие-то _не очень_ критичные по времени выполнения вещи, и в таком случае вам, действительно, не очень важно, насколько C# медленнее. Не вижу в этом ничего плохого :)
Неоднократно наблюдал, как в метро убирают рвоту: засыпают опилками, ждут, а потом заметают в совочек. Выглядит удивительно эффективно плюс не приходится наклоняться или использовать руки напрямую для уборки (поскольку и совок и метла с длинными палками).
>Одну структуру можно встроить в другую так, как это реализовано в Go (и даже лучше - используется ключевое слово inline). Это очень простая и в то же время мощная концепция, прямо готовая для proposal'а в очередной стандарт С и/или С++... Удивительно - почему ее сразу не сделали в Си?
В С++ это уже давно есть, только называется немножко иначе - наследование :)
Мне казалось, что scots в данном контексте вроде бы все-таки "жители шотландии" или точнее, "говорящие на шотландском диалекте английского" (который Scottish Standard English), а не именно "говорящие на скотсе/гэльском".
А разве можно рассчитывать, что
sizeof(size_t) == sizeof( uint32_t)?Вроде ж нужно юзать штуки из inttypes.h?
Бене Гессерит же :)
Интересно, что тот же мультитран дает довольно много вариантов перевода:
carouse; fuddle; lush; deep potations; drink; spree; drinking spree
Но судить об их корректности не возьмусь :)
А из редактора для комментариев пропало превью (или я просто не могу его найти?) и возможность использовать маркдаун (или я просто не могу ее найти?)
Еще года три назад я прям очень бесился, когда мои студенты путали "сдвиг" и "смещение", но сейчас я полностью принял дескриптивный взгляд на лингвистику и считаю, что бороться с такими явлениями невозможно.
Да, для меня странно слышать слово "битЫ", а не "бИты" (когда речь про bits, а не beats) или когда говорят "адрес НА первый элемент массива", вместо "адрес первого элемента", но я не вижу смысла с этим спорить :) Правильность в языке - дело привычки.
Но так же странно было людям 100 лет назад слышать как всех детей (а не только крестьянских) называют "ребята", а мне странной кажется фраза "не умаляя общности" из учебника по матанализу..
Язык меняется и, на мой взгляд, с этим ничего делать не нужно, только стрессовать зря.
(Ну а если конкретнее, придирки в статье мне кажутся уж совсем высосанными из пальца по большей части; разницы между "послать" и "отправить" я вообще не вижу.. что лишний раз демонстрирует субъективность восприятия таких вещей).
На мой взгляд, есть еще очень большая проблема вот какого плана: если гуглить по-английски любые вопросы по С и С++ - попадаешь на stackoverflow и cppreference, а если гуглить по-русски, то оказывается, что ресурсов-то особо и нет!
И в выдаче будет либо машинный перевод того же stackoverflow, либо какой-нибудь простите cyberforum, где точно такие же джуны обмениваются кодом даже не обернутым в теги.
Учебники вроде как есть, но их много и они большие, а вот на короткий простой вопрос ответ хрен найдешь.
И видеокурсов тоже как-то не густо русскоязычных.
Соответственно за эту дорожную карту вам большое спасибо :)
Да, но чтобы посчитать хэш - пароль сперва таки нужно получить в открытом виде.
А что, IAR тоже свой компилятор дропнули?
По-моему это тоже самое другими словами :) Сложно => дорого и/или долго => экономически нецелесообразно.
Простите, но зачем?..
Миллионы несовместимых компиляторов С (и стандартных библиотек, не забывайте еще и про них) - это огромная проблема, причем это проблемы программистов, вы вспомните, сколько ифдефов нужно написать, просто чтобы обеспечить совместимость с gcc/clang/msvc!
Когда появился С - не было интернета, распространить единый компилятор было очень трудно, а книжку - относительно легко, вот все и писали эти компиляторы..
Но это же безумие просто, повторять раз за разом одну и ту же работу, писать сотни раз одну и ту же стандартную библиотеку, наступать на те же грабли - вместо того, чтобы завести один единственно-верный (опенсорсный, разумеется) компилятор. Зачем, ради чего?!
Вот, в посте есть замечательная ссылка на блок члена комитета по стандартизации С - он прямо об этом же пишет:
(краткий пересказ-перевод)
С постоянно продает себя как "простой язык". Но это ложь! На С даже два числа сложить нельзя, не подглядывая в стандарт (ой, а не закралось ли UB?), но менеджменту говорили не это! Им говорили "любой хороший разработчик может сляпать компилятор за пару дней", эту иллюзию поддерживают все нормальные компиляторы (gcc, clang и т.д.), ведь все их оптимизации и проверки - необязательные!На самом деле стандарт гарантирует так мало, что это просто смешно - но даже это реализовать правильно ужасающе сложно!Именно поэтому все попытки производителей чипов сделать свой компилятор приводили лишь к забагованным кускам <вырезано цензурой>.Now now, I say that like the compiler authors are being vindictive. The reality of the matter is that C has repeatedly and perpetually sold itself as being a “simple” language. And I mean…
Is it?
Can’t add 2 numbers together in C without consulting the holy standard about whether or not some UB’s been tripped, let alone with a well-defined way to figure out how to stop it. We recently just had to reinforce a Defect Report where we stated that “yes, even if a compiler can figure out that your array bounds are, in fact, a constant number, we have to treat the creation and usage of the array like a VLA because the Standard’s constant expression parser isn’t smart enough!”.
C is not a simple language.
That’s not what management gets told, of course. What management hears is the spicy dream, the “any good developer can bang out a C compiler drunk out of their mind on a weekend”. The way the Standard supports that dream is by making all of the good stuff people get used to in GCC, Clang, EDG or whatever else “optional” or “recommended”. What’s actually guaranteed to you by the C Standard is so pathetically miniscule it’s sad (and even that tiny little bit is still complex!). It’s why every person who ran off to “write their own C compiler” did a miserable job, why every embedded chipset thought they could roll their own C compilers and ended up with a bug-ridden mess. It’s why there are so many
#ifdef __SUN_OSand// TODO: workaround, please removes that end up becoming permanent fixtures for 17 years.Насчет vendor-specific компиляторов - это ведь реально так, даже ARM сливает свой armcc и вместо него переходит на форк clang'a, потому что сделать свой нормальный компилятор для своей же архитектуры оказалось слишком сложно!
Простите, что-то у меня пригорело слишком сильно..
Да, так вот. Я реально не вижу никаких причин активно поддерживать множество компиляторов для одного языка, это только распыляет усилия людей и создает проблемы переносимости на ровном месте, поэтому мне очень интересно, почему вы считаете, что это хорошо :)
Сочувствую..
Но рискну предположить, в таком случае, что вы делаете какие-то _не очень_ критичные по времени выполнения вещи, и в таком случае вам, действительно, не очень важно, насколько C# медленнее. Не вижу в этом ничего плохого :)
Да, это вполне нормальный тест, только я бы предложил к вашему списку добавить в качестве эталонного значения код на С с прямой записью в регистры.
>У меня пока нет достаточно точных контрольно-измерительных устройств для проведения замеров.
У вас нет осциллографа?
Главный или нет, но сравнение все равно было бы интересно увидеть :)
Неоднократно наблюдал, как в метро убирают рвоту: засыпают опилками, ждут, а потом заметают в совочек. Выглядит удивительно эффективно плюс не приходится наклоняться или использовать руки напрямую для уборки (поскольку и совок и метла с длинными палками).
Помнится, в "Паутине" Шелли этот эффект назывался "меморт" - или "синдром мертвой памяти" :)
>Одну структуру можно встроить в другую так, как это реализовано в Go (и даже лучше - используется ключевое слово
inline). Это очень простая и в то же время мощная концепция, прямо готовая для proposal'а в очередной стандарт С и/или С++... Удивительно - почему ее сразу не сделали в Си?В С++ это уже давно есть, только называется немножко иначе - наследование :)
Мне казалось, что scots в данном контексте вроде бы все-таки "жители шотландии" или точнее, "говорящие на шотландском диалекте английского" (который Scottish Standard English), а не именно "говорящие на скотсе/гэльском".
Шотландцы не могут произнести burglar alarm :)
Не знаю, к сожалению.
Справедливо. Я чесгря никогда не мог запомнить разницу :)