Евгений Шатунов

Это очень не умно, спрашивать у других о том, что для самого себя проще и удобнее. Особенно критично это для плюсов. Вот из чего я исхожу.

C++ - свободный язык, если вы хотите произвести на свет новую платформу, и при этом хотите, чтобы уже написанные 100500 программных продуктов на нем работали, вы просто производите свой компилятор для C++. С Ide ситуация схожая.

Что-то уровня десятков тысяч строк, комфортно можно написать в любой IDE. Но когда размер становится больше, или нужно использовать какой-то специфический пайплан разработки, только тогда становится понятно, зачем yet another IDE.

На самом деле, все зависит от количества составляющих программного проекта, и как это все дело собирается.

Qt Creator создана для удобства работы с Qt, особенно с точки зрения скрытия сложности сборки. Например, для VS лишь относительно недавно они родили на свет приемлемый плагин, который не заставляет добавлять файлы meta object compiler для каждой сборки проекта вручную. Но всё ещё осталось, мягко говоря, все остальное: WYSIWYG редакторы для файлов ресурсов, которые не всегда корректно работают, редактор для быстрого формошлёпства, удобная работа со старыми версиями qt, производительности плагина, и прочее и прочее. С qt работать из других qt стоит лишь тогда, если ваша система сборки не будет меняться чаще раза в N лет, иначе лишние траты на перенастройку сборки.

Если что-то коммерческое собирается для Windows не на MSBuild + VC++, то могу пожелать счастливой отладки и напомнить, что спасение утопающих - дело рук самих утопающих.

Eclipse нужен в случаях когда нельзя применять коммерческое ПО в ходе разработки. Или, если вы пишете про специфичную или открытую платформу, потому что как правило, в таких случаях владельцы платформы IDE не предоставляют по ряду причин. Тут на помощь приходит всемирно известный конструктор для IDE - Eclipse. Ещё его можно рассматривать в случаях, когда вы оптимизируете процесс разработки для себя. Хотя, этим заниматься лучше всего на Vim, Emacs. Насчёт последних - если кодовая база за миллионы строк, что выбора может не быть, но скорее всего, большинства а разработчиков эта проблема не касается.

CLion нужен для тех, кто привык к другим IDEшкам от jetbrains. Хорошие, удобные, потому что коммерческие, постоянное развитие. На stepik можно решить тяжёлые задачи и получить лицензию на несколько месяцев, персональную. Хотя многие рефакторинги ещё не работают.

Из ide ещё упоминают netbeans, а также многие редакторы, типа gedit, vs cide, geany и прочие.

Если опыта разработки нет, то нужно начинать с geany. Потом переходить, например, на vs code. А уже потом пытаться что-то делать в IDE и делать проекты для сборки на разных платформах, например, с помощью cmake. Дело в том, что нужно знать, что делает при каждом чихе IDE, и самый органичный способ это сделать - наращивать сложность пайплацна разработки постепенно: сначала проекты на сотни строк, потом добавляем статический анализ, автоформатирование, тесты, git, управление сборкой и CI/CD. К тому же, это коррелирует с основным принципом C++ - "я не плачу, за то, что не использую", т.е. время на лишнюю возню из-за узкой специализации IDE, либо недостаточной специализации - оно не тратится. Именно исходя из этого, Евгений Шатунов вас спросил о вашей задаче, чтобы посоветовать что-то дельное.

Давным давно, на диком западе пользовались не очень безопасными револьверами. Нормального предохранителя не было, заряжать револьвер - слишком долго. Поэтому ковбои часто могли ходить с заряженными револьверами. А там было несложно неудачно дернуться, и собственно выстрелить себе в ногу.

Любой инструмент, которым нужно пользоваться аккуратно, может привести к тому, что процесс упадет, возможно даже поломав другие процессы вплоть до синего экрана, то есть "выстрелишь себе в ногу".
А с/с++ достаточно низкоуровневый язык, в котором нужно о многом думать.
Забыл выделить память под переменную - выстрелил в ногу. Забыл освободить память - утечка накопилась - выстрелил в ногу. Перепутал указатель с указателем на указатель - ...

В более современных языках работать проще, многое за тебя уже продумано и автоматизировано (garbage collector, например)

