смотрю, плюсисты никак не выучат. вечно проблемы с языком возникают

Ещё раз. Чисто наблюдения показывают, точнее, показали лет 12-16 назад, что вопросы, касаемые конструкций языка, у программистов на асм практически не обсуждаются, зато активно муссируются у С-шников. Помнятся по SU.CROSSTOOLS да RU.EMBEDDED имено такие "болезни роста" и точно так же многие тогда говорили, что фигня это всё и ассемблерщики борятся с железом и задачей, а С-шники с языком и компилятором. И много приходилось спорить и доказывать, что борьба с компилятором - просто от незнания основ языка в духе правил приведения типов.
Но по мере увеличения числа знающих С эти вопросы отпали, место С во встроенных системах никто не оспаривает. Сейчас слово "асм" заменилось на "С", "С" на "С++" и наблюдаем второй виток. От тех, кто не видел первого?

стандартов на языки понаделали давно. с появлением стандартов на си - все болезни роста пропали.
на плюсы вроде как уже 12 лет первому стандарту, а проблемы языка - остались.
похоже этот "виток" превратился в вечное кольцо.

Поэтому пора уже думать об С#

В упомянутые времена разговоров про "С-шники воюют с компилятором" языку С тоже много лет было, стандарту C89 было много лет, С99 был на подходе.
Но в нише мелкоконтроллеров он был многим в новинку, болезни роста не от возраста языа зависят, а от времени его применения в нише, так как это болезни роста не языка как такового.
Многие из тех, кто много лет просидел в этой нише на ассемблере - просто не воспринимали С. Вопросы "рискнувших" (в смысле применения С) укрепляли их в вере в то, что "С-шники борятся ..." дале по тексту. Но "рискнувшие" прошли свою фазу освоения языка и все те вопросы остались, но они теперь ассоциируются не со всеми, применяющими С, а только с новичками. А "тогда" практически все новичками и были, С был уделом программистов на "достаточно больших машинах", а "в эмбеддед ему не место" (хотя я удивлялся — почему на "ДВК-2" с 56К озу на всё про всё вместе с ОС ему за десять лет до этого было место, а на 8051 с 16-20-32К ПЗУ для автономной программы — так не место).

С его то идеологией уборки мусора?

А что там с идеологией не так?
Стековый язык, с уборкой проблем быть не должно

http://msdn.microsoft.com/en-us/library/ms...28VS.90%29.aspx :

Управляеймый код, конечно, хорошо в своей области, но, как правило, во встраваимых системах программист привык быть уверенным в том, что и как делает программа. А если забывать за собой убирать - наверное, стоит сменить профиль
Оффтоп. Почему C# не такой популярный? потому, что его разрабатывал мужик без бороды.

ReAl
при чём тут ниша и контроллеры? если обсуждаются проблемы именно языковых конструкций. зайдите на любой форум программеров - война с языком идёт вечно. причём чуть ли не с базовыми конструкциями.

"С войной покончили мы счеты —
Бери шинель, пошли домой!"

Потому что на архитектуру PDP-11 ложится идеально. А на 51 - увольте

Добрый день.
Неожиданно был удивлен что здесь из-за такого вопроса получился холивар.
Считаю что разработчик сам должен для себя решить на каком языке и с какой эффективностью он будет реализовывать проект.
Так что считаю вообще спор бессмысленным. И прошу его прекратить.

И если можно ответить еще на один вопрос.
Можно ли каким либо образом сделать переход из одного метода класса в другой не вызовом его через Call а переходом через Jmp.
Вернее что бы компилировалось так. А то сейчас у меня два метода которые возвращают один и тот же тип WatcherState
Но при этом один просто выполняет проверки и возвращает значение
Второй же более длинный по времени выполнения выполняет расчет и так же возвращает WatcherState
Вот как я это пока написал

Что можете посоветовать?

Может я ошибаюсь, но сдается мне, что никак так не сделать. Либо как-то в отдельно взятом компиляторе, но все равно сомневаюсь. Очень.
А инлайн не подходит?

А чем собственно call не угодил? Хотите пару тактов и пару байт в стеке съэкономить? Если это действительно важно - можно сделать эти функции члены (в С++ нет методов) inline? Например написать их реализацию в объявлении класса. Если функции маленькие, то возможно удастся съэкономить и побольше, за счет отсутствия вызовов и передачи аргументов.