в C++ можно не писать return в методе, который согласно сигнатуре должен что-то возвращать
Меж тем у компилятора (gcc по крайней мере) есть ключик -Werror=return-type, превращающий соответствующий warning в полноценный error. Очень рекомендую.
Линукс сложно проапгрейдить до состояния, когда вообще ничего не запускается. А вот Мелкософт некоторое время назад умудрился выпустить обновление на Вин10, которое стабильно вызывало БСОД при загрузке системы.
Учитывая, что в Линуксе у рута всегда есть неприкосновенный резерв места на диске, все запущенные из-под него службы продолжат работать в штатном режиме. А вот котикам не повезет, это да.
А, Вы наверное подумали, что я предлагаю от требований отказаться? Не-не-не, требования — это мастхэв номер 1, и спорить даже не буду. :) Нет требований — нет проекта.
Я имею ввиду, что юзкейсы (с макетами или хотябы без них) очень сильно помогают утрясти собственно сами требования. Без низ риск накосячить гораздо выше. Можно сказать, они как раз и помогают «продать» требования заказчику, так как показывают ему, как будет работать еще не разработанный продукт.
Требование — это не функция системы, а описание задачи или проблемы, которую хочет решить конкретный человек.
Вот мне лично эта фраза прям понравилась. Мне кажется, что написать требования и не написать юзкейсы — зря потратить время. Юзкейсы обязательно надо показать заказчику, чтобы он прослезился и сказал: «Да, именно так я и хочу чтобы оно работало».
Таки да, забыл выключить. Теперь для switch-а результат «superposition» и bool сравнивается как int, с 1 и 0, для if-ов по прежнему true. Да и ассемблерный код для них все равно одинаковый. В общем-то логично, что gcc if(t[0]) и if(t[0]==true) одинаково воспринимает, так же как и if(!t[0]) и if(t[0]==false).
GCC для примера с if-ами вообще странный код генерирует. Во-первых, он выкидывает напрочь ветку default из switch и выводит false, потому что в первом case-е сравнивает булевскую переменную с 1, когда не совпадает (а там же мусор, так что не совпадает) — сразу переходит на cout<<«false\n»;. А в обоих ифах gcc тупо сравнивает булевскую переменную с 0 и довольный выводит true. Ассемблерный код для if(t[0]) и if(t[0]==true) абсолютно одинаковый:
0x80486e8 <+0x0048> 80 3e 00 cmpb $0x0,(%esi)
0x80486eb <+0x004b> 75 43 jne 0x8048730 <main()+144>
Подозреваю, что MVC для switch-а честно сравнивает переменную сначала с 1, потом с 0 и в результате попадает в default.
А вот при явном присвоении «bool var=10;» gcc еще при компиляции преобразует 10 в true (то есть в 1), что в отладке видно.
Ключ -s команды read предотвращает отображение на экране данных, вводимых с клавиатуры. На самом деле, данные выводятся, но команда read делает цвет текста таким же, как цвет фона.
Наверное, все-таки вообще не выводятся. Иначе они занимали бы место на экране и во многих терминалах их можно было бы выделить мышкой.
По поводу Message и Mailer пришлось перечитать три раза, прежде чем я въехал. Слава C++ и указателям! :)
Если честно, упоминание php и ракет вызывает когнитивный диссонанс. А тут еще и фреймворки. Как раз если писать ПО для ракеты, широко распространенные фреймворки использовать нельзя ни в коем случае. Тут лучше подходит самопальный «бронированный» велосипед, хотя это и дороже. Но в таких случаях на спичках не экономят.
Я, может, ошибаюсь, но я не заметил в статье самый простой вариант для Linux-Linux. После установки иксов запускаем ssh с ключом -X и наслаждаемся окошками удаленных GUI-приложений у себя в системе. Это, конечно, для случая, когда не нужен именно рабочий стол.
Дабы минимизировать временные затраты на саму функцию получения времени, вызываю два раза clock_gettime с CLOCK_PROCESS_CPUTIME_ID в начале и в конце, пересчет в секунды делаю уже потом. Если есть возможность зафиксировать частоту процессора, использую rdtsc инструкцию.
Мне кажется, что проблема тут в отсутствии взаимопонимания, даже скорее взаимопроникновения знаний. Менеджер, работающий в контакте с командой программистов, обязательно должен обладать неким базовым набором знаний в программной инженерии, иначе он не сможет понять причины возникновения тех рисков, о которых ему будут говорить разработчики. А значит, он от них просто отмахнется. С другой стороны, разработчики должны понимать, для каких целей они делают ПО, кто и как им будет пользоваться, и в какую сторону оно предположительно будет развиваться (если вообще будет).
В конечном итоге, менеджер и команда разработчиков должны ДОГОВАРИВАТЬСЯ друг с другом, и не ударяться в крайности, а принимать компромиссные решения, которые позволят не только снять сливки сейчас, но и продолжить это делать в течении длительного времени с минимальными затратами.
Меж тем у компилятора (gcc по крайней мере) есть ключик -Werror=return-type, превращающий соответствующий warning в полноценный error. Очень рекомендую.
Кстати, компилятор люто паникует.
Так что, не забывайте посматривать на ворнинги компилятора.
Еще в линуксовых шеллах во всех.
Вот мне лично эта фраза прям понравилась. Мне кажется, что написать требования и не написать юзкейсы — зря потратить время. Юзкейсы обязательно надо показать заказчику, чтобы он прослезился и сказал: «Да, именно так я и хочу чтобы оно работало».
0x80486e8 <+0x0048> 80 3e 00 cmpb $0x0,(%esi)
0x80486eb <+0x004b> 75 43 jne 0x8048730 <main()+144>
Подозреваю, что MVC для switch-а честно сравнивает переменную сначала с 1, потом с 0 и в результате попадает в default.
А вот при явном присвоении «bool var=10;» gcc еще при компиляции преобразует 10 в true (то есть в 1), что в отладке видно.
Наверное, все-таки вообще не выводятся. Иначе они занимали бы место на экране и во многих терминалах их можно было бы выделить мышкой.
Если честно, упоминание php и ракет вызывает когнитивный диссонанс. А тут еще и фреймворки. Как раз если писать ПО для ракеты, широко распространенные фреймворки использовать нельзя ни в коем случае. Тут лучше подходит самопальный «бронированный» велосипед, хотя это и дороже. Но в таких случаях на спичках не экономят.
В конечном итоге, менеджер и команда разработчиков должны ДОГОВАРИВАТЬСЯ друг с другом, и не ударяться в крайности, а принимать компромиссные решения, которые позволят не только снять сливки сейчас, но и продолжить это делать в течении длительного времени с минимальными затратами.