Очень интересная, полезная и грамотно-написанная статья. Она заслуживает большего как мне кажется, также присутствует много разбора кода что тоже будет многим полезно. Кстати непонятно, почему текста написанные людьми с опытом в среднем набирают меньше просмотров, и плюсов? К примеру даже моя первая скандальная статья вызвала гораздо более крупные обсуждения и набрала больше плюсов...
Жду больше статей по С и программированию в целом, так держать!
Ух это да. Но я думаю вряд-ли такое останется без внимания - компилятор сгенерирует столько ошибок, сколько было написано new, и тогда злополучная строка быстро обнаружится.
Вы добавили очень сомнительной полезности сахар и положили рядом граблю
Насчёт полезности честно не знаю - вкусовщина. Кому-то тип легче написать, а кому-то sizeof подтянуть. Всё ради эксперимента
Кстати такая же неприятность может случиться вот с таким макросом:
Ну я не считаю что макросы с переменным количеством аргументов плохи, если вы это имели ввиду. Я считаю что если такая возможность языка имеется, и её можно применить, то её нужно применить. А что плохого вы видите в их использовании? Было бы интересно послушать о минусах/подводных камнях/недостатках и неудобства их использования, да и другим будет полезно
получилось сделать свой код несовместимым с С++ ))
Но ведь главной целью не было сделать код совместимым с С++. Главной целью было повторить синтаксически и максимально похоже оператор new в С, с чем я считаю справился ( за исключением скобок ) - но это уже не критично.
Вы себе сами выше придумали задачу: распечатать текст, который хранится в uint64. Ее хотя бы доделайте до конца.
А кросс-платформенное решение я уже опубликовал в статье, вот оно краткое и лаконичное:
extern uint64_t x; //сама строка
if (!x)
return; //если строка нулевая то завершаем работу функции
do {
putchar((char)(x & 0xFF)); //печатаем байт
x >>= 8; //удаляем байт
} while (x); //пока число не станет нулем
Это немного переделанная версия чтобы не возникло претензий к стилю написания. Я буду удивлён если такой код не заработает на какой-либо платформе имеющей хорошую реализацию С. И так этот код может НЕ заработать только по следующим причинам:
Платформа не поддерживает С
Платформа не имеет файла inttypes.h/stdint.h
uint64_t не хранится в памяти на этой платформе по порядку в одной ячейке и его байты раскиданы по памяти как связный список.
Платформа не имеет файла stdio.h
Не знаю как вы но платформы с выше перечисленным списком я не знаю и поэтому не могу полностью отрицать факта её существования. Можно ли такой код назвать кросс-платформенным?
Опытные программисты на С умеют избегать UB жертвуя объёмом кода, и я стремлюсь следовать этому совету. Мы же тут не за краткостью кода собрались, а если да то тогда Python будет хорошим вариантом
В Си статическими удобно делать мелкие функции определяемые в хедерах.
А зачем писать функции в хедерах если можно сразу написать их в том файле который подключает этот хедер так ещё и статические. Может тут какой-то трюк?
А уж про саму оболочку вообще ничего нематерного сказать не смогу, это вообще какой-то конец 90х в плане комфорта и эффективности разработки
Ну да среда и правда сомнительная но наоборот заточена под комфорт как бы это парадоксально не звучало. В Arduino IDE (если вы о нём говорите) как по мне удобное решение - простой редактор, две кнопки для прошивки и компиляции. А что именно вам пришлось не по вкусу?
И учить с ассемблера я бы никому не рекомендовал начинать, есть предел того, куда стоит лезть с отсутствием понимания, на данный момент и Си работает отлично
Вот это да но почему никому? Если человек работает и прошивает или пишет прошивки для железа он хочет чтобы программа работала настолько быстро насколько это возможно в теории. Я не спорю - Си это один из немногих языков где можно писать дичь - while($>>=x^28+~10) f("89!"+op<<1);, и на том же языке можно писать вполне себе читабельные высокоуровневые программы. А если захочется - с помощью инструментов языка можно вставить ассемблерный код напрямую в С - тогда компилятор его компилировать не будет. Вот это я понимаю комбо =)
Си работает отлично
Несомненно. Правда иногда задумываешься - какую следующую коварную оптимизацию применит компилятор чтобы испортить твою программу?)
#include <stdio.h>
#include <inttypes.h>
int main(void){
uint64_t x = 0x2E6D6172676F7270;
printf ("%.8s\n", (char*)&x);
}
Вывод: program.(правильный вывод)
А вот ваша версия:
#include <stdio.h>
#include <inttypes.h>
int main(void){
uint64_t x = 0x2E006172676F7270;
printf ("%.8s\n", (char*)&x);
}
Вывод: progra (неправильный вывод)
Потому что как только printf доходит до предпоследнего байта (который у вас превратился в 00) вывод других символов завершается. Из-за этого мы потеряли букву m и точку. Всё верно
Ардуино создавалась как лайтовая платформа для практики электроники (как конструктор). Библиотеки на любой вкус и цвет. Там конечно можно и на ассемблере писать, но зачем если есть прекрасный средне-уровневый С который в каждой микроволновке работает. Если интересно как работают железяки и процессоры на низком уровне и хочется разбираться то как по мне лучше сразу брать какой-нибудь MOS 6502 и писать на нём на чистом ассемблере. Правда у меня его пока нет =)
Да, скоро хабровчане будут читать статьи написанные нейросетями, такое будущее уже не за горами
Очень интересная, полезная и грамотно-написанная статья. Она заслуживает большего как мне кажется, также присутствует много разбора кода что тоже будет многим полезно. Кстати непонятно, почему текста написанные людьми с опытом в среднем набирают меньше просмотров, и плюсов? К примеру даже моя первая скандальная статья вызвала гораздо более крупные обсуждения и набрала больше плюсов...
Жду больше статей по С и программированию в целом, так держать!
А что именно странного в статье вы заметили?
А что не так?
Вы же понимайте что комментарии подобного рода автору вообще ничего не говорят о его ошибках?
Не костыль, а принятый стандартом С99 инструмент
Почему же? Есть такое ключевое слово, которым гарантируется что данный указатель является единственным способом получения доступа к объекту:
Здесь указатели p1 и p2 могут быть «агрессивно» оптимизированы так как программист гарантирует что они ни с чем не пересекаются
Ух это да. Но я думаю вряд-ли такое останется без внимания - компилятор сгенерирует столько ошибок, сколько было написано new, и тогда злополучная строка быстро обнаружится.
Насчёт полезности честно не знаю - вкусовщина. Кому-то тип легче написать, а кому-то sizeof подтянуть. Всё ради эксперимента
Кстати такая же неприятность может случиться вот с таким макросом:
Проблем доставит ещё больше чем дефайн new.
Конечно лучше, никто не спорит. Следует использовать инструменты которые присутствуют в языке. Я просто экспериментировал :)
Хм интересно. Может напишу об этом статью потом. Но здесь задумкой было повторить его синтаксически, а не технически.
Ну я не считаю что макросы с переменным количеством аргументов плохи, если вы это имели ввиду. Я считаю что если такая возможность языка имеется, и её можно применить, то её нужно применить. А что плохого вы видите в их использовании? Было бы интересно послушать о минусах/подводных камнях/недостатках и неудобства их использования, да и другим будет полезно
Но ведь главной целью не было сделать код совместимым с С++. Главной целью было повторить синтаксически и максимально похоже оператор new в С, с чем я считаю справился ( за исключением скобок ) - но это уже не критично.
Спасибо =)
А кросс-платформенное решение я уже опубликовал в статье, вот оно краткое и лаконичное:
Это немного переделанная версия чтобы не возникло претензий к стилю написания. Я буду удивлён если такой код не заработает на какой-либо платформе имеющей хорошую реализацию С. И так этот код может НЕ заработать только по следующим причинам:
Платформа не поддерживает С
Платформа не имеет файла
inttypes.h/stdint.huint64_tне хранится в памяти на этой платформе по порядку в одной ячейке и его байты раскиданы по памяти как связный список.Платформа не имеет файла
stdio.hНе знаю как вы но платформы с выше перечисленным списком я не знаю и поэтому не могу полностью отрицать факта её существования. Можно ли такой код назвать кросс-платформенным?
Опытные программисты на С умеют избегать UB жертвуя объёмом кода, и я стремлюсь следовать этому совету. Мы же тут не за краткостью кода собрались, а если да то тогда Python будет хорошим вариантом
Почему же не могу? Пишите что должен делать сниппет (только не гигантский проект) а я реализую его как кросс-платформенный
Я здесь не для заработка денег :)
А у вас есть что возразить насчёт этого? Написал допустим + или -> и сразу можешь предсказать что будет на выходе
А зачем писать функции в хедерах если можно сразу написать их в том файле который подключает этот хедер так ещё и статические. Может тут какой-то трюк?
Ну да среда и правда сомнительная но наоборот заточена под комфорт как бы это парадоксально не звучало. В Arduino IDE (если вы о нём говорите) как по мне удобное решение - простой редактор, две кнопки для прошивки и компиляции. А что именно вам пришлось не по вкусу?
Вот это да но почему никому? Если человек работает и прошивает или пишет прошивки для железа он хочет чтобы программа работала настолько быстро насколько это возможно в теории. Я не спорю - Си это один из немногих языков где можно писать дичь -
while($>>=x^28+~10) f("89!"+op<<1);, и на том же языке можно писать вполне себе читабельные высокоуровневые программы. А если захочется - с помощью инструментов языка можно вставить ассемблерный код напрямую в С - тогда компилятор его компилировать не будет. Вот это я понимаю комбо =)Несомненно. Правда иногда задумываешься - какую следующую коварную оптимизацию применит компилятор чтобы испортить твою программу?)
Вот моя версия:
Вывод:
program.(правильный вывод)А вот ваша версия:
Вывод:
progra(неправильный вывод)Потому что как только printf доходит до предпоследнего байта (который у вас превратился в 00) вывод других символов завершается. Из-за этого мы потеряли букву m и точку. Всё верно
Ардуино создавалась как лайтовая платформа для практики электроники (как конструктор). Библиотеки на любой вкус и цвет. Там конечно можно и на ассемблере писать, но зачем если есть прекрасный средне-уровневый С который в каждой микроволновке работает. Если интересно как работают железяки и процессоры на низком уровне и хочется разбираться то как по мне лучше сразу брать какой-нибудь MOS 6502 и писать на нём на чистом ассемблере. Правда у меня его пока нет =)