Станислав Макаров

Потому что указатель начинает указывать на следующий элемент той размерности, для которой указатель создавался. Сделаете unsigned char* - будет на размер char увеличиваться (1 скорее всего), unsigned long long* - на 8. void* скорее всего вообще не даст такой фокус провернуть (и правильно сделает).

Присоединяйтесь к open source проекту или начните свой большой проект. Разбивайте его на части, двигайтесь постепенно. Так, чтобы несколько часов работы - и уже какая-то фича, пусть и небольшая. Не обязательно делать прям ну очень большой проект, можно начать с чего-то простенького - todo-шка, простенький irc клиент, и так далее, и потом постепенно развивать. Если удастся найти что-то, что вам лично сейчас нужно, будет больше мотивации. Еще как вариант, посмотрите в backlog у вас на работе. Всегда есть какие-то большие, но на данный момент не приоритетные задачи. Попробуйте взять одну из таких задач и написать PoC в свободное время. Если получится хорошо, покажите начальству, так и С++ на свою работу протащите! Ну а вообще самый-самый крутой способ прокачать в чем-то скил - устроится все-таки на работу где это используется.

Я постараюсь подключить философию, примеры и "как если бы я говорил в баре с вами".

ЯП - это инструмент. Инструмент всегда взаимодействует с объектом и со средой. Соответственно, вам точно нужно что-то знать про объект и уметь пользоваться инструментом внутри среды, а это потащит дополнительные знания, назовем их "естественными" зависимостями. Насколько глубоко их нужно знать? Тут ответа не бывает: настолько, насколько нужно и хочется. Тут важен баланс и акцент. Если нет строгих параметров на уровне разума, нужно верить интуиции, потому что больше нечему. Для JS-программиста JSON/jQuery/AJAX - это естественные зависимости, их в любом случае не получится обойти. Даю зуб, что вам хватит вечера и немного гугла, чтобы стать чуть ли не LIKE A PRO в этом. Это все форматы хранения данных, либы, парадигмы. Это примерно как прочитать состав у шоколадки по сложности и входному порогу. Скорее всего, вас пугают сложные слова. Примерно как сказать "НАПРАВЛЕННЫЙ АЦИКЛИЧЕСКИЙ ГРАФ", и вы сразу знаете теорию графов, хотя с практической точки зрения суть настолько элементарна, что аж страшно, а вы будете долго прокрастинировать и искать что попроще.

Это что касается близких и неизбежных естественных зависимостей. Но есть и более далекие, но тем не менее все равно естественные, их знание позволяет развиваться, иметь более полную картину в голове. Вот есть гитарист, он может быть просто технарем. Есть гитарист-музыкант, который чувствует дорийский лад в блюзе. А есть гитарист-музыкант-звукорежиссер, который наконец-то понял, как надо жирно сводить гитары и теперь в симбиозе со звукарем. Кто из них самый крутой, очевидно.

Вы можете просто верстать (html/css) и игнорировать программирование в целом. Но естественная среда противится: вы уже (!) пишете на декларативном языке, неплохо было бы узнать об этом подробнее (о языках или даже о типизации), тем более, что крайне близко к вам находится интереснейший язык js, а там моментально вылезут проблемы связывания html и js, разные подходы к этому, целые парадигмы и фреймворки; и вот вам выпадает интересная задача по анимированию svg, вы курите мануал по нужной либе, читаете что-то про reflow/repaint, внезапно узнаете что-нибудь про селекторы. И через какое-то время, будучи все тем же верстальщиком, вы видите архитектурный косяк дизайна, который очень неудобно укладывается в используемые технологии, предлагаете его пофиксить и спасаете команду от факапа через месяц, когда какой-нибудь транзишн наложится на какой-нибудь position: fixed и еще и в Safari упадет анимация и только там, а тут и новая тудушка: "Переделать, нафиг, всю шапку, чтобы ок было". Что-то изменилось в мышлении и картина стала полнее. ВНЕЗАПНО вы уже и инженер, можно сказать, ЗП растет, все дела, рутины меньше стало.

