Да, в примере 1 правила 2 через nread ничего не вернётся. Поторопился. Я как увидел, что в аргумент функции пишется адрес локальной переменной, у меня забрало упало.
Вообще-то я писал про время компиляции, а не про скорость работы. А для того, что бы откомпилировать std::accumulate, компилятору придётся сделать некий объём дополнительной работы по анализу шаблонов и пр.
Есть некоторые сомнения в качестве исходной статьи. Автор взял список С++ Core Guidelines и, на мой взгляд неудачно, откомментировал.
Правило 1. Пример с циклом не показателен. Во-первых, первый пример абсолютно ясен, если вы сколько-нибудь долго пишете на C/C++. Во-вторых, время компиляции второго примера будет чуть больше (умножим на 100500 таких «циклов» в большом проекте). Кстати, какого типа будет sum во втором примере? — ага, double.
«Никаких сырых циклов» — вообще бред. Скорее всего цитата просто выдернута из контекста.
Правило 2. Результат работы функций read1 и read2 будут различны. Первая считывает в каждый массив char ровно по maxstring символов (за исключением последнего куска данных), включая пробельные символы и переводы строк. Концевой '\0' в массивы не добавляется. Вторая разбивает входные данные на строки по разделителям (пробельные символы и концы строк по умолчанию), которые в выходные данные не попадают.
Кроме того, в первой функции в параметре nread возвращается адрес локальной переменной. Это к слову о квалификации автора как программиста C++.
И «никаких сырых циклов»!
Правило 5. Спорно. Зависит как от конкретного кода, так и от размера экрана. И совершенно не факт, что определив новые логические сущности, разделив «на функции и объекты с методами», вы не получите двукратное увеличение объёма кода, разделённого на несколько файлов, с оверхедом в виде вызова функций и методов.
Кстати, это уже к автору перевода, термин «область видимости» имеет несколько другую семантику, если имеется ввиду язык программирования. Правило 5 лучше бы звучало как «пишите по возможности небольшие функции».
Правило 6. Оператор if (result.second) не скомпилируется в обоих случаях, поскольку имеет тип std::string, который неявно не приводится к bool.
Шлак. Унылое заумствование по поводу достаточно очевидных вещей. Полезной информации — 10%, остальное — вода. Похоже на выступление начальника отдела разработки перед топ-менеджерами, когда необходимо выбить финансирование.
Кстати, кроме процедурного программирования и ООП существуют и другие парадигмы программирования. Если уж рефакторить, то по-большому.
большое количество синтаксических стилей, и синтаксис там можно сильно изменять… у операторов настраивается приоритет, запросто можно ввести свою мудрёную нотацию
А есть ли это хорошо?
Wolfram language был спроектирован таким, видимо, исходя из каких-то достаточно веских оснований. Для универсального языка программирования такие возможности скорее минус, чем плюс. Вот, кстати, Ruby: одно и то же действие можно описать 2-3 разными синтаксическими конструкциями. Типа «кто как привык, пусть так и пишет». Но такой подход приводит к тому, что при разборе чужого кода надо помнить эти 2-3 вида конструкций. И это уже не хорошо.
Люди разрабатывают code style для того, что бы ограничить разнообразие использования пробелов, отступов, переводов строк. А тут полная «демократия» на уровне конструкций языка.
Во-первых, слишком много воды. Всю полезную информацию можно было уместить в пяток абзацев и десяток ссылок.
Во-вторых, «изучить я зык программирования» в статье понимается как «понять идеи, на которых основан язык» + «изучить синтаксис». Это — как правило, не проблема. Но что бы практически использовать язык, необходимо достаточно свободно ориентироваться в «стандартной библиотеке» (а она в том или ином виде всегда есть) и иметь навык комбинирования возмножностей, предоставляемых языком и стандартной библиотекой, для получения оптимальных результатов. А это уже совсем другие затраты сил и времени.
Хотя с основной мыслью статьи о полезности изучения базовых принципов, на которых строятся языки программирования, полностью согласен. Глупо было бы спорить.
С нероссийскими работодателями другие проблемы (кроме знания английского). Например, как решается вопрос с отчислениями в ПФР, налоговую, медстрах? Как получить НДФЛ2? (Если, конечно, это не российское представительство компании.) Кроме того, у нероссийского работодателя часто бывает подход: «Русский? — заткнись, говно, и выполняй, что сказано!». Хотя «их» специалисты, порой такие специалисты… Да и вообще неприятно такое «общение». (Не говорю про всех нероссийских работодателей, но сам сталкивалася.)
Про специализацию. Можно, конечно, в критических ситуациях наступить себе на горло и заниматься тем, что не нравится: писать на Битриксе, разрабатывать лохотрон на PHP, ковырять фронтэнд… Я не говорю, что это в принципе плохо (кроме лохотрона, конечно), просто кому-то нравится фронтэнд, а кому-то писать драйвера устройств на С. Всё-таки работа должна приносить и моральное удовлетворение.
Требования по текущим вакансиям с «Моего Круга» (C++, удалённая работа):
Python • Java • C++
C++ • Git • Gnu compiler collection • C++ stl • C++ boost • Nginx • Ubuntu • Cmake
C++ • Go • Python • Java
C++ • Алгоритмы и структуры данных • Разработка программного обеспечения • Разработка игр • Assembler • Прикладная математика • Программирование микроконтроллеров • Matlab • Opencv
Машинное обучение • Python • C++ • Matlab
Linux • C# • C++ • Fpga • Системное программирование • Программирование микроконтроллеров
C# • Java • C++ • Объектно-ориентированный дизайн
Это вы называете «стандартными требованиями»?
Это я ещё не проваливался внутрь объявлений. Там обычно более развёрнутый список требований к соискателю.
Обычную работу найти сложно, а удалённую работу — сложно вдвойне. А если ваш возраст перевалил за 40, то можно умножать ещё на 1.5 за каждые 10 лишних лет.
Попробуйте посмотреть какие вакансии есть, например, на ресурсе, дружественном Хабру, «Мой круг» для разработчика на С++ в «удалённом режиме». Во-первых, вакансий очень немного (хотя вроде как С++ стабильно держит 2-3-4 место по востребованности). Во-вторых, либо требуестя дополнительно знание ещё большого количества чего-то (других языков, фреймворков, библиотек, технологий и пр.), либо это достаточно узкоспециализированная сфера, которую надо тоже знать.
Вы можете сказать, что если не знаешь «других языков, фреймворков, библиотек, технологий и пр.», то кто же виноват? Но всего знать нельзя. Поэтому ещё нужно что бы область знаний соискателя совпадала с требованиями работодателя. И проблема не в том, что " больше никуда развиваться не хочет", а в том, что работодателю нужно здесь и сейчас. Ждать месяц-два-три, пока вы куда-то там разовьётесь, ни кто не будет.
Возможно вашим знакомым повезло. Или они не хотят огорчать вас информацией о реальном положении дел. Или все они гуру в своей области. Или сугубо нетребовательны к уровню предлагаемой зарплаты. Вариантов много. Но с удалёнкой у нас пока объективно плохо.
Для справки. Сейчас посмотрел вакансии на «Мой круг»:
2. До 10 элементов, скорее всего, можно не заморачиваться с бинарным поиском.
3. Откуда два прохода и дополнительная память?
for (size_t i = 1; i < ARR_LENGTH; ++i) {
if (arr[i] > arr[i-1] && arr[i] < arr[i+1])
std::cout << arr[i] << ' ';
}
Ну ещё добавить проверку, что длина массива больше 3. И вроде как всё. Или я что-то упустил?
5. Из контекста русского перевода как раз вообще ничего такого не следует. А вот в английском варианте, который сейчас добавили, написано: «being absent for more than once or being late for 3 times continuously». Здесь уже примеры выглядят логично: они поясняют, что подряд два опоздания и прогул тоже не допускаются. При переводе пропустили всего одно слово, и смысл задачи полностью изменился.
2. Примитивное решение: отсортировать массив и простейший поиск. Можно и деревом, но возни больше. Вообще оптимальный алгоритм зависит от размера массива. Для десятка элементов — любая сортировка из библиотеки и линейный поиск.
3. Решение в один цикл и один условный оператор. Даже не интересно.
И что значит «Учитывая массив целых чисел,»? Погрешности гуглопереводчика?
4. Единственная задача, требующая некоторых размышлений.
5. Банальное сканирование строки с подсчётом вхождения символов. И возврат значения логического выражения. Однако смущают примеры и комментарий.
Из первого примера следует, что студент не получает конфетку, поскольку опоздал больше 3 раз. В комментарии же написано: «потому что «LLA» означает, что он опоздал 3 раза подряд». Отсутствие == опоздание?? И где в условии сказано, что нельзя опаздывать 3 раза подряд?
Во втором примере тоже должно быть False, поскольку студент опаздывал более 3 раз.
Подозреваю, что условие задачи дано (или переведено с английского?) некорректно.
Пункт «дополнительно» n*(n-1)*(n-2)*(n-3), если следовать условию задачи из первого абзаца.
Вчера накатил сей апдейт. Так он у меня без объявления войны снёс геймпак от Windows 7 (Minesweeper, Hearts и пр.), который был поставлен отдельно. Спрашивается, какого чёрта обновление системы лезет в пользовательские приложения? Опять, как с внедрением Windows 10 в массы: «вы все недоумки, мы (Microsoft) лучше знаем что вам нужно!».
Теперь можно использовать спецификацию CSS Grid Layout без флагов в следующих браузерах: Firefox 52, Chrome 57, Opera 44, Safari 10.1. Какой из браузеров остался позади, думаю, вы догадываетесь. Точнее он поддерживает старую версию спецификации.
Вот если бы ещё все остальные браузеры умерли, а оставшиеся единомоментно проапгрейдились до вышеуказанных версий, было бы совсем отлично. А так всё равно придётся писать кучу флагов для совместимости.
Шаблоны — боль. Это как если в России всё делопроизводство велось бы на китайском языке. Или в Китае — на русском. Мозги приходится выворачивать в ортогональную плоскость. Но здесь видимо уже ничего не попишешь. Или шанс есть?
Да, в примере 1 правила 2 через nread ничего не вернётся. Поторопился. Я как увидел, что в аргумент функции пишется адрес локальной переменной, у меня забрало упало.
Учеников жалко. Не повезло с преподавателем.
Вообще-то я писал про время компиляции, а не про скорость работы. А для того, что бы откомпилировать std::accumulate, компилятору придётся сделать некий объём дополнительной работы по анализу шаблонов и пр.
Правило 1. Пример с циклом не показателен. Во-первых, первый пример абсолютно ясен, если вы сколько-нибудь долго пишете на C/C++. Во-вторых, время компиляции второго примера будет чуть больше (умножим на 100500 таких «циклов» в большом проекте). Кстати, какого типа будет sum во втором примере? — ага, double.
«Никаких сырых циклов» — вообще бред. Скорее всего цитата просто выдернута из контекста.
Правило 2. Результат работы функций read1 и read2 будут различны. Первая считывает в каждый массив char ровно по maxstring символов (за исключением последнего куска данных), включая пробельные символы и переводы строк. Концевой '\0' в массивы не добавляется. Вторая разбивает входные данные на строки по разделителям (пробельные символы и концы строк по умолчанию), которые в выходные данные не попадают.
Кроме того, в первой функции в параметре nread возвращается адрес локальной переменной. Это к слову о квалификации автора как программиста C++.
И «никаких сырых циклов»!
Правило 5. Спорно. Зависит как от конкретного кода, так и от размера экрана. И совершенно не факт, что определив новые логические сущности, разделив «на функции и объекты с методами», вы не получите двукратное увеличение объёма кода, разделённого на несколько файлов, с оверхедом в виде вызова функций и методов.
Кстати, это уже к автору перевода, термин «область видимости» имеет несколько другую семантику, если имеется ввиду язык программирования. Правило 5 лучше бы звучало как «пишите по возможности небольшие функции».
Правило 6. Оператор if (result.second) не скомпилируется в обоих случаях, поскольку имеет тип std::string, который неявно не приводится к bool.
Кстати, кроме старых машин есть ещё и новые, но специфические компьютеры. Одноплатники, например.
Кстати, кроме процедурного программирования и ООП существуют и другие парадигмы программирования. Если уж рефакторить, то по-большому.
Докладчику офигительно не хватает слованого запаса.
А есть ли это хорошо?
Wolfram language был спроектирован таким, видимо, исходя из каких-то достаточно веских оснований. Для универсального языка программирования такие возможности скорее минус, чем плюс. Вот, кстати, Ruby: одно и то же действие можно описать 2-3 разными синтаксическими конструкциями. Типа «кто как привык, пусть так и пишет». Но такой подход приводит к тому, что при разборе чужого кода надо помнить эти 2-3 вида конструкций. И это уже не хорошо.
Люди разрабатывают code style для того, что бы ограничить разнообразие использования пробелов, отступов, переводов строк. А тут полная «демократия» на уровне конструкций языка.
Во-вторых, «изучить я зык программирования» в статье понимается как «понять идеи, на которых основан язык» + «изучить синтаксис». Это — как правило, не проблема. Но что бы практически использовать язык, необходимо достаточно свободно ориентироваться в «стандартной библиотеке» (а она в том или ином виде всегда есть) и иметь навык комбинирования возмножностей, предоставляемых языком и стандартной библиотекой, для получения оптимальных результатов. А это уже совсем другие затраты сил и времени.
Хотя с основной мыслью статьи о полезности изучения базовых принципов, на которых строятся языки программирования, полностью согласен. Глупо было бы спорить.
Про специализацию. Можно, конечно, в критических ситуациях наступить себе на горло и заниматься тем, что не нравится: писать на Битриксе, разрабатывать лохотрон на PHP, ковырять фронтэнд… Я не говорю, что это в принципе плохо (кроме лохотрона, конечно), просто кому-то нравится фронтэнд, а кому-то писать драйвера устройств на С. Всё-таки работа должна приносить и моральное удовлетворение.
Требования по текущим вакансиям с «Моего Круга» (C++, удалённая работа):
Это вы называете «стандартными требованиями»?
Это я ещё не проваливался внутрь объявлений. Там обычно более развёрнутый список требований к соискателю.
Попробуйте посмотреть какие вакансии есть, например, на ресурсе, дружественном Хабру, «Мой круг» для разработчика на С++ в «удалённом режиме». Во-первых, вакансий очень немного (хотя вроде как С++ стабильно держит 2-3-4 место по востребованности). Во-вторых, либо требуестя дополнительно знание ещё большого количества чего-то (других языков, фреймворков, библиотек, технологий и пр.), либо это достаточно узкоспециализированная сфера, которую надо тоже знать.
Вы можете сказать, что если не знаешь «других языков, фреймворков, библиотек, технологий и пр.», то кто же виноват? Но всего знать нельзя. Поэтому ещё нужно что бы область знаний соискателя совпадала с требованиями работодателя. И проблема не в том, что " больше никуда развиваться не хочет", а в том, что работодателю нужно здесь и сейчас. Ждать месяц-два-три, пока вы куда-то там разовьётесь, ни кто не будет.
Возможно вашим знакомым повезло. Или они не хотят огорчать вас информацией о реальном положении дел. Или все они гуру в своей области. Или сугубо нетребовательны к уровню предлагаемой зарплаты. Вариантов много. Но с удалёнкой у нас пока объективно плохо.
Для справки. Сейчас посмотрел вакансии на «Мой круг»:
3. Откуда два прохода и дополнительная память?
Ну ещё добавить проверку, что длина массива больше 3. И вроде как всё. Или я что-то упустил?
5. Из контекста русского перевода как раз вообще ничего такого не следует. А вот в английском варианте, который сейчас добавили, написано: «being absent for more than once or being late for 3 times continuously». Здесь уже примеры выглядят логично: они поясняют, что подряд два опоздания и прогул тоже не допускаются. При переводе пропустили всего одно слово, и смысл задачи полностью изменился.
1. Некорректная постановка задачи. Тупо return 1352; формально удовлетворяет условию задачи.
2. Примитивное решение: отсортировать массив и простейший поиск. Можно и деревом, но возни больше. Вообще оптимальный алгоритм зависит от размера массива. Для десятка элементов — любая сортировка из библиотеки и линейный поиск.
3. Решение в один цикл и один условный оператор. Даже не интересно.
И что значит «Учитывая массив целых чисел,»? Погрешности гуглопереводчика?
4. Единственная задача, требующая некоторых размышлений.
5. Банальное сканирование строки с подсчётом вхождения символов. И возврат значения логического выражения. Однако смущают примеры и комментарий.
Из первого примера следует, что студент не получает конфетку, поскольку опоздал больше 3 раз. В комментарии же написано: «потому что «LLA» означает, что он опоздал 3 раза подряд». Отсутствие == опоздание?? И где в условии сказано, что нельзя опаздывать 3 раза подряд?
Во втором примере тоже должно быть False, поскольку студент опаздывал более 3 раз.
Подозреваю, что условие задачи дано (или переведено с английского?) некорректно.
Пункт «дополнительно» n*(n-1)*(n-2)*(n-3), если следовать условию задачи из первого абзаца.
Для динамического IP выдаёт полную ерунду. Другой вопрос, что на основании этой ерунды могут возбудить дело.
Вот если бы ещё все остальные браузеры умерли, а оставшиеся единомоментно проапгрейдились до вышеуказанных версий, было бы совсем отлично. А так всё равно придётся писать кучу флагов для совместимости.