>В случае если собираетесь заниматься роботами и автоматизацией производства (не учет и контроль, а именно автоматизированным управлением процессами), подтяните такие разделы:
-Линейная алгебра
-Дифференциальное и интегральное исчисление (интегралы руками брать не обязательно)
-Теория вероятностей

-Теория линейных систем

В списке очень не хватает:
— Мехатроника (в особенности, теория машин и механизмов, теоретическая механика)
— Теория автоматических ситем управления (ТАУ) [continuous & discrete]
— Современная ТАУ (в частности, робастные и нелинейные системы управления, хотя, по — хорошему, надо бы все помотреть хоч краем глаза)
— Цифровая обработка сигналов
— Искусственный интеллект
— Машинное обучение
— Машинное зрение
— Визуализация
— Численные методы

— Ну еще статистика не помеашала бы (т.к. не всегда в рамках теор вера о ней упоминают)

Все зависит от твоей специализации. ХОчешь быть формошлепом — она тебе не нужна. Хочешь чего-то большего, то нужна. Области, что надо учить, также зависят тоже от конретного нарпавления работы, ибо всю математику познать не дано. И учитывай, то, что выучишь сейчас надо постоянно использовать и актуализировать. Знания-то устаревают и забываюцца. Скажем, год не работал со звуком. НЕдавно была задача поднять или опустить голосу человека на 1-7 тонов, очень долго пришщлось вспоминать, хотя в прошлом году еще все от зубов отскакивало.

С++ не нужен. Это про Обжектив и С++:

www.developers.org.ua/...ic/4766/#146511

С нужен в обязательном порядке на уровне структур, работы с памятью, указателей, кастования, колбеки и т.п. ТАкже, неплохо бы освежить разные новомодные ключевые слова, типа inline, которые умеет пользовать GCC.

C++ нужен только, если перецца в геймдев. В описаниях вакансии пишут С/С++/Objective-C зачастую потоиму, что сидит в компании безграмотное кодло, ибо редко где Objective-C++ используецца.

>Например, под с# можно сразу делать формочки и не знать, что такое ООП и зачем нужны интерфейсы и т.д., а потом уже по мере необходимости учить что надо.

Будешь неконкурентоспособен. Второе, там необходимость в базовых знаниях есть сразу же, т.к. язык объектно-ориентированный, но имеющий все возможности С. БОлее того, часть стандартный библиотеки использует не обжектив, а чистый С (например, core foundation).

Эмм... Вообще-то, сырцы дарвина где-то валяюцца у эппла.

objc_msgsend — это то, что скрываецца под синтаксисом вызова любого метоад и не связан с IMP-cache никак. Про имп кэш написано ниже вообще-то.

Тут тоже можно инлайнить, но от этого теряем прелести messaging, хотя, в определенных местах это и разумно.

Так вот ,оверхед от имп кэш на самом мюллере описан так (замечу, что у эша сразу написано, что имп кэш быстрее вызова виртуальной функции С++):

Obj-C method calls aren’t slow, but they are slower than plain C calls. Outside of inline code, the fastest invocations are the static C function (or any function that isn’t crossing shared library boundaries) and equally fast if not even a smidgen faster message implementations (IMP)s.

И собсно, то, что я и говорил, подтверждает и приведенный тобой источник, что вызовы методов ненамного медленнее С++, а если сделать пару финтов ушами, то почти такие же по скорости, а иногда и быстрее (то, о чем я не упоминал ,т.к. зачастую добивацца этого не имеет смысла).

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

Какие именно?

И да, мы говорим о среднем по рынку или потолке?

Я — лох и в этом уже признался, не? И да, я их отличаю, но настолько привык сокращать фортран до форта, что тут попался.

Это ужасно. Я представляю, насколько все-таки тяжело формошлепам освобождать память вручную. Неудивителньо после этого, что оне достижением считаеют знакомство с очередным фреймворком посредством прочтения его доки.

Угу. Лучше уж фиксить баги от того, что формочку нашлепал неверно или доку не дочитал. Да-да.

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

А синтаксис шарпа такой же фиговый, как и синтаксис С++. Абсолютно нечитаемая хрень. К тому же, те же самые болезни, что и с ооп парадигмой (которая недооп), что в нем наличествует. Лень повторяцца, читайте в треде ниже мой спор с реалити хакером по читаемости и и с ним же и грезом по оопшности.

Ну дык тебе то, что я пишу не нравицца? Кто тебе мешает также делать это целенаправленно? Религия?

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

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