Так вот, о инженерах. Можно выучить, например, Python за пару дней, там же отличный мануал. Но настоящий программист - это инженер, потому что вся суть в архитектуре, во взаимодействии объектов/компонентов и в том, как все это соотносится с задачей. Какой молоток взять, это уже без разницы, как состав на банке прочитать. То есть суть вашей работы заключается как раз в объекте и среде, а не в инструменте. Образно говоря, когда вы сидите в кафе, суть не в чашке чая, а в атмосфере и как вы себя в ней чувствуете, но при этом чашка чая нужна, чтобы заставить вас что-то делать и вписать тем в самым во взаимодействие со средой, поэтому придется научиться красиво пить чай.

Подведу тут черту: естественные зависимости - это норма, а суть в инжиниринге. Можно двигаться по зависимостям дальше. У вас есть интервал, где есть минимальный порог, ниже которого нельзя, и максимальный, где вы "мастер на все руки", что тоже плохо. Между минимальным и максимальным порогом можно двигаться. Взять те же сети: разворачиваете приложение, видите линуху, настраиваете сеть. Можно немного заморочиться и прочитать про основы маршрутизации, буквально 2 вечера, можно еще про сетевой стек в линукс, еще 2 вечера, и уже будет во много раз проще. Кроме того, возрастет культура в целом и если вы программист на бэке, то вам будет проще взаимодействовать с админами. Про OSPF, очевидно, читать не надо, важен баланс. Баланс - это понимание того, на что у вас акцент (вы программист? какой? фронт/бэк? насколько важны сети/ос? проектируете бд? верстаете? интересен ли прикладной кодинг под какую-то ос и так далее...) и насколько интересны естественные далекие зависимости выбранной области.

Так вот, теперь у нас есть естественные зависимости, инжиниринг и баланс между порогами. А не php/jquery/html/css.

Важно также отметить, что все очень быстро развивается сейчас, а это еще один аргумент, что привязываться к инструменту не стоит. Кто-то может сказать, мол, взять тот же js, программирование на нем - это целая парадигма, иной подход, свои фичи. Это так, но дело тут не в js, а в целом в динамичных/интерпретируемых языках.

Кстати, что касается SEO: с технической точки зрения это пара мануалов от гугла и не более того. Там сеошники наговорить могут много, с ними надо быть осторожнее :)

А теперь, собственно, выводы:

1) Вакансий крутых много, надо пробовать. Нужно только отличать близкие и необходимые естественные зависимости от мастера на все руки. Я считаю, что мастером на все руки нужно поработать хоть однажды, чтобы просто понять, почему это плохо. Но зависимости будут всегда, и это норма. Вы перечислили слишком радикально, конечно.
2) Себя пилить под вакансию не нужно. Нужно просто идти туда, где интересно, всегда стараться быть инженером и не убить в себе искусство (то есть не бояться делать так, как кажется правильно, чтобы либо убедиться в правоте, либо ошибиться и стать круче).
3) Не нужно думать в стиле "а что если завтра рубионреилс развалится, комьюнити разойдется, вакансий не будет, что я буду делать". Вы же инженер. У вас опыт в проектировании IT-систем, перейти на что-то смежное, если будет понятно, что технология умирает, не составит труда.
4) По естественным зависимостям нужно двигаться по мере интереса, вы станете от этого только лучше.

Это, конечно, если вам действительно все это интересно. Все это области, очень близкие к искусству, и тут надо любить все это делать.

Никакие.

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

Вообще, в области server / desktop / mobile очень сложно уйти далеко без, как минимум, следующего:

• Объектно-ориентированное программирование и проектирование — ведь код не должен быть говном
  
• Параллельное программирование — ведь делать нужно много и быстро, а у нас уже 10 лет как многоядерные машины есть
  
• Сети — ведь нельзя жить без интернета
  
• Базы данных — ведь данные надо где-то хранить, и хранить надёжно
  

hardware не комментирую, но там ещё хардкорнее.

Собственно, для программиста не столько важно знать какой-либо конкретный ЯП, а важно владеть технологиями разработки. ЯП, конечно, входит в это множество, но им оно совсем не ограничивается.

