Я не очень хорошо помню, есть ли в спецификации jls/jvms понятие «постоянная». Но вынужден заметить, что ни константным выражением, ни константой String.class не является. Иными словами, на этапе компиляции значение данного выражения не может быть определено. Именно поэтому оно и не может быть использовано в case. Таблицы поиска для switch/case генерируются на этапе компиляции. Для String-значений switch компилируется в код, использующий две таблицы поиска. Первая из них содержит hashCode образцов. То, что вы предлагаете, вынуждает либо отказаться от эффективной реализации switch/case путём замены её на линейную цепочку проверок, либо утяжелить загрузку классов, переложив на неё коррекцию соответствующих таблиц поиска (для эффективного сравнения используется hashCode). Вот такой вот «крошечный шаг».
Тут не только о том, что три числа в два сжимаются. Тут ещё о том, что в предлагаемом варианте не зависимо от того, где расположена точка на единичной сфере, сжатие будет одинаково хорошим/плохим (до точности представления float). В варианте с углами, одни точки будут закодированы более точно, чем другие. Об этом автор говорит тут:
Если сгенерировать случайные сферические координаты и преобразовать их обратно в 3D-точки, они образуют скопления вокруг полюсов и будут довольно разреженными возле экватора. Это является следствием того, что 3D-векторы рядом с экватором будут менее точно различимы.
Двойственное ощущение от статьи. С одной стороны — просвещение, польза! Про «strictfp» не помню, чтобы слышал. С другой стороны — простите, детский сад какой-то.
Если использовать assert, хорошо бы знать, как он работает. Как только он появился, сразу прочитал про него всё, а не остановился на выжимке, что появилась мол, новая функциональность в языке.
Switch-case тоже, базовая конструкция языка, вроде. Либо используем и знаем, как она работает, либо не удивляемся, что она имеет ограничения. Раньше вообще можно было только числа использовать. (Да, тут я рассматриваю char как число). И, на всякий случай, в case можно писать только константу/константное выражение.
Break и continue — я бы удивился, если бы не было возможности указать метку. Как уже говорили выше — если пишешь на java, хорошо бы понимать, откуда растут ноги.
Вызов vararg-метода без аргументов. У меня единственный вопрос, а почему вообще ожидается, что массив, который содержит аргументы, внезапно может оказаться и не массивом вовсе, а null? Тут же, вроде, всё логично: длина массива равна количеству аргументов. Ноль аргументов — массив длины ноль. Или у меня логика ущербная? И предвосхищая комментарий: «ну, производительность-же!», опять же, сошлюсь на логику.
int.class.isAssignableFrom(Integer.class) — ну autoboxing-же. Если об этом не задумываться или не знать о его существовании, то как же жить-то дальше? int.class != Integer.class туда же. Это же базовые понятия языка — примитивные и непримитивные типы.
А по вопросу, помогли ли эти знания в production, скажу, что мат-часть хорошо бы знать. Иначе использовать её на полную не получится. А если не знать, то процесс уже напоминает раскладывание грабель. И очень повезёт, если как в случае с switch — case, код просто не скомпилируется. Так что то, что подобные вещи не знают программисты, которые работают над тем же проектом, это очень даже мешает в production. Поскольку обидно наступать на грабли, подложенные коллегой, который просто не знает базовых вещей.
Amphis, в первичную синхронизацию входит процесс полного обнуления входящих в RAID1 партиций. Это занимает некоторое время, в зависимости от размера партиций. Как я уже писал, это «можно отключить для начальной сборки, но я предпочитаю «перебдеть».».
Ничего против изначального поднятия полноценного RAID1 не имею. Но сам так делаю не всегда ;)
Я думаю, все преимущества и недостатки данного метода «видны невооружённым глазом». Существенных отличий нет. Конечно, если этот единственный диск вдруг испортится до того, как полноценный RAID1 заработает, то будет неприятно. Но это риск, на который мы осознанно пошли.
Я тоже часто подготавливаю всё сначала на RAID1 только с одним диском, потом добавляю второй. Моя мотивация — то, что при сборке RAID1 диски в обоих случаях должны быть синхронизированы. (Можно отключить для начальной сборки, но я предпочитаю «перебдеть».) Пока идёт начальная синхронизация, я предпочитаю систему не дёргать и не перезапускать, хотя тут каждый решает сам. Да и дисковые операции становятся медленнее. Таким образом, готовя всё только на одном диске, я откладываю фазу первичной синхронизации на потом.
Так же, часто использую RAID1 с единственным диском на виртуальных машинах, где на прототипе отлаживаю RAID1 конфигурацию. При тестах выхода из строя одного из дисков, второй диск, естественно, приходится перед этим добавлять :)
И да, всегда создаю LVM-партиции поверх RAID1. Потом это сильно помогает при online перебросах или расширении партиций.
Даже некоторые провайдеры так поступают — пред-устанавливают две swap партиции на разных дисках, остальные партиции которых входят в программный RAID1. Проблемы начинаются, когда один из дисков выходит из строя. Особенно горько, если в swap были записаны данные. Да и система с такой конфигурацией при выходе из строя одного из дисков в большинстве случаев виснет.
Если же swap-партиция находится в RAID1 и контроллер поддерживает hot swap, то выход из строя и замена одного из дисков проходит для пользователей практически незаметно, а для администратора — бескровно.
А теперь у вас появляется скрипт, который порождает два файла
У меня такое видение проблемы. Если скрипт генерирует несколько целей, и важно этот факт отслеживать в ходе сборки, то можно поступить так. (Я поступал).
Выделяем «главный порождаемый файл», скажем, .h, либо порождаем искусственный touch-файл в начале скрипта, скажем, .hcc42 (естественно, при ошибке трём). Собственно правило, которое и дёргает этот скрипт и есть единственное правило для главного порождаемого файла. Все остальные генерируемые файлы (.cc в вашем случае) называем «второстепенными». Для них ставим зависимость от главного порождаемого файла. В команде генерации [каждого] второстепенного файла вываливаемся с ошибкой, если он [второстепенный файл] старше главного. Больше ничего для второстепенных файлов не делаем.
искусственный touch-файл может быть необходим,
если мы не можем выделить ни одного порождаемого файла, который был бы всегда моложе или такого же возраста, как остальные порождаемые файлы.
Причём всё это следует стараться описать правилами-шаблонами, иначе слишком многословно получается.
Конечно, возникает вопрос — зачем. Для себя я ответил на него следующим образом: так всё без проблем продолжает работать с парадигмой gnu make. Ну а такое расширение, почти вроде-как и не «костыль» вовсе ;)
Make-файлы make-файлам рознь. Какими напишешь — такими и будут. Долгое время — больше пяти лет — жили с системой сборки развесистого c++ проекта, построенной на базе gnu make. Всё было понятно, лаконично, быстро.
Потом перешёл на другую работу, поэтому, как эта система сборки развивалась дальше — не знаю.
Вот мои «десять копеек». Основная мысль статьи — правильная. Пример — неплохой. Объяснение и обоснование — так себе. Управление потоком без исключений — это когда всё идёт по плану, когда данные не битые, когда файлы там, где мы их хотим найти, когда сеть не сбоит,… Как только случается то, что для нас выходит за рамки запланированного нормального хода работы, тогда появляются исключения. При чём эти рамки определяем мы сами. Чаще всего, на исключения надо реагировать существенно выше по иерархии кода, прерывая его выполнение. Недалеко от тех мест, где исключения возникают, обычно вообще не понятно, что с ними делать, кроме как передать или обернуть-и-передать вызывающему. В языках программирования без исключений приходится изворачиваться и тянуть информацию об ошибке назад по стеку вызовов, организуя альтернативное управление ходом программы с кучей дополнительных проверок. Потом иногда оказывается, что «совсем уж исключительные ситуации» всё-равно нужно было обрабатывать иначе. Например, деление на 0 или ctrl-C в консольном приложении на C.
В примере показана обработка исключения возвращением значения из предметной области. То-есть, нам ясно, что такая ситуация может произойти, и мы для себя решили, что это нормально. Тогда возникает вопрос, а почему же мы рассматриваем эту ситуацию как исключительную? Так что в первую очередь, стоит понять для себя, что нормально для программы, а что нет. И тогда скорее всего окажется, что при появлении исключительной ситуации, производительность уже не играет такой существенной роли.
Конечно, за удобство элегантно выпрыгнуть из стека вызовов, надо платить. Поэтому там, где важна производительность в исключительных ситуациях, возможно, от Exception придётся отказаться. Но лично мне такое встречалось нечасто.
Добавлю, что объект в JavaScript похож на «классический » словарь (std::map в c++) методами доступа к полям (в JavaScript они называются свойствами — properties), но всё-же словарём не является. Есть ограничения/тонкости. Хотя, до появления Map, объекты часто использовались в качестве словарей с известными ограничениями.
Согласен, явно этого сказано не было. Только решение, которое вы предлагаете, может давать разные результаты, если поменять местами входные массивы. Как-то несолидно, не находите?
Ну или вначале из numTwo сделать набор.
Для больших массивов можно сравнить количество элементов в mySet и numTwo, и на основании этого использовать либо первый вариант, либо второй.
А на ущербном cmd писать 1% от функциональности вышеуказанных кроссплатформенных инструментов — выделки, по-моему, не стоит…
Ваши вопросы как-то плохо к нему подходят. Если хотите поговорить о cmd, power shell,… etc. — давайте поговорим.
Насчет cmd — то без него как вы настроите, диагностируете систему?… Как без cmd диагностировать систему, если большая часть утилит не имеет GUI?
Скрипты настройки и диагностики могут быть на чём угодно, в том числе на cmd. Просто, на cmd лаконично без «подвыподвертов» у меня хоть сколько-нибудь серьёзной логики написать не получалось. Да и возможность обработки сигналов отсутствует… На том же bash это было существенно красивее. Я использовал и gnuwin, и cygwin, сейчас добавился wsl. На питоне подобную логику приходилось писать — тоже куда удобнее, чем на cmd. Но вас я не отговариваю.
Будете использовать power shell?
power shell я не люблю, поскольку нахожу его весьма тяжеловесным «на вкус и цвет»… Хотя он очень мощный. Правда, для кода, показанного в статье, power shell — по-моему, перебор.
Будете подключаться из Linux?
Мне не очень понятно, что вы имеете в виду. Мы же говорим о windows.
Будете использовать кучу стороннего софта и те утилиты с GIU которые есть в системе?
«кучу стороннего софта» — нет. Только набор удобных утилит, такой, например, как gnuwin. А «утилиты с GIU» для подобных задач сомнительны, да и часто не имеют api.
Или руками лезть каждый раз в regedit?
А тут вообще не понял. REG (\Windows\System32\reg.exe), которую вы используете, — это утилита, которую можно запускать откуда угодно. К cmd она прямого отношения не имеет. Кстати, для изменения мастер-копии переменных окружения, больше подходит утилита SETX. Хотя в рамках «компиляции программ с помощью Notepad++», потребность переписывать что-то в registry заставляет серьёзно задуматься об этой «компиляции». Если не хочется «вводить каждый раз полный путь к программе», в моей ситуации удобнее прописать эти данные в локальном файле конфигурации окружения проекта, поскольку, как правило, компиляторов стоит несколько версий.
Это конечно хорошо, представлять себе, как можно откомпилировать пару файлов. Но писать об этом статью, по-моему, как из пушки по воробьям. Развитие-то какое? Обычно нужно собирать проекты, состоящие из большого количества файлов с исходным кодом и библиотек. Да и после сборки частенько хочется тесты запускать,… а перед сборкой — анализатор качества исходного кода… Библиотеки, опять же, временами пересобирать приходится… Иногда свои патчи применять…
Если хочется на уровне отдельных файлов с исходными текстами работать — посмотрите в сторону make, в частности — gnu make. Если на несколько уровней выше — то в сторону maven. На apache ant тоже можно глянуть, но я бы не советовал… А на ущербном cmd писать 1% от функциональности вышеуказанных кроссплатформенных инструментов — выделки, по-моему, не стоит…
Если использовать assert, хорошо бы знать, как он работает. Как только он появился, сразу прочитал про него всё, а не остановился на выжимке, что появилась мол, новая функциональность в языке.
Switch-case тоже, базовая конструкция языка, вроде. Либо используем и знаем, как она работает, либо не удивляемся, что она имеет ограничения. Раньше вообще можно было только числа использовать. (Да, тут я рассматриваю char как число). И, на всякий случай, в case можно писать только константу/константное выражение.
Break и continue — я бы удивился, если бы не было возможности указать метку. Как уже говорили выше — если пишешь на java, хорошо бы понимать, откуда растут ноги.
Вызов vararg-метода без аргументов. У меня единственный вопрос, а почему вообще ожидается, что массив, который содержит аргументы, внезапно может оказаться и не массивом вовсе, а null? Тут же, вроде, всё логично: длина массива равна количеству аргументов. Ноль аргументов — массив длины ноль. Или у меня логика ущербная? И предвосхищая комментарий: «ну, производительность-же!», опять же, сошлюсь на логику.
int.class.isAssignableFrom(Integer.class) — ну autoboxing-же. Если об этом не задумываться или не знать о его существовании, то как же жить-то дальше? int.class != Integer.class туда же. Это же базовые понятия языка — примитивные и непримитивные типы.
А по вопросу, помогли ли эти знания в production, скажу, что мат-часть хорошо бы знать. Иначе использовать её на полную не получится. А если не знать, то процесс уже напоминает раскладывание грабель. И очень повезёт, если как в случае с switch — case, код просто не скомпилируется. Так что то, что подобные вещи не знают программисты, которые работают над тем же проектом, это очень даже мешает в production. Поскольку обидно наступать на грабли, подложенные коллегой, который просто не знает базовых вещей.
Ничего против изначального поднятия полноценного RAID1 не имею. Но сам так делаю не всегда ;)
Я тоже часто подготавливаю всё сначала на RAID1 только с одним диском, потом добавляю второй. Моя мотивация — то, что при сборке RAID1 диски в обоих случаях должны быть синхронизированы. (Можно отключить для начальной сборки, но я предпочитаю «перебдеть».) Пока идёт начальная синхронизация, я предпочитаю систему не дёргать и не перезапускать, хотя тут каждый решает сам. Да и дисковые операции становятся медленнее. Таким образом, готовя всё только на одном диске, я откладываю фазу первичной синхронизации на потом.
Так же, часто использую RAID1 с единственным диском на виртуальных машинах, где на прототипе отлаживаю RAID1 конфигурацию. При тестах выхода из строя одного из дисков, второй диск, естественно, приходится перед этим добавлять :)
И да, всегда создаю LVM-партиции поверх RAID1. Потом это сильно помогает при online перебросах или расширении партиций.
Если же swap-партиция находится в RAID1 и контроллер поддерживает hot swap, то выход из строя и замена одного из дисков проходит для пользователей практически незаметно, а для администратора — бескровно.
Да нет, это было некоторое количество лет назад, внезапно… только под windows :) Так что некоторые детали подзабыл.
У меня такое видение проблемы. Если скрипт генерирует несколько целей, и важно этот факт отслеживать в ходе сборки, то можно поступить так. (Я поступал).
Выделяем «главный порождаемый файл», скажем, .h, либо порождаем искусственный touch-файл в начале скрипта, скажем, .hcc42 (естественно, при ошибке трём). Собственно правило, которое и дёргает этот скрипт и есть единственное правило для главного порождаемого файла. Все остальные генерируемые файлы (.cc в вашем случае) называем «второстепенными». Для них ставим зависимость от главного порождаемого файла. В команде генерации [каждого] второстепенного файла вываливаемся с ошибкой, если он [второстепенный файл] старше главного. Больше ничего для второстепенных файлов не делаем.
Причём всё это следует стараться описать правилами-шаблонами, иначе слишком многословно получается.
Конечно, возникает вопрос — зачем. Для себя я ответил на него следующим образом: так всё без проблем продолжает работать с парадигмой gnu make. Ну а такое расширение, почти вроде-как и не «костыль» вовсе ;)
Потом перешёл на другую работу, поэтому, как эта система сборки развивалась дальше — не знаю.
В примере показана обработка исключения возвращением значения из предметной области. То-есть, нам ясно, что такая ситуация может произойти, и мы для себя решили, что это нормально. Тогда возникает вопрос, а почему же мы рассматриваем эту ситуацию как исключительную? Так что в первую очередь, стоит понять для себя, что нормально для программы, а что нет. И тогда скорее всего окажется, что при появлении исключительной ситуации, производительность уже не играет такой существенной роли.
Конечно, за удобство элегантно выпрыгнуть из стека вызовов, надо платить. Поэтому там, где важна производительность в исключительных ситуациях, возможно, от Exception придётся отказаться. Но лично мне такое встречалось нечасто.
заполнит duplicatedValues так: [ 2, 4, 6, 4, 2 ]
Ну или вначале из numTwo сделать набор.
Для больших массивов можно сравнить количество элементов в mySet и numTwo, и на основании этого использовать либо первый вариант, либо второй.
Скрипты настройки и диагностики могут быть на чём угодно, в том числе на cmd. Просто, на cmd лаконично без «подвыподвертов» у меня хоть сколько-нибудь серьёзной логики написать не получалось. Да и возможность обработки сигналов отсутствует… На том же bash это было существенно красивее. Я использовал и gnuwin, и cygwin, сейчас добавился wsl. На питоне подобную логику приходилось писать — тоже куда удобнее, чем на cmd. Но вас я не отговариваю.power shell я не люблю, поскольку нахожу его весьма тяжеловесным «на вкус и цвет»… Хотя он очень мощный. Правда, для кода, показанного в статье, power shell — по-моему, перебор.Мне не очень понятно, что вы имеете в виду. Мы же говорим о windows.«кучу стороннего софта» — нет. Только набор удобных утилит, такой, например, как gnuwin. А «утилиты с GIU» для подобных задач сомнительны, да и часто не имеют api.А тут вообще не понял. REG (\Windows\System32\reg.exe), которую вы используете, — это утилита, которую можно запускать откуда угодно. К cmd она прямого отношения не имеет. Кстати, для изменения мастер-копии переменных окружения, больше подходит утилита SETX. Хотя в рамках «компиляции программ с помощью Notepad++», потребность переписывать что-то в registry заставляет серьёзно задуматься об этой «компиляции». Если не хочется «вводить каждый раз полный путь к программе», в моей ситуации удобнее прописать эти данные в локальном файле конфигурации окружения проекта, поскольку, как правило, компиляторов стоит несколько версий.
Мне показалось лишь странным, описывать достаточно простые вещи в немаленькой статье. Хотя я не рассматривал данную статью как tutorial для NppExec.
Ну а попытка донести информацию, что часто требуется нечто большее, чем компиляция пары-другой файлов, похоже, успехом не увенчалась.
Да нет, не смутило. Поэтому gnu make и упомянул.
Если хочется на уровне отдельных файлов с исходными текстами работать — посмотрите в сторону make, в частности — gnu make. Если на несколько уровней выше — то в сторону maven. На apache ant тоже можно глянуть, но я бы не советовал… А на ущербном cmd писать 1% от функциональности вышеуказанных кроссплатформенных инструментов — выделки, по-моему, не стоит…