>Опционально можешь называть методы по разному и добавлять коментарии о параметрах — дело вкуса.

Эмм... Я, наверное, не правильно понял, но makeCursorWithNamespaceDetailsIndexDetailsNumberIndexDetailsInDirectionShouldUseFRVSpec( _d, _d->idxNo( (IndexDetails&) _id), _id, _bounds, _direction, useFRVSpec) читаемости коду не добавит. Это не только в С++ проблема, как по мне, т.к. после нотации, подобной той, что я привел, читать голые названия функций у которых еще и не интуитивные названия переменных ну очень тяжело. Очень уж болезненный синтаксис, хоть и лаконичный.

>Вычисления в шаблонах это пример чего-то там головного мозга, типа дали обезьяне гранату с большим количеством степеней свободы. Я так считаю.

Тогда этот вопрос снимаецца, т.к. именно чтение подобного кода у меня всегда вызывало вопросы и непонимание. Собсно, яркий тому пример — топ про оптимизацию в С++, где я не понял ничерта, а парсер, сожрав теги, еще и добавил сложностей в понимании.

Я тусуюсь. И я никогда не скрывал, в каком городе я родился. Даже тут сегодня несколько раз принимал благодарности от жителей Украины. Я не заполняю хоть чутку профил ьна сиим ресурсе по религиозным причинам, ибо никогда не стеснялся признавать, что я из Донецка.

>Да и просто появился повод тролля троллянуть — он же мимо не прошел, контекстуал эдакий, сразу подсекся.

Teh drama. Мне развлекацца, как с горы катицца. Дык, еще и купаюсь в лучах твоего внимания, о человек, которого записывать в избирательные списки..

Почему? Почему у меня это получаецца?

Если это принять, то нет места дял конфликта. Определенно, не метод посетителей сего треда.

Там ведь не только и не столько о вилке речь идет.

>Не читать его записи можно только в том случае, если, когда видишь ник trimm, перескакивать на следующий пост или в другую ветвь, где его нет.

Очевидный фикс же.

Угу. Как я уже сказал, с парой финтов ушами работает почти также (пара финтов = 5-10 строк кода). Поясняю почему: на критических по производительности участках мы делаем полноценную посылку сообщения только один раз, а в остальное время — IMP-cached message send. Ощутите разницу, как грицца, посему и сказано было, что таки Обжектив приближаецца к С++.

И да, мы так спорим с вами про быстродействие, но изначально я взъелся не на С++ в этом контексте.

Я не знаю, почему ты говоришь о продвинутых техниках. Я речи о них не вел.

Первое, что бьет по глазам:

BtreeCursor* BtreeCursor::make(NamespaceDetails *_d, const IndexDetails& _id, const shared_ptr< FieldRangeVector > &_bounds, int _direction, bool useFRVSpec )

BtreeCursor* BtreeCursor::make(NamespaceDetails *_d, const IndexDetails& _id, const BSONObj &startKey, const BSONObj &endKey, bool endKeyInclusive, int direction)

BtreeCursor* BtreeCursor::make(NamespaceDetails *_d, int _idxNo, const IndexDetails& _id, const BSONObj &startKey, const BSONObj &endKey, bool endKeyInclusive, int direction)

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

Посмотрим на вызов из самого кода:

make( _d, _d->idxNo( (IndexDetails&) _id), _id, _bounds, _direction, useFRVSpec );

Все замечательно, только непонятно, что они жрут на входе у кого конкретно вызываецца этот метод, если не лезть в описание функции и включать подсказку. Самое главное, я далеко не сразу нашел, где этот метод и какой именно из нескольких одинаковых по имени методов вызываецца. Зато лаконично. Это я еще не прошелся по именованию переменных, в котором черт ногу сломит.

Сравним читаемость с Обжективом, который более многословен (не знаю, статичен ли мейк, считаем, что таки статичен):
[BtreeCursor makeCursorWithNamespaceDetails:_d
withIndexDetailsNumber:[_d indexDetailsNumberForIndex:_id]
withIndexDetails:_id
inDirection: _direction
shouldUseFRVSpec:useFRVSpec];

Многословен? Да. Читаем? Да. Именование оставил то же, что и в оригинале, хотя, такое именование в обжетиве недопустимо.

И да, в данном шаблоне нет рекурсивного подсчета и чего-то подобного, что меня заставляло вешацца всегда. Если в обещм, пример приведенный вами уже намного более читаем, но, все-таки, недостаточно из — за особенностей синтаксиса С++. Но ,в нем нет и специальной шаблонной магии ,если я правильно это понимаю.