Вообще .Net давно работает на Nix*. Просто имплементация стандарта не поддерживалась MS официально.
Вот тут списочек : Mono Software Showcase.

Сейчас MS меняет свою политику по части инструментов и тд. и будет официально поддерживать свою реализацию платформы на Win, Mac и Linux.
Вот страничка CoreFx - https://github.com/dotnet/corefx. Как видите билды на Linux уже проходят.
А вот CoreClr - https://github.com/dotnet/coreclr. Там уже и на Маке подняли билды.

А нужно многим. Например, я бы рад сделать продукты кроссплатформенными, но от Java глаза вытекают(особенно после C#6), Scala - слишком нишевая, интерпретируемые я не люблю(производительность, нет статической типизации и тд- просто личное предпочтение). Вот и остается только C#/.Net. Ну и не я один такой)

Если откинуть хэйтинг МС отдельными личностями - то ИМХО C#/.Net сейчас наиболее перспективный и интересный тулсет.

#include — как ни странно.

Вы так и не поняли такой вещи, как «единица компиляции». Дело в том, что в Си c-файлы компилируются независимо друг от друга (в единую программу всё собирает линкер). А чтобы сказать «оно есть, только в другой единице компиляции», используют прототипы и extern’ы.

А если вы хотите просто внести код в ту же единицу компиляции, просто пишите его в хедере, да и всё. Только в большинстве компиляторов это исключает предкомпилированные хедеры — а ТАКИЕ хедеры вам предкомпилировать, скорее всего, и не нужно.

<брюзга mode on>
Не создают кода (а значит, в традиционной системе с кучей единиц компиляции находится именно в хедерах)
• extern и прототипы
• inline
• не до конца специфицированные шаблоны
• static-поля в классе (но потом это static-поле придётся повторить в какой-нибудь одной единице компиляции)
• может, ещё что-то, только я забыл…
<брюзга mode off>

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

В C++ это будет вызов метода method2() у того, что вернул method1().

А вы что хотите? Чтобы method2() вызывался у object? тогда метод1 должен возвращать ссылку на *this.

#include <iostream>
#include <stdexcept>
#include <iomanip>
using namespace std;


struct vantuz
{
   vantuz& push();
   vantuz& pull();
   vantuz();
private:
   bool pushed;
};

vantuz::vantuz():pushed(false)
{
}

vantuz& vantuz::push()
{
        if(pushed)
        {
              throw logic_error("already pushed!");
        }
        pushed=!pushed;
        cout<<"push! ";
        return *this;
}

vantuz& vantuz::pull()
{
    pushed=!pushed;
    if(pushed)
    {
          throw logic_error("already pulled!");
    }
   cout<<"pull! ";
   return *this;
}

int main()
{
   try
   {
      vantuz v;
      v.push().pull().push().pull().push().pull().push().push();
   }
   catch(logic_error& ex)
   {
   	  cout<<endl<<setw(20)<<setfill('@')<<' '<<"Runtime error!"<<setw(20)<<setfill('@')<<' '<<endl<<ex.what()<<endl;
   	  throw;
   }
   return 0;
}

Потыкать на ideone

Расклад примерно такой. Пусть n -- длина числа, т.е. обычный перебор работает за 2^{c * n}.

1) Вероятностный тест Рабина-Миллера можно реализовать за O(k n^2 log n), где k -- число попыток. Вероятность ложноположительной ошибки 4^-k. При k=100 это значение настолько безумно мало, что скорее в вашей программе найдется критический баг, процессор сделает ошибку в вычислениях и взломщик выиграет в лотерею и все это одновременно, чем число окажется составным.

2) Детерминированный AKS (en.wikipedia.org/wiki/AKS_primality_test). Работает за O(n^{6 + eps}). Интересен скорее теоретически.

3) Эллиптический тест на простоту (en.wikipedia.org/wiki/Elliptic_curve_primality). Эмпирически работает за O(n^5). Интересен тем, что в случае успеха возвращает сертификат простоты.

Немного теории