С clon все в принципе нормально. Можно конечно добавить std::move, но проблема не в этом.
Проблема в том, что у тебя массив arr размером length - 1, а temp - length. А в clon() ты пытаешься копировать length элементов из arr, поэтому происходит выход за пределы массива.
В PushBack делай инкремент length, только после того как вызовешь clon первый раз, но до второго вызова.

Жаль немецкий убрал, было забавно :-) Но так гораздо привычней и понятней.

Процессор обязательно Интел (Опыт в программировании с АМД у меня печальный)

Ryzen сейчас крайне хорош, да ещё и жор меньше, чем у интела.

По требованиям - нашёл вот такие варианты:
HP Pavilion 15-ec1090ur
Lenovo Legion 5 15IMH6
ASUS Vivobook Pro 15 OLED K3500PC-L1012T
Acer Swift X SFX14-41G- R3N5

Целую часть можно получить с помощью floor(v)
Дробную: (v - floor(v))
Для сортировки используйте стандартный sort.

Кстати, отсортировать вы можете массив (он у вас уже есть в памяти), когда говорят про поток, то это нечто потенциально бесконечное, порции данных из потока вы получаете частями и обрабатываете их.
Соответственно, если у вас действительно поток, то надо строить из его данных дерево. Для этого можно использовать стандартный map. Данные будут укладываться в дерево по мере поступления с одновременной сортировкой. Получить из дерева отсортированный список можно просто обходом дерева с помощью итератора.
Данные в дереве сортируются по ключу. Для ключа можно использовать примерно такую конструкцию: floor(v) + (1 - (v - floor(v)))

Потому что вы даже вывод не освоили. Должно быть printf("%d\n", a);

Это нормальная практика. Например, ваш браузер скорее всего именно таким инструментом пользуется (если он на хромиуме основан).

Используя Кресты, стоит использовать и их удобства.

std::vector< std::vector< int > > a(rowCount, std::vector< int >(colCount, 0));
void average (std::vector< std::vector< int > > &a){

Так вы не нарветесь на промахи в индексах массива, например. Если умеючи.

А в вашем коде int[][], конечно, не может самопроизвольно превратиться в int*

ZDoom

Попробуйте __pretty_function__ в gcc и __FUNCSIG__ в visual studio.

В откомпилированном коде нет никаких названий классов.
В С++ нет рефлексии. И не надо, кстати.
Проверить, что класс является MyBeautifulClass или его наследником, можно при помощи dynamic_cast. А если вам нужно другое - берите другой язык и не навлекайте на себя гнев св. Барбары.

Используйте memcopy. Копируете из адреса дабловой переменной в адрес интовой.

Трюки с union и реинтерпритацей указателей довольно опасны.

Если внезапно использовать что то редкое и не следующее стандарту, то можно наткнутся что NULL не равен нулю.

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

А то можно писать и int i = false.

NULL - служебный дефайн, который есть, в частности, в венде.

Общей практикой является int i = 0; Хотя бы потому, что так короче.

Проблема в другом. В int.
В большинстве языков, int - это 32 бита со знаком, то есть, два гигабайта. В современных же системах памяти - десятки-сотни-тысячи гигабайт, а программы обрабатывают разного рода бигдату и ML. Так что индексация массива интами может легко выйти трудноуловимыми багами.

Поэтому правильно писать for(size_t i = 0; ..

Выкладывание игры в Google Play вообще никак не зависит от того, на чем она написана.
Как это делается - хорошо знает, внезапно, Гугль ;)
Хочется готовой сборки бандлов - бесплатная Android Studio в помощь.
Хотя даже интересно, на каком же движке вы написали игру на С++ под Андроид, но без проекта сборки его в бандл.

1. typename в данном случае нужен компилятору только как подсказка от разработчика, что последующий идентификатор (т.е. std::stack<T>::container_type::iterator) - это действительно имя типа. Подсказка нужна потому, что этот typedef вероятно находится также в шаблоне, и мы ещё не знаем, во что конкретно инстанциируется шаблон std::stack (в этом случае говорят, что container_type "is dependent on a template-parameter" - пока не инстанциируем std::stack, не узнаем).

2. Member-тип container_type эквивалентен типу нижележащего контейнера (т.к. std::stack - это адаптер под интерфейс стека, а не реальный контейнер, реальный контейнер для хранения вы выбираете вторым параметром шаблона, по-умолчанию это std::deque).

3. Вот у std::deque<T> итератор действительно есть.