CMake — [средневековье] первая попытка уйти от низкоуровневых деталей make-а.
Зря вы, не разобравшись, списываете удобный инструмент.
Такой подход напоминает мне красивый фасад старого деревянного дома, который заботливо обшили свежим пластиком.
И все это следствия чуток кривоватой архитектуры, когда основная часть работы выполняется другими «помощниками».
Это называется unix-way: "Write programs that do one thing and do it well.". Cmake — это генератор. И у него хорошо это получается. Отслеживание зависимостей хорошо получается у make/ninja и других инструментов.
Под Linux все вроде бы хорошо, но если нужно построить тот же проект под Windows с помощью MSVC — а я предпочитаю нативный компилятор MinGW-шному, будут сгенерированы файлы для NMake
Представьте, что вы создали большую компанию. Ради привлечения инвестиций часть акций продали на API, другую часть стратегическим партнерам. Но у вас остался контрольный пакет. Так вот, кому принадлежит большая часть активов этой компании? Разве ей самой?
И подумайте, кто как не владелец имеет решающий вес в вопросе о том, куда девать прибыль: возвращать акционерам в виде дивидендов или же инвестировать, в том числе с рискованные проекты?
Спасибо за полезную информацию! В среди аббревиатур DMARC, DKIM и SPF не хватает ARC. Очень интересно, планирует ли почта mail.ru внедрение Authenticated Received Chain (http://arc-spec.org/)?
Идея хорошая, мне тоже приходится смотреть логи. Но ваше приложение, при попытке открыть лог размером 7 Гб (это всего за 3 часа работы), начало кушать 100% CPU и отъело кучу памяти, пока не было убито. У less же навигация по такому логу не вызывает затруднений.
В тексте много раз упоминается забота о пользователях. Но где же открытое API для этих пользователей? Мне оно нужно для своего устройства на arduino, которое отображает полезную информацию, в том числе погоду.
Следует уточнить, фраза «We don't really use MapReduce anymore» не означает, что «map reduce не справляется с обработкой действительно больших данных».
Не означает. Об этом другой абзац:
The technology is unable to handle the amounts of data Google wants to analyze these days, however.
Я прекрасно понимаю, что MapReduce не отомрет так быстро и они продолжают его использовать. У меня создалось впечатление, что они не считают MapReduce перспективной и универсальной технологией для big data.
Почему-то все чаще начинают писать о map reduce. Интересно, а что вы думаете о высказывании старшего вице-президента по инфраструктуре google о том, что они больше не используют map reduce?
“We don’t really use MapReduce anymore,” Hölzle said in his keynote presentation at the Google I/O conference in San Francisco Wednesday. The company stopped using the system “years ago.”
Источник цитаты: http://www.datacenterknowledge.com/archives/2014/06/25/google-dumps-mapreduce-favor-new-hyper-scale-analytics-system/
По их словам, map reduce не справляется с обработкой действительно больших данных.
1. Обработчик сигналов не AS-Safe (https://www.gnu.org/software/libc/manual/html_node/POSIX-Safety-Concepts.html)
2. Обработчик исключений выделяет память, а что если она закончилась и произошло исключение std::bad_alloc?
3. Такое решение дает накладные расходы на каждый вызов.
4. Нет возможности получить стек вызова при использовании сторонних библиотек.
5.…
Не проще ли воспользоваться backtrace/backtrace_symbols в Linux или WinGdb на Windows?
Проверил, самый свежий gcc (5.3.0) все еще генерирует вот это:
func(int):
cmpl $1, %edi
je .L3
cmpl $2, %edi
je .L4
cmpl $3, %edi
je .L5
cmpl $4, %edi
je .L6
cmpl $5, %edi
movl $100, %edx
movl $50, %eax
cmovne %edx, %eax
ret
.L6:
movl $40, %eax
ret
.L3:
movl $10, %eax
ret
.L4:
movl $20, %eax
ret
.L5:
movl $30, %eax
ret
Все еще никакой оптимизации со стороны компилятора.
Конечно информация имеет свойство устаревать, это факт. Я в самом начале указал, что все это написано давно (2006-2008, если мне не изменяет память). Так что же, теперь ничего не писать?
Если постараться, в C++, как и в других низкоуровневых языках, можно сделать все, что угодно. Однако ссылку даже нельзя проверить на валидность, т.к. это уже UB.
Повторюсь, что совет появился как раз из-за исправления с vector на что-либо другое. Если количество элементов мало, то обычно нет разницы, какой контейнер. Если же оно большое, например 1 000 000, может быть deque будет все же эффективней?
И надо думать не только о том, какое количество вставок сейчас. А еще и на много лет вперед, когда проект будут поддерживать совсем другие люди.
Скажу, что мой совет относился к стандартным итераторам, в которых хранятся "большие" объекты. В случае чего-нибудь вроде int очень даже допустимо, что все будет с точностью наоборот, правильное замечание.
Согласен, что совет спорный. Сильно зависит от количество вставок и того, куда вставляется. Но я слишком часто на практике сталкивался с тем, что приходилось переделывать с vector на deque или list. Поэтому призываю думать, а не бездумно писать vector в надежде, что кто-нибудь потом регулярно будет прогонять код профайлером под изменившиеся условия и исправит, когда vector станет работать плохо.
Можно, используя подход "UDP hole punching". Правда не всегда.
Зря вы, не разобравшись, списываете удобный инструмент.
Это называется unix-way: "Write programs that do one thing and do it well.". Cmake — это генератор. И у него хорошо это получается. Отслеживание зависимостей хорошо получается у make/ninja и других инструментов.
Cmake умеет генерировать не только nmake/make, но и проекты для MSVC (https://cmake.org/cmake/help/v3.12/manual/cmake-generators.7.html). Как-то так:
cmake -G "Visual Studio 15"set rnuИ больше не надо думать, vim покажет номер строки.
Представьте, что вы создали большую компанию. Ради привлечения инвестиций часть акций продали на API, другую часть стратегическим партнерам. Но у вас остался контрольный пакет. Так вот, кому принадлежит большая часть активов этой компании? Разве ей самой?
И подумайте, кто как не владелец имеет решающий вес в вопросе о том, куда девать прибыль: возвращать акционерам в виде дивидендов или же инвестировать, в том числе с рискованные проекты?
Большая часть акций принадлежит государству. Как это, компания государственная, а деньги не государственные?
Спасибо за полезную информацию! В среди аббревиатур DMARC, DKIM и SPF не хватает ARC. Очень интересно, планирует ли почта mail.ru внедрение Authenticated Received Chain (http://arc-spec.org/)?
Нет, не просто. Еще нужно стрелочку вниз или page down нажать.
Идея хорошая, мне тоже приходится смотреть логи. Но ваше приложение, при попытке открыть лог размером 7 Гб (это всего за 3 часа работы), начало кушать 100% CPU и отъело кучу памяти, пока не было убито. У less же навигация по такому логу не вызывает затруднений.
Не означает. Об этом другой абзац:
Я прекрасно понимаю, что MapReduce не отомрет так быстро и они продолжают его использовать. У меня создалось впечатление, что они не считают MapReduce перспективной и универсальной технологией для big data.
Источник цитаты: http://www.datacenterknowledge.com/archives/2014/06/25/google-dumps-mapreduce-favor-new-hyper-scale-analytics-system/
По их словам, map reduce не справляется с обработкой действительно больших данных.
1. Обработчик сигналов не AS-Safe (https://www.gnu.org/software/libc/manual/html_node/POSIX-Safety-Concepts.html)
2. Обработчик исключений выделяет память, а что если она закончилась и произошло исключение std::bad_alloc?
3. Такое решение дает накладные расходы на каждый вызов.
4. Нет возможности получить стек вызова при использовании сторонних библиотек.
5.…
Не проще ли воспользоваться backtrace/backtrace_symbols в Linux или WinGdb на Windows?
Все еще никакой оптимизации со стороны компилятора.
И надо думать не только о том, какое количество вставок сейчас. А еще и на много лет вперед, когда проект будут поддерживать совсем другие люди.