Здравствуйте, tranzit, Вы писали:

T>какое-нибудь устройство делал со своей прошивкой ?

Ты бы код посмотрел, если с теми архитектурами знаком. Пишешь сразу под кучу процессоров, не лазая по даташитам как обезьяна и не обкладываясь дефайнами. При этом в результате никакого оверхеда, поскольку статический полиморфизм, статические функции и инлайн.

Здравствуйте, Ops, Вы писали:

Ops>Здравствуйте, tranzit, Вы писали:

T>>какое-нибудь устройство делал со своей прошивкой ?

Ops>Ты бы код посмотрел, если с теми архитектурами знаком. Пишешь сразу под кучу процессоров, не лазая по даташитам как обезьяна и не обкладываясь дефайнами. При этом в результате никакого оверхеда, поскольку статический полиморфизм, статические функции и инлайн.

Дык скачал и посмотрел уже.
Я сам паял toy разные вещи на avr.
И спросил без какого либо сарказма.

Здравствуйте, tranzit, Вы писали:

T>Дык скачал и посмотрел уже.
T>Я сам паял toy разные вещи на avr.
T>И спросил без какого либо сарказма.

Просто многие утверждают, что плюсы в МК не нужны, а про такой способ даже не задумывались. И дело не в самой библиотеке, она скорее как иллюстрация подхода, хотя я ее даже использовал, как раз под AVR. Получаем рабочие абстракции, код легко собирается под разные камни, при этом пишется и читается очень легко. И все это бесплатно, компилятор оставляет только функциональный код.

Здравствуйте, bazis1, Вы писали:

B>А теперь предположим, что вместо unsigned вдруг понадобился какой-нибудь bigint. И все, на Си приходится руками переписывать "a = b % a" в "bigint_mod(&a, &b, &a)". А с шаблонным решением достаточно определить свои traits и ВСЕ алгоритмы, их использующие автоматически начинают поддерживать ваш тип.

Но надо сказать, что даже если написать на Си ассортимент вариантов на все случаи жизни, все равно получится меньше кода, чем в бустовской реализации на стероидах темплейтах.

Я хочу сказать, обобщенная реализация алгоритмов — штука, конечно хорошая. Но не получается ли так, что в некоторых (во многих?) случаях цена, которую за нее приходится заплатить в C++, существенно превышает выгоду?

Здравствуйте, tranzit, Вы писали:

T>Но не стоит для микроконтроллера с памятью в 1к писать программы на c++/c

Я писал для avr'ки со 128-ю байтами памяти на Си. Причем сначала сдуру написал кусок на ассемблере, сходу не заработало, надо было алгоритм тьюнить. Набросал за вечер прототип на Си, покрутил его туда-сюда, и так в конечной версии и оставил.

Здравствуйте, Lonely Dog, Вы писали:

LD>Привет!

LD>Я 15 лет пишу на C++, немного знаю C#, Python и пр. Но совершенно не понимаю, как писать на C.
...
LD>Может есть какие-нибудь книги? Думаю, посмотреть что-то типа Writing device drivers for Linux.
LD>Заранее спасибо.

сам был в такой ситуации. Переход с языка С++ на С очень болезненный. Как всегда обсуждения скатываются на достоинства и недостатки парадигм программирования и мало кто отвечает на вопросы ТС. Чтобы понять, что с++ в Вашем случае использовать не получится, можно несколько слов написать про Ваш проект, который требует (по Вашему мнению) именно чистого С (если это не секрет)?

Здравствуйте, so5team, Вы писали:

S>>>У вас res уже содержит UB_NOERROR. Запутались в трех простых соснах. В типа простом C.
P>>Угу, запутался.
S>В этом и проблема. В C слишком много деталей, про которые нужно помнить. Поэтому люди путаются.
Да ну? А в современном стандарте С++ не много деталей которые нужно помнить?

Здравствуйте, _smit, Вы писали:

_>сам был в такой ситуации. Переход с языка С++ на С очень болезненный.
А для меня в удовольствие. Из мозга сразу высвободилось много место из под с++ оверхеда правил/особенностей под конкретные платформенные знания в С.
Правда, когда пришлось возвращаться, опять пришлось держать в памяти эту кучу правил и особенностей.

Здравствуйте, Vain, Вы писали:

V>Здравствуйте, _smit, Вы писали:

