Не секрет, что стандартный аллокатор new/delete/malloc/free в языке C/C++ не блещет быстродействием. Конечно, всё зависит от реализации, но, если говорить об оной от компании Microsoft, то это факт.
Факт ли? Вот например создатель ned malloc утверждает, что в современных OS системные аллокаторы очень хороши.
To my knowledge, nedmalloc is among the fastest portable memory allocators available, and it has many features and outstanding configurability useful in themselves. However it cannot consistently beat the excellent system allocators in Windows 7, Apple Mac OS X 10.6+ or FreeBSD 7+ (and neither can any other allocator I know of in real world testing).
И кому в данном случае верить: создателю одного из альтернативных аллокаторов или Вашим голословным утверждениям, которые сделаны для рационализации сомнительных велосипедов?
Мейкфайлы, конечно, вполне себе ужасны. И тем не менее, язык мейкфайлов — вполне себе декларативный язык. Мейкфайлы описывают ациклический граф, в узлах которого — как раз ваши файлы в проекте. Иерархические файлы, зависимости, флаги компиляции — все это можно реализовать.
По поводу формата файла проекта в стандарте языка. Для больших мейнстримовых языков: 1) поздно уже, поезд ушел. Да и на разных платформах — разные исторические традиции. 2) комитеты типа С++ никогда не договорятся; 3) всегда будут те, кому встроенный формат не подойдет, потому что не решит некоторых задач; 4) вместо того, чтобы сосредоточиться на разработке 1 языка, надо будет разработать 2 языка.
у J есть ниша – обработка данных, особенно в финансовой сфере
Что-то, с учетом недавней статьи про IT в банках, мне кажется, что J в финансовой сфере привлекателен, в первую очередь, как раз своей мало-читаемостью.
Можно было бы еще легко поудалять всю ту тонну статей из облака — было бы совсем хорошо. А то висят мертвым грузом, засоряют список.
На странице аккаунта статьи удаляются по одной, после чего страница перезагружается.
Безотносительно решения, приведенного в статье (по нему ничего сказать не могу), shared folders в virtual box:
1) периодически отваливаются. Содержимое файлов просто перестает меняться.
2) постоянно портят таймстампы файлов. make не очень любит файлы, измененные в будущем.
Да ладно, проще некуда. Просто катапультировать наружу всех людей из машины. Внутри машины — никто не погибнет. А то, что снаружи творится — машины уже не касается.
В машинах самого высокого класса, к катапультирующим сиденьям будут даже прилагаться парашюты.
Ок, это отвечает на первый вопрос. Но это мелочи.
Меня больше интересует, насколько верно мое рассуждение, что современные умные указатели настолько умные, что ничего делать не надо, а все есть?
А зачем функцию std::unique_ptr< MyClass > create() const оставлять в хедере? В данном случае, я не вижу проблемы того, что unique_ptr будет создан в библиотеке. Сам по себе unique_ptr память не выделяет.
Более того, мне кажется, что и определять свой собственный default_delete< MyClass > не обязательно. Если создавать в объект unique_ptr внутри библиотеки, не указывая deleter, будет создан объект класса по умолчанию и отдан unique_ptr-у по значению. Когда мы будем отдавать unique_ptr, то deleter будет перемещен в новый unique_ptr. То есть, клиент получит deleter из библиотеки.
Суммируя, библиотека должна просто создавать отдавать unique_ptr или shared_ptr и все должно работать само по себе. Или я что-то упускаю?
И в тоже время видно, как линия прорисовывается с секундной задержкой. Я никогда не видел вживую и не пользовался планшетами для рисования — неужели там тоже все так плохо?
Факт ли? Вот например создатель ned malloc утверждает, что в современных OS системные аллокаторы очень хороши.
www.nedprod.com/programs/portable/nedmalloc/
И кому в данном случае верить: создателю одного из альтернативных аллокаторов или Вашим голословным утверждениям, которые сделаны для рационализации сомнительных велосипедов?
По поводу формата файла проекта в стандарте языка. Для больших мейнстримовых языков: 1) поздно уже, поезд ушел. Да и на разных платформах — разные исторические традиции. 2) комитеты типа С++ никогда не договорятся; 3) всегда будут те, кому встроенный формат не подойдет, потому что не решит некоторых задач; 4) вместо того, чтобы сосредоточиться на разработке 1 языка, надо будет разработать 2 языка.
Что-то, с учетом недавней статьи про IT в банках, мне кажется, что J в финансовой сфере привлекателен, в первую очередь, как раз своей мало-читаемостью.
Есть что-то в стремлении людей использовать инструменты не по назначению.
На странице аккаунта статьи удаляются по одной, после чего страница перезагружается.
1) периодически отваливаются. Содержимое файлов просто перестает меняться.
2) постоянно портят таймстампы файлов. make не очень любит файлы, измененные в будущем.
По крайней мере, так было 2 года назад.
В машинах самого высокого класса, к катапультирующим сиденьям будут даже прилагаться парашюты.
Меня больше интересует, насколько верно мое рассуждение, что современные умные указатели настолько умные, что ничего делать не надо, а все есть?
std::unique_ptr< MyClass > create() constоставлять в хедере? В данном случае, я не вижу проблемы того, чтоunique_ptrбудет создан в библиотеке. Сам по себеunique_ptrпамять не выделяет.Более того, мне кажется, что и определять свой собственный
default_delete< MyClass >не обязательно. Если создавать в объектunique_ptrвнутри библиотеки, не указывая deleter, будет создан объект класса по умолчанию и отданunique_ptr-у по значению. Когда мы будем отдаватьunique_ptr, то deleter будет перемещен в новыйunique_ptr. То есть, клиент получит deleter из библиотеки.Суммируя, библиотека должна просто создавать отдавать
unique_ptrилиshared_ptrи все должно работать само по себе. Или я что-то упускаю?edit: вдогонку, ссылка, подтверждающая мою мысль stackoverflow.com/a/5835036/661451
И в тоже время видно, как линия прорисовывается с секундной задержкой. Я никогда не видел вживую и не пользовался планшетами для рисования — неужели там тоже все так плохо?