Все три.

C. Только C.

Меня смущает связка Assembler+C++. Разве что ради вставки какой-нибудь команды нового процессора, о которой компилятор ещё не в курсе в оптимизированном по времени выполнения коде.

Меня смущает связка Assembler+C++. Разве что ради вставки какой-нибудь команды нового процессора, о которой компилятор ещё не в курсе в оптимизированном по времени выполнения коде.

Ну если придумывать пример... оптимизировать рейтрейсер векторизованными вычислениями.

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

Ассемблер всегда полезен. Лучше «железо» чувствуешь. Но и без него вполне можно обходиться.

Тем не менее, я бы сделал основной упор на С.

Мак вообще не рассматриваю, из-за аллергии на анальные-зонды)))

Ага, а винда - это, конечно, не «анальный зонд», ага...

Мак вообще не рассматриваю, из-за аллергии на анальные-зонды)))

Не волнуйся, детка, тебя туда и не возьмут ;)

а простите

Туда это куда? Вроде уже работал на Маке...не понравилось, хотя в этом что-то все же есть..

P.S не стоит мир делить на Linux, Windows, Mac. Нужно просто всем этим пользоваться, и применять плюсы которые возможны.

и применять C/Python/Lua которые возможны.

отремонтировал

Туда это куда?

Туда где пишут на системном уровне для Mac ;)

P.S не стоит мир делить на Linux, Windows, Mac. Нужно просто всем этим пользоваться, и применять плюсы которые возможны.

Это к вопросу не относится. Вопрос в разработке а не использовании

С стоит изучать. Ассемблер - нет.

Assembler знать стоит, но не писать на нём. плюсы стоит изучать примерно по такой же причине - знать что такое есть, что может и не трогать особо.

А зачем вам власть над кодом, это какие-то комплексы доминирования или практическая необходимость?

изучи MIX.

Вопрос: Стоит ли изучать C, или лучше стремиться к связке Assembler+C++?

1. Сначала немного истории ВТ, булева алгебра, системы исчисления - поймёшь почему.

2. Затем - емулятор (bochs) с DOS + книги Абель (Ассемблер) или Нортон (Ассемблер для IBM PC)

3. Затем - емулятор (qemu-arm) c линукс и пробуешь асм на арм.

4. Затем С. Пойдёт легко поскольку он просто высокоуровневый кроссплатформенный ассемблер.

5. Затем SICP + scheme, внимательно и без читов.

6. Выбирай любой ЯП.

Если собираешься нарушать последовательность или пытаться умничать и комбинировать - лучше сразу купи «PHP за 24 часа», по крайней мере вреда от тебя не будет.

С стоит изучать. Ассемблер - нет.

А gdb ? Или там переводчик встроили?

В универе изучал и асм и си. Могу сказать что после ассемблера си кажется просто намного удобнее но смысл тот же. И после асма уже как бы понимаешь что там процессор делает когда ты пишешь какойнибуть оператор условного перехода. Если хорошо разберешься с асмом то в си нужно будет выучить только синтаксис (ну и плюс там пару модных финтов узнать). А так в большинстве случаев работать с асмом на прямую это сильно трудоёмкий процесс. Кроме того что бы писать на асме нужно учитывать какой именно ассемблер(они тоже разные бывают) и для какой архитектуры. А вот Си один универсальный для любой платформы.

Универсального рецепта нет. Все, кто утверждают, что знают его, религиозники, обманщики и шарлотаны.

Просто реально нужна помощь людей, которые знают свою работу.

Тут их мало, хотя и есть, да.

из-за аллергии на анальные-зонды

Неужто уже всовывали? или один раз не ....рас. Ведь чтобы узнать есть ли аллергия - нужно правильно применить аллерген.

Вопрос: Стоит ли изучать C, или лучше стремиться к связке Assembler+C++?

Исключительно что-то одно.

Мак вообще не рассматриваю, из-за аллергии на анальные-зонды)))

Не беда! Зато, судя по тройному смайлику, рот рабочий.

Учи все три

Учи все 3 хотя бы поверхностно, а 1 или 2 нормально. Я бы выбрал С + асм.

Без дизассемблирования можно прекрасно обойтись. Многие всю жизнь без него живут.

В принципе так, как посоветовал iBliss (сомнения вызывает только пункт 3). А перед пунктом 6 почитай чего-нибудь про ООП. Лучше в связке с С++. Если, конечно, будешь работать с этой парадигмой.

C не трогай. Ассемблер только на почитать, чтобы понять как оно все работает, за ним С++.

максимально дающее власть над кодом

с этого места подробнее, о могущественный владыка

Пока так.

Калькулятор MK-61 и программирование полётов на Луне.

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

По поводу С vs Asm
позвольте привести мнение весьма продвинутого эксперта:

http://www.software-lab.de/doc64/README

The 64-bit version of PicoLisp is a complete rewrite of the 32-bit version.

While the 32-bit version was written in C, the 64-bit version is implemented in
a generic assembler, which in turn is written in PicoLisp.

Reasons for the Use of Assembly Language
----------------------------------------

Contrary to the common expectation: Runtime execution speed was not a primary
design decision factor. In general, pure code efficiency has not much influence
on the overall execution speed of an application program, as memory bandwidth
(and later I/O bandwidth) is the main bottleneck.

The reasons to choose assembly language (instead of C) were, in decreasing order
of importance:

1. Stack manipulations
Alignment to cell boundaries: To be able to directly express the desired
stack data structures (see «doc64/structures», e.g. «Apply frame»), a
better control over the stack (as compared to C) was required.

Indefinite pushs and pops: A Lisp interpreter operates on list structures
of unknown length all the time. The C version always required two passes,
the first to determine the length of the list to allocate the necessary
stack structures, and then the second to do the actual work. An assembly
version can simply push as many items as are encountered, and clean up the
stack with pop's and stack pointer arithmetics.

2. Alignments and memory layout control
Similar to the stack structures, there are also heap data structures that
can be directly expressed in assembly declarations (built at assembly
time), while a C implementation has to defer that to runtime.

Built-in functions (SUBRs) need to be aligned to to a multiple of 16+2,
reflecting the data type tag requirements, and thus allow direct jumps to
the SUBR code without further pointer arithmetic and masking, as is
necessary in the C version.

3. Multi-precision arithmetics (Carry-Flag)
The bignum functions demand an extensive use of CPU flags. Overflow and
carry/borrow have to emulated in C with awkward comparisons of signed
numbers.

4. Register allocation
A manual assembly implementation can probably handle register allocation
more flexibly, with minimal context saves and reduced stack space, and
multiple values can be returned from functions in registers. As mentioned
above, this has no measurable effect on execution speed, but the binary's
overall size is significantly reduced.

5. Return status register flags from functions
Functions can return condition codes directly. The callee does not need to
re-check returned values. Again, this has only a negligible impact on
performance.

6. Multiple function entry points
Some things can be handled more flexibly, and existing code may be easier
to re-use. This is on the same level as wild jumps within functions
('goto's), but acceptable in the context of an often-used but rarely
modified program like a Lisp kernel.

It would indeed be feasible to write only certain parts of the system in
assembly, and the rest in C. But this would be rather unsatisfactory. And it
gives a nice feeling to be independent of a heavy-weight C compiler.

Поддерживаю тезис о том чтобы последовательно пройти все этапы развития вычислительной техники.
Писать на асме сейчас глупо (в общем случае), но знать о его наличии и о том как работает процессор просто обязательно!