_>>сам был в такой ситуации. Переход с языка С++ на С очень болезненный.
V>А для меня в удовольствие. Из мозга сразу высвободилось много место из под с++ оверхеда правил/особенностей под конкретные платформенные знания в С.
V>Правда, когда пришлось возвращаться, опять пришлось держать в памяти эту кучу правил и особенностей.

с языком С++ живу уже 15 лет, я уже "думаю" на нем. Железка была с 64М flash и 16М RAM, процессор MIPS. Поковырявшись с С (из-за саботажа пары программистов) понял, что оказался как без рук -- без автоматического управления памятью, структур и алгоритмов. Собрал компилятор, библиотеки, изучил MIPS-ASM, язык управления линкером, написал загрузчик, сделал инструкции для программистов, подключил с++ программистов и жизнь закипела.

Здравствуйте, Vain, Вы писали:

S>>В этом и проблема. В C слишком много деталей, про которые нужно помнить. Поэтому люди путаются.
V>Да ну? А в современном стандарте С++ не много деталей которые нужно помнить?

Под фразой "в С слишком много деталей, про которые нужно помнить" подразумевалось, что в программе на C таких деталей слишком много. Банально:

void f() {
  char * buf = malloc(1024);
  ... // (1)
  free(buf);
}

Везде в блоке (1) нужно помнить, что нельзя сделать преждевременный return. Даже если (1) разрастается до сотни-другой строк. Даже если (1) сопровождается в течении нескольких десятилетий совершенно разными программистами из разных частей света.

Так что ну да.

А вопросы объема стандартов волнуют, в первую очередь, компиляторописателей. Обычным разработчикам, как правило, в сам стандарт и заглядывать не приходится.

Здравствуйте, so5team, Вы писали:

S>Под фразой "в С слишком много деталей, про которые нужно помнить" подразумевалось, что в программе на C таких деталей слишком много. Банально:
S>

void f() {
S>  char * buf = malloc(1024);
S>  ... // (1)
S>  free(buf);
S>}

S>Везде в блоке (1) нужно помнить, что нельзя сделать преждевременный return. Даже если (1) разрастается до сотни-другой строк. Даже если (1) сопровождается в течении нескольких десятилетий совершенно разными программистами из разных частей света.
S>Так что ну да.
Пустячок по сравнению с гаданием на кофейной гуще, какая перегрузка вызовется из фаршмака шаблонной магии, enable_if'ов и кучи другой хрени из синтаксического сахара. А также гадание на том, почему не вызвалась вообще.

S>А вопросы объема стандартов волнуют, в первую очередь, компиляторописателей. Обычным разработчикам, как правило, в сам стандарт и заглядывать не приходится.
Ага, щас. Прям вот на этом форуме куча вопросов можешь поискать с ответами "в стандарте".

Здравствуйте, Vain, Вы писали:

V>Пустячок по сравнению с гаданием на кофейной гуще, какая перегрузка вызовется из фаршмака шаблонной магии, enable_if'ов и кучи другой хрени из синтаксического сахара. А также гадание на том, почему не вызвалась вообще.

Пример можно увидеть?

Здравствуйте, so5team, Вы писали:

V>>Пустячок по сравнению с гаданием на кофейной гуще, какая перегрузка вызовется из фаршмака шаблонной магии, enable_if'ов и кучи другой хрени из синтаксического сахара. А также гадание на том, почему не вызвалась вообще.
S>Пример можно увидеть?
Не коллекционер таких примеров. Но вот первый пример буквально на второй странице нашёл:
http://rsdn.org/forum/cpp/6534716

Автор: Кодт
Дата: 26.08.16

Здравствуйте, Vain, Вы писали:

V>>>Пустячок по сравнению с гаданием на кофейной гуще, какая перегрузка вызовется из фаршмака шаблонной магии, enable_if'ов и кучи другой хрени из синтаксического сахара. А также гадание на том, почему не вызвалась вообще.
S>>Пример можно увидеть?
V>Не коллекционер таких примеров. Но вот первый пример буквально на второй странице нашёл:
V>http://rsdn.org/forum/cpp/6534716

Автор: Кодт
Дата: 26.08.16

И? Как это же сделать на более простом C, в котором не будет enable_if и кучи другой хрени?

Здравствуйте, so5team, Вы писали:

V>>>>Пустячок по сравнению с гаданием на кофейной гуще, какая перегрузка вызовется из фаршмака шаблонной магии, enable_if'ов и кучи другой хрени из синтаксического сахара. А также гадание на том, почему не вызвалась вообще.
S>>>Пример можно увидеть?
V>>Не коллекционер таких примеров. Но вот первый пример буквально на второй странице нашёл:
V>>http://rsdn.org/forum/cpp/6534716

Автор: Кодт
Дата: 26.08.16

S>И? Как это же сделать на более простом C, в котором не будет enable_if и кучи другой хрени?
ЗАЧЕМ? Какая задача решается, что не обойтись без такого?

Здравствуйте, Vain, Вы писали:

V>>>Не коллекционер таких примеров. Но вот первый пример буквально на второй странице нашёл:
V>>>http://rsdn.org/forum/cpp/6534716

Автор: Кодт
Дата: 26.08.16

S>>И? Как это же сделать на более простом C, в котором не будет enable_if и кучи другой хрени?
V>ЗАЧЕМ? Какая задача решается, что не обойтись без такого?

Это вы объясните, вы же привели пример. Или приведите какой-то другой пример, в котором вы будете знать постановку задачи.

Как я сказал ранее, обычному разработчику, как правило, в стандарт заглядывать не приходится. Если приходится, значит человек делает что-то нетривиальное (что вряд ли приходится делать обычному разработчику). А раз так, то было бы полезно сравнить это самое нетривиальное на C++ с реализацией этого же самого нетривиального на C. Но так мы быстро придем к тому, что C++ сложен в вещах, которые на C вообще не реализуемы. Т.е. придется сравнивать "сложное" с "невозможным".

Здравствуйте, so5team, Вы писали:

S>>>И? Как это же сделать на более простом C, в котором не будет enable_if и кучи другой хрени?
V>>ЗАЧЕМ? Какая задача решается, что не обойтись без такого?
S>Это вы объясните, вы же привели пример.
Вам объяснить как в С можно решить всё без шаблонов и магии?

S>Или приведите какой-то другой пример, в котором вы будете знать постановку задачи.
Так приводи. Это же не я стараюсь enable_if присовывать.

S>Как я сказал ранее, обычному разработчику, как правило, в стандарт заглядывать не приходится. Если приходится, значит человек делает что-то нетривиальное (что вряд ли приходится делать обычному разработчику).
Да, в С++ приходится заглядывать. В качестве примера, вопросы с этого форума по С++. Спрашивай у авторов, что за проблемы они решают, что потребовалось такое. Почему ты у меня спрашиваешь?

S>А раз так, то было бы полезно сравнить это самое нетривиальное на C++ с реализацией этого же самого нетривиального на C. Но так мы быстро придем к тому, что C++ сложен в вещах, которые на C вообще не реализуемы.
Нереализуемо что? Поставленная задача? Или шашечки?

S>Т.е. придется сравнивать "сложное" с "невозможным".
Брехня

Здравствуйте, Vain, Вы писали:

S>>>>И? Как это же сделать на более простом C, в котором не будет enable_if и кучи другой хрени?
V>>>ЗАЧЕМ? Какая задача решается, что не обойтись без такого?
S>>Это вы объясните, вы же привели пример.
V>Вам объяснить как в С можно решить всё без шаблонов и магии?

Не всё, а пример, на который вы сослались.

Но, т.к. с этим вряд ли получится, давайте вернемся чуток назад. Я вам показал грабли с malloc/free. Типичные, про которые должен знать любой разработчик на C. Вы от этого примера отмахнулись и заявили, что это ерунда по сравнению с проблемами шаблонов и enable_if.

Ну так покажите же эти проблемы. Где они? В синтетическом тесте, который специально был написан, чтобы показать проблему о которой раньше никто не задумывался? Прекрасный аргумент. Какое отношение это имеет к повседневной разработке на C++?

V>Брехня

Ожидаю, что все остальные аргументы будут какого же уровня.

Здравствуйте, Vain, Вы писали:

V>Пустячок по сравнению с гаданием на кофейной гуще, какая перегрузка вызовется из фаршмака шаблонной магии, enable_if'ов и кучи другой хрени из синтаксического сахара. А также гадание на том, почему не вызвалась вообще.
Действительно в C всё гораздо проще:

#include <stdio.h>
  
#define type_x(T) _Generic( (T), double*: 1, double: 2, default: 3)
#define type_idx(T) _Generic( (T), char: 1, int: 2, long: 3, default: type_x( (T) ) + 1.0 * type_x( (T) ))
   
int main(void) {
    printf("%d", type_idx(1u));
    return 0;
}

Не стесняемся, угадываем выхлоп программы

Здравствуйте, _NN_, Вы писали:

_NN>Не стесняемся, угадываем выхлоп программы
6?