Возьмите под контроль работу персонала в режиме онлайн.
Наблюдайте, чем прямо сейчас занят человек, загляните в его монитор,
ознакомьтесь с содержимым всех окон, открытых на рабочем столе компьютера.
Контролируйте нажатия клавиш сотрудником. Узнайте, что он пишет прямо сейчас и
какую информацию вводил ранее. Онлайн-мониторинг и запись видео, объединенные
с кейлоггером, помогут Вам обеспечить наиболее эффективный контроль сотрудников.
Ну и хрень этот ваш Kickidler...
Может быть, российские программисты, сваявшие Kickidler на заказ и свалившие после этого из проекта, и являются самыми лучшими (технически), но руководители бизнеса, заказавшие и использующие эту хрень, к лучшим точно не относятся. Это же как нужно не доверять своим сотрудникам (о "команде", да еще "единомышленников", даже речи нет), чтобы постоянно шпионить за ними таким образом? Так что можете дополнить свою статью еще одним пунктом.
Кстати, в некоторых западных странах сотрудники могут через суд запретить своему работодателею использовать такой софт.
Да, если строку считать набором одиночных символов, каждый из которых считается отдельным валидным разделителем, то функция работает правильно. Но если так не считать, то она ошибочна.
В любом случае, очевидно нарушение автором своих же правил:
Комментарии
Если вы пишете понятный код с разумными именами, то комментировать вам практически нечего. Только места с неочевидными вещами, хаки. Лучше потратьте энергию на короткое описание что же все таки делает этот модуль.
то результат будет: "a", "a", "a", "a"
вместо ожидаемого: "aSa", "a", "Sa"
Если выложил в интернет — удали.
Если удалил — сделал добро людям.
Сделайте доброе дело: удалите ваш код из этой сатьи, пока кто-либо его не скопировал.
Или хотя бы поправьте и протестируйте перед выкладыванием (да еще с претензией «у меня лучше, чем в Boost»).
Вообще-то Ant по умолчанию вообще ничего на тащит из интернета и не требует его. Если Ant-скрипт что-то и тянет оттуда, то это программист своими очумелыми ручками сделал такой custom-таск (ну, или вставил сторонний таск «для улучшения»).
Тянуть что-либо со стороны — это как раз maven (ну и gradle).
Автору: статья расчитана на новичков, не умеющих делать сборку. Почему вы не началим с простейшего срособа собрать «hello world» без сторонних систем сборок? Или это уже не требуется от желающих найти работу?
Никто и не говорит о панацее. Иначе new/delete выбросили бы из стандарта, чего точно никогда не произойдет.
замените глобальный operator new/delete на...
Переопределение операторов new/delete ничего не даст, т.к. смысл в отказе от их явного использования. Так что это не сработает.
Следует изначально стараться писать код с минимумом new/delete, либо подвергнуть его рефакторингу.
По-поводу замены всех операторов new: да, в реальной большой программе полностью сделать это не получится.
Однако даже минимизация их использования уже приведет к указанным бонусам (простота, безопасность, производительность).
Хотя время жизни «автоматических» переменных и ограничено текущим блоком, большинство таких блоков вложены в другие (причем многократно, вплоть до функции main на самом верху, где время их жизни равно времени работы программы). Стековая переменная, созданная на одном уровне, гарантированно существует для всех своих «потомков» (вложенных блоков или синхронно вызванных функций/методов), которые могут безопасно использовать её. Так что область использования таких переменных может быть намного больше, чем может показаться на первый взгляд.
Я и не говорил об универсальности. Я сказал, что «можно минимизировать явное динамическое выделение памяти» (те самые new/delete или malloc/free).
a) наоборот: память под стековый объект выделяется неявно (автоматически), и так же неявно (автоматически) освобождается. Программисту ничего не нужно для этого делать (ни «new», ни «delete»), кроме соответствующего объявления переменной без указателей и ссылок, и (опционально) инициализации (если default инициализация не устраивает).
Вы, вероятно, «явное объявление переменной» назвали «явным выделением», однако это не одно и то же. Например, «явно объявленная» переменная типа «указатель» не означает, что соответствующий объект будет действительно выделен — вам в дополнение к объявлению еще и явное выделение нужно сделать (используя «new»), а затем и явное освобождение («delete»). А вот при «явном объявлении» стековой переменной (не указателя и не ссылки) память будет автоматически (==неявно) выделена и освобождена.
б) Этого и не требуется. «new»/«delete» — это тот самое явное динамическое управление ресурсами, использование которого следует минимизировать.
в) Да, время жизни ограничено текущим блоком. Но при грамотном использовании это существенно улучшает код сразу в нескольких направлениях: простота, безопасность, производительность. Причем до такой степени, что аргументы в пользу JIT типа «оптимизация проверки на null и быстрое выделение памяти без синхронизаций» становятся бессмысленными: в C++ можно с легкостью писать код, в котором эти улучшения «встроены генетически».
В C++ можно минимизировать явное динамическое выделение памяти в пользу автоматического создания объектов на стеке, которое и работает намного быстрее любого аллокатора и без блокировок, и к тому же безопаснее. Например, нет указателей, которые нужно было бы проверять, ресурсы выделяются/удаляются в exception-safe режиме (RAII). Причем в C++ такой подход считается не специальной оптимизацией, а обычным рекоммендуемым подходом. Вряд ли JIT смог бы здесь что-либо улучшить.
Это только если делать программы для использования на широком спектре железа. Тогда да, JIT может динамически подстроить программу под тип и количество CPU и т.д. В принципе, это могло бы дать Java некоторое преимущество (хотя и это спорно) на, к примеру, зоопарке десктопов, если бы не чрезмерная требовательность к ресурсам.
Однако все опрошенные эксперты говорили об «интерпрайзе». Это значит — свои серверы, или по крайней мере — с исзвестной архитектурой. Статическая компиляция своего C++ кода с настройками под конкретную архитектуру сервера + перекомпиляция некоторых из используемых библиотк (делается 1 раз для каждой версии библиотеки) убивает указанное преимущество JIT.
Java с её «гарантиями безопасности» позволяет достичь результата, используя менее квалифицированных программистов
при одной и той же квалификации в обоих языках выгоднее использовать язык, на котором делать продукт можно быстрее (включая выполнение всех требований)
Это практически одно и то же, но «вид сбоку».
К тому же, есть нюанс в определениях «одинаковая квалификация» и «выполнение всех требований». Исходя из нашего опыта, для написания безопасного (с точки зрения работы с памятью и другими ресурсами) кода на C++ в среднем нужна более высокая квалификация, чем для кода на Java.
Нет такого расового деления — разработчик java/разработчик c++.
На самом деле, такле разделение есть. У нас есть как те, так и другие, и мы не будем Java программистам ставить задачи с разработкой на C++, и наоборот. Да они и сами не возьмутся без крайней необходимости.
Автоматическая оптимизация C++ компиляторов тоже «всегда работает» для всего проекта любого размера.
Возможность настроить (оптимизировать) компиляцию отдельных частей проекта (причем при необходимости — по-разному для разных частей) — это «бонус», которого нет в JIT.
Владимир Ситников: Если же говорить про C++, то, если библиотеку скомпилировали и библиотека выполняет виртуальный вызов, то всё, у пользователя нет шансов сделать вызов не виртуальным.
В целом, один из самых действенных способов оптимизации — исключать лишние действия. Для того чтобы C++ библиотеки «видели» особенности их использования, программистам C++ приходится делать разнообразные приседания
О какой оптимизации речь? Производительности разработчика? Так вопрос был о рантайме.
Вообще-то, описанная как недостаток (да еще с точки зрения оптимизации в рантайме) особенность C++ дает прирост производительности по сравнению с Java. Причем как с точки зрения скорости начальной заргрузки программы, так и «рабочей» производительности.
Что предпочтительнее: использование архитектурных особенностей машины вручную (С++), либо лучше положиться на динамические оптимизации JVM?
— Адаптивная компиляция и автоматическое управление памятью — как раз сильные стороны Java.
… но не сильнее «ручной» настройки компилятора C++ :-) В лучшем для JIT случае — он так же силен (что вряд ли).
Мы выбираем JVM за те гарантии безопасности, что она нам даёт. В первую очередь — защиту от фатальных ошибок из-за неправильной работы с памятью. Искать проблемы, связанные с указателями или выходом за границы массива, в неуправляемом коде на порядок сложнее.
В конечном итоге все упирается в квалификацию и дисциплину разработчиков. Java с её «гарантиями безопасности» позволяет достичь результата, используя менее квалифицированных программистов. Экономически это выгодно, конечно.
Андрей Паньгин: Редко, когда мы упираемся в производительность самой Java платформы. Обычно проблемы можно решить либо заменой алгоритма, либо масштабированием, то есть наращиванием железа. Чаще всего узким местом оказывается пропускная способность сети или дисковый ввод-вывод.
Вот как раз масштабированием и изощренными алгоритмами и решаются проблемы с упором в производительность. А вы говорите — «редко»…
иметь весь набор прав и свобод гражданина Евросоюза.
Это преувеличение. Весь набор прав гражданина Евросоюза имеют только граждане Евросоюза. К примеру, право избирать и быть избранным. Или работать в определенных гос. учреждениях (включая EU уровня вроде ESA) и фирмах (например, оборонных).
Уже сказал:
Это насчет "доверия" руководства своей "команде".
Да и статья ваша напоминает скрытую рекламу вашего продукта: вроде и не о нем статья, а всё же ссылочку добавили.
Глянул на ваш продукт по ссылке:
Ну и хрень этот ваш Kickidler...
Может быть, российские программисты, сваявшие Kickidler на заказ и свалившие после этого из проекта, и являются самыми лучшими (технически), но руководители бизнеса, заказавшие и использующие эту хрень, к лучшим точно не относятся. Это же как нужно не доверять своим сотрудникам (о "команде", да еще "единомышленников", даже речи нет), чтобы постоянно шпионить за ними таким образом? Так что можете дополнить свою статью еще одним пунктом.
Кстати, в некоторых западных странах сотрудники могут через суд запретить своему работодателею использовать такой софт.
В любом случае, очевидно нарушение автором своих же правил:
Вы в курсе, что ваша функция не всегда работает правильно (==«убивает»)?
Объявление функции допускает использование произвольной строки в качестве delimiters:
Например, если я сделаю вызов:
то результат будет:
"a", "a", "a", "a"вместо ожидаемого:
"aSa", "a", "Sa"Сделайте доброе дело: удалите ваш код из этой сатьи, пока кто-либо его не скопировал.
Или хотя бы поправьте и протестируйте перед выкладыванием (да еще с претензией «у меня лучше, чем в Boost»).
Тянуть что-либо со стороны — это как раз maven (ну и gradle).
Автору: статья расчитана на новичков, не умеющих делать сборку. Почему вы не началим с простейшего срособа собрать «hello world» без сторонних систем сборок? Или это уже не требуется от желающих найти работу?
Переопределение операторов new/delete ничего не даст, т.к. смысл в отказе от их явного использования. Так что это не сработает.
Следует изначально стараться писать код с минимумом new/delete, либо подвергнуть его рефакторингу.
По-поводу замены всех операторов new: да, в реальной большой программе полностью сделать это не получится.
Однако даже минимизация их использования уже приведет к указанным бонусам (простота, безопасность, производительность).
Хотя время жизни «автоматических» переменных и ограничено текущим блоком, большинство таких блоков вложены в другие (причем многократно, вплоть до функции main на самом верху, где время их жизни равно времени работы программы). Стековая переменная, созданная на одном уровне, гарантированно существует для всех своих «потомков» (вложенных блоков или синхронно вызванных функций/методов), которые могут безопасно использовать её. Так что область использования таких переменных может быть намного больше, чем может показаться на первый взгляд.
a) наоборот: память под стековый объект выделяется неявно (автоматически), и так же неявно (автоматически) освобождается. Программисту ничего не нужно для этого делать (ни «new», ни «delete»), кроме соответствующего объявления переменной без указателей и ссылок, и (опционально) инициализации (если default инициализация не устраивает).
Вы, вероятно, «явное объявление переменной» назвали «явным выделением», однако это не одно и то же. Например, «явно объявленная» переменная типа «указатель» не означает, что соответствующий объект будет действительно выделен — вам в дополнение к объявлению еще и явное выделение нужно сделать (используя «new»), а затем и явное освобождение («delete»). А вот при «явном объявлении» стековой переменной (не указателя и не ссылки) память будет автоматически (==неявно) выделена и освобождена.
б) Этого и не требуется. «new»/«delete» — это тот самое явное динамическое управление ресурсами, использование которого следует минимизировать.
в) Да, время жизни ограничено текущим блоком. Но при грамотном использовании это существенно улучшает код сразу в нескольких направлениях: простота, безопасность, производительность. Причем до такой степени, что аргументы в пользу JIT типа «оптимизация проверки на null и быстрое выделение памяти без синхронизаций» становятся бессмысленными: в C++ можно с легкостью писать код, в котором эти улучшения «встроены генетически».
Однако все опрошенные эксперты говорили об «интерпрайзе». Это значит — свои серверы, или по крайней мере — с исзвестной архитектурой. Статическая компиляция своего C++ кода с настройками под конкретную архитектуру сервера + перекомпиляция некоторых из используемых библиотк (делается 1 раз для каждой версии библиотеки) убивает указанное преимущество JIT.
К тому же, есть нюанс в определениях «одинаковая квалификация» и «выполнение всех требований». Исходя из нашего опыта, для написания безопасного (с точки зрения работы с памятью и другими ресурсами) кода на C++ в среднем нужна более высокая квалификация, чем для кода на Java.
На самом деле, такле разделение есть. У нас есть как те, так и другие, и мы не будем Java программистам ставить задачи с разработкой на C++, и наоборот. Да они и сами не возьмутся без крайней необходимости.
Возможность настроить (оптимизировать) компиляцию отдельных частей проекта (причем при необходимости — по-разному для разных частей) — это «бонус», которого нет в JIT.
Вообще-то, описанная как недостаток (да еще с точки зрения оптимизации в рантайме) особенность C++ дает прирост производительности по сравнению с Java. Причем как с точки зрения скорости начальной заргрузки программы, так и «рабочей» производительности.
модификация строки формата "%s" может привести к ошибке :-)
http://www.gnu.org/software/hello/
:-)
Так что — почти весь набор…