АР
Насколько "всегда есть"? Сделать (Foo*)nullptr->Bar() это UB?
p.s. (*this).Bar() =)
p.s. (*this).Bar() =)
да
Size: a a a
2020 August 14
АР
начиная с с++11
AN
Можно вызвать наверное this на чем то невалидном
AN
Во кстати
Foo& Foo::bad() {
delete this;
return *this;
}
Foo& Foo::bad() {
delete this;
return *this;
}
CD
Можно вызвать наверное this на чем то невалидном
С точки зрения языка, на невалидном вызывать ничего нельзя, так что this валидный
CD
Во кстати
Foo& Foo::bad() {
delete this;
return *this;
}
Foo& Foo::bad() {
delete this;
return *this;
}
Ситуация не хуже, чем со ссылкой
CD
обычно формировать битые ссылки не стоит, но, увы, язык не запрещает (см. длинное обсуждение про формирование ссылки из nullptr)
ST
Всем привет! В boost mp11/fusion/hana есть что-нить вроде reverse_for_each ? Задача: нужен обратный цикл (итератор) по элементам std::tuple? В mp11 даже нет нормального for_each, в fusion и hana есть, но только прямой. Можно конечно по-старинке - сделать реверс из подобного:
двигаясь в обратном направлении по индексу, но хотелось бы что-то готовое из буста...
template<size_t Index = 0, typename TTuple, size_t Size = std::tuple_size_v<std::remove_reference_t<TTuple>>,
typename TCallable, typename... TArgs>
void for_each(TTuple &&tuple, TCallable &&callable, TArgs &&... args) {
if constexpr (Index < Size) {
std::invoke(callable, args..., std::get<Index>(tuple));
if constexpr (Index + 1 < Size) {
for_each<Index + 1>(std::forward<TTuple>(tuple), std::forward<TCallable>(callable), std::forward<TArgs>(args)...);
}
}
}двигаясь в обратном направлении по индексу, но хотелось бы что-то готовое из буста...
FZ
Всем привет! В boost mp11/fusion/hana есть что-нить вроде reverse_for_each ? Задача: нужен обратный цикл (итератор) по элементам std::tuple? В mp11 даже нет нормального for_each, в fusion и hana есть, но только прямой. Можно конечно по-старинке - сделать реверс из подобного:
двигаясь в обратном направлении по индексу, но хотелось бы что-то готовое из буста...
template<size_t Index = 0, typename TTuple, size_t Size = std::tuple_size_v<std::remove_reference_t<TTuple>>,
typename TCallable, typename... TArgs>
void for_each(TTuple &&tuple, TCallable &&callable, TArgs &&... args) {
if constexpr (Index < Size) {
std::invoke(callable, args..., std::get<Index>(tuple));
if constexpr (Index + 1 < Size) {
for_each<Index + 1>(std::forward<TTuple>(tuple), std::forward<TCallable>(callable), std::forward<TArgs>(args)...);
}
}
}двигаясь в обратном направлении по индексу, но хотелось бы что-то готовое из буста...
не буст, но кажется видел как бригандом делали что-то вроде
brigand::for_each<brigand::reverse<std::tuple<....>>>(...), можно посмотреть https://github.com/edouarda/brigand/
FZ
Всем привет! В boost mp11/fusion/hana есть что-нить вроде reverse_for_each ? Задача: нужен обратный цикл (итератор) по элементам std::tuple? В mp11 даже нет нормального for_each, в fusion и hana есть, но только прямой. Можно конечно по-старинке - сделать реверс из подобного:
двигаясь в обратном направлении по индексу, но хотелось бы что-то готовое из буста...
template<size_t Index = 0, typename TTuple, size_t Size = std::tuple_size_v<std::remove_reference_t<TTuple>>,
typename TCallable, typename... TArgs>
void for_each(TTuple &&tuple, TCallable &&callable, TArgs &&... args) {
if constexpr (Index < Size) {
std::invoke(callable, args..., std::get<Index>(tuple));
if constexpr (Index + 1 < Size) {
for_each<Index + 1>(std::forward<TTuple>(tuple), std::forward<TCallable>(callable), std::forward<TArgs>(args)...);
}
}
}двигаясь в обратном направлении по индексу, но хотелось бы что-то готовое из буста...
а, пардон, не дочитал сообщение. по элементам же
AN
обычно формировать битые ссылки не стоит, но, увы, язык не запрещает (см. длинное обсуждение про формирование ссылки из nullptr)
Это хуже, чем nullptr. Я самоубился
CD
Это хуже, чем nullptr. Я самоубился
Тут нет ничего хуже, чем обычная ссылочная семантика
AN
Dangling reference получается
2020 August 15
..
Привет всем. Такая ситуация. Мне нужно собирать модуль для апача, который принимает .o файл. Я собираю много .o из исходников с помощью Cmake типа вот такого:
add_library(router OBJECT ${PROJECT_SOURCE_DIR}/src/router/Router.cpp)
target_include_directories(router PUBLIC ${PROJECT_SOURCE_DIR}/lib/own)
А сборка объекта в makefile выглядит вот так:
Router.o : $(s_router)/Router.cpp $(i_router)/Router.h \
g++ $(GCC_COMPILE) $(s_router)/Router.cpp
Вопросы: 1) после компиляции этот объект (.o) можно использовать для ручной линковки в Makefile'e (так нужно для того чтобы один большой .o файл поместить как параметр сборки для apxs сборки для апача) или там есть какая - то метаинфа о CMake и так делать нельзя?
2) они .o Cmake'а весят в 2-3 раза меньше если собирать руками эти объекты. Почему так? Типа ручками получается: 11356 а Cmake выдает 2416 размера всех сгенереных объектов.
add_library(router OBJECT ${PROJECT_SOURCE_DIR}/src/router/Router.cpp)
target_include_directories(router PUBLIC ${PROJECT_SOURCE_DIR}/lib/own)
А сборка объекта в makefile выглядит вот так:
Router.o : $(s_router)/Router.cpp $(i_router)/Router.h \
g++ $(GCC_COMPILE) $(s_router)/Router.cpp
Вопросы: 1) после компиляции этот объект (.o) можно использовать для ручной линковки в Makefile'e (так нужно для того чтобы один большой .o файл поместить как параметр сборки для apxs сборки для апача) или там есть какая - то метаинфа о CMake и так делать нельзя?
2) они .o Cmake'а весят в 2-3 раза меньше если собирать руками эти объекты. Почему так? Типа ручками получается: 11356 а Cmake выдает 2416 размера всех сгенереных объектов.
AN
Привет всем. Такая ситуация. Мне нужно собирать модуль для апача, который принимает .o файл. Я собираю много .o из исходников с помощью Cmake типа вот такого:
add_library(router OBJECT ${PROJECT_SOURCE_DIR}/src/router/Router.cpp)
target_include_directories(router PUBLIC ${PROJECT_SOURCE_DIR}/lib/own)
А сборка объекта в makefile выглядит вот так:
Router.o : $(s_router)/Router.cpp $(i_router)/Router.h \
g++ $(GCC_COMPILE) $(s_router)/Router.cpp
Вопросы: 1) после компиляции этот объект (.o) можно использовать для ручной линковки в Makefile'e (так нужно для того чтобы один большой .o файл поместить как параметр сборки для apxs сборки для апача) или там есть какая - то метаинфа о CMake и так делать нельзя?
2) они .o Cmake'а весят в 2-3 раза меньше если собирать руками эти объекты. Почему так? Типа ручками получается: 11356 а Cmake выдает 2416 размера всех сгенереных объектов.
add_library(router OBJECT ${PROJECT_SOURCE_DIR}/src/router/Router.cpp)
target_include_directories(router PUBLIC ${PROJECT_SOURCE_DIR}/lib/own)
А сборка объекта в makefile выглядит вот так:
Router.o : $(s_router)/Router.cpp $(i_router)/Router.h \
g++ $(GCC_COMPILE) $(s_router)/Router.cpp
Вопросы: 1) после компиляции этот объект (.o) можно использовать для ручной линковки в Makefile'e (так нужно для того чтобы один большой .o файл поместить как параметр сборки для apxs сборки для апача) или там есть какая - то метаинфа о CMake и так делать нельзя?
2) они .o Cmake'а весят в 2-3 раза меньше если собирать руками эти объекты. Почему так? Типа ручками получается: 11356 а Cmake выдает 2416 размера всех сгенереных объектов.
1. Можно ручками линковать
2. Разница в флагах?
2. Разница в флагах?
AN
Можно сделать make VERBOSE=1 и видно будет что передаётся компилеру/линкеру на вход(у CMake)
..
Различие во флагах есть, да
IZ
Привет всем. Такая ситуация. Мне нужно собирать модуль для апача, который принимает .o файл. Я собираю много .o из исходников с помощью Cmake типа вот такого:
add_library(router OBJECT ${PROJECT_SOURCE_DIR}/src/router/Router.cpp)
target_include_directories(router PUBLIC ${PROJECT_SOURCE_DIR}/lib/own)
А сборка объекта в makefile выглядит вот так:
Router.o : $(s_router)/Router.cpp $(i_router)/Router.h \
g++ $(GCC_COMPILE) $(s_router)/Router.cpp
Вопросы: 1) после компиляции этот объект (.o) можно использовать для ручной линковки в Makefile'e (так нужно для того чтобы один большой .o файл поместить как параметр сборки для apxs сборки для апача) или там есть какая - то метаинфа о CMake и так делать нельзя?
2) они .o Cmake'а весят в 2-3 раза меньше если собирать руками эти объекты. Почему так? Типа ручками получается: 11356 а Cmake выдает 2416 размера всех сгенереных объектов.
add_library(router OBJECT ${PROJECT_SOURCE_DIR}/src/router/Router.cpp)
target_include_directories(router PUBLIC ${PROJECT_SOURCE_DIR}/lib/own)
А сборка объекта в makefile выглядит вот так:
Router.o : $(s_router)/Router.cpp $(i_router)/Router.h \
g++ $(GCC_COMPILE) $(s_router)/Router.cpp
Вопросы: 1) после компиляции этот объект (.o) можно использовать для ручной линковки в Makefile'e (так нужно для того чтобы один большой .o файл поместить как параметр сборки для apxs сборки для апача) или там есть какая - то метаинфа о CMake и так делать нельзя?
2) они .o Cmake'а весят в 2-3 раза меньше если собирать руками эти объекты. Почему так? Типа ручками получается: 11356 а Cmake выдает 2416 размера всех сгенереных объектов.
Что-то для сборки модуля апача у тебя вопросы странные...
AP
Новый Boost зарелизился https://www.boost.org/users/history/version_1_74_0.html
Из самого вкусного:
* ASIO ускорился и дополнительно оброс корутинами
* Atomic теперь умеет многое полезное из C++20 (например wait)
* MultiIndex научился выдавать пользователям ноды
Из самого вкусного:
* ASIO ускорился и дополнительно оброс корутинами
* Atomic теперь умеет многое полезное из C++20 (например wait)
* MultiIndex научился выдавать пользователям ноды
AP
Из забавного: Embarcadeo (бывший компилятор Borland) зашевелился и теперь шлёт патчи в Boost (последняя официально оттестированная на Boost версия Borland была ~40 релизов назад)