В реализации STL в Visual Studio 2012 стандартный аллокатор тоже вызывает "::operator new(size)", а не malloc. В реализациях Apache stdcxx и libc++ делается то же самое.
Вообще странно бы было, если бы стандартный аллокатор пытался бы вызывать malloc, когда есть возможность вызвать new и предоставить возможность его глобального переопределения.
Стандартный аллокатор в реализация STL в gcc вызывает не malloc, а "::operator new(size)", как раз для того, чтобы можно было переопределить этот new глобально для всего приложения.
Ну первый вариант подходит только для тестирования по понятным причинам: добавлять установку этих переменных в сам проект нельзя, они зависят от среды сборки.
Второй вариант может работать, но это неудобно, и не факт что всегда будет работать. Т. е. сначала будет запускаться cmake, отрабатывать наполовину, создавать половину кэша, потом пользователь вручную добавляет нужные переменные в кэш, потом перезапускает cmake.
Проще было бы, если бы была возможность задать параметры cmake (как в QtCreator). Ну и каталог сборки неплохо было бы самому выбирать, а то сейчас это всё прячется где-то в ~/.clion10
Под Linux системный gcc определился, простые проекты собирает. А есть возможность указать опции cmake, которые будут использоваться при конфигурации проекта? Без указания опций мой проект не собирается (cmake завершается с ошибкой).
Установил версию для Windows. Не могу настроить mingw toolchain. mingw установлен в C:\mingw, указываю этот путь в поле «Use MinGW home», пишет «MinGW not found». Можно узнать подробнее какой конкретно MinGW нужен и как определяется его наличие в каталоге? Может там каких файлов у меня не хватает.
Как раз наоборот. Этот итог наступает очень быстро только у теоретиков. На практике же " критические по скорости участки кода переписываем на С/С++". Давайте уже конкретные примеры, если действительно это наступает на практике, а не в умах теоретиков.
Конечно расширяется, кто спорит то? Потом вы его расширите на функциональные объекты (с перегруженным оператором (), в том числе другие делегаты), потом расширите на биндинг параметров, потом сделаете имитацию лямбд с помощью операторов и placeholder'ов, и получитие boost.function + boost.bind + boost.lambda. Какой смысл, если нормальные лямбды уже на подхоже, и даже уже есть в msvs и gcc?
Профит в том, что делегатом может быть любая функция без параметров, а не только функция-член какого-то класса. Ну или например функция/функция-член, которой передаются какие-то дополнительные параметры:
На С++ описанные в посте конструкции уже лет 10 во всю используются, + имитация лямбд + каррирование (binding параметров). Так что скорее пишешь на Java, хочется на С++.
> Тем кто заинтерисован в производительности.
Тем, кто заинтересован в производительности, нужна в первую очередь минимизация количества операций с памятью. Очень удобно наверное выдернуть из трёх абзацев одну фразу и обсуждать её.
> Мир компиляторов не ограничивается GCC, VC.
Ну так покажите нам крутые компиляторы, которые рожают высокопроизводительный код для ARM, MIPS, PPC
> Кодогенератор правда придется покодировать…
Уже нет. Берёте LLVM и базовый компилятор готов. После этого уже можно заниматься «крутыми оптимизациями».
Вообще странно бы было, если бы стандартный аллокатор пытался бы вызывать malloc, когда есть возможность вызвать new и предоставить возможность его глобального переопределения.
Второй вариант может работать, но это неудобно, и не факт что всегда будет работать. Т. е. сначала будет запускаться cmake, отрабатывать наполовину, создавать половину кэша, потом пользователь вручную добавляет нужные переменные в кэш, потом перезапускает cmake.
Проще было бы, если бы была возможность задать параметры cmake (как в QtCreator). Ну и каталог сборки неплохо было бы самому выбирать, а то сейчас это всё прячется где-то в ~/.clion10
Мне надо запускать проект с несколькими опциями примерно так:
cmake -DVAR1=value1 -DVAR2=value2 <path_to_sources>
Переменных VAR1 и VAR2 в кэше нету.
std::string name(raw_name);
Точка.
в каком итоге и когда уже этот итог наконец наступит?
А потом начали куске на Це переписывать: lionet.livejournal.com/84884.html
=))
test_delegate.Connect([&test_class] { test_class.Foo(10, 20, 30, 40); });
Да и вообще, можно саму обработку кода прям в внутрь лямбды поместить.
Вот так:
Victim test_class; Delegate test_delegate; test_delegate.Connect([&test_class] { test_class.Foo(); });Забудьте вы уже этот С++2003, используйте C++0x! ;)
Тем, кто заинтересован в производительности, нужна в первую очередь минимизация количества операций с памятью. Очень удобно наверное выдернуть из трёх абзацев одну фразу и обсуждать её.
> Мир компиляторов не ограничивается GCC, VC.
Ну так покажите нам крутые компиляторы, которые рожают высокопроизводительный код для ARM, MIPS, PPC
Уже нет. Берёте LLVM и базовый компилятор готов. После этого уже можно заниматься «крутыми оптимизациями».