внезапно вброс ~X() = 0 = default; и наоборот, ~X() = default = 0;

внезапно вброс ~X() = 0 = default; и наоборот, ~X() = default = 0;

Так можно? 0_о

внезапно вброс ~X() = 0 = default; и наоборот, ~X() = default = 0;

Што)

не могу гугл спросить

"как работают исключения"

Так можно? 0_о

нет, это ололо-хотелка на 23й стандарт

Фух

"как работают исключения"

а там описано как отреагирует С контекст на исключение из C++ контекста?

возникла на волне обсуждения "а почему язык вообще позволяет ~X()=0; и молча срёт в тапки если ты забыл сделать определение чисто-виртуального деструктора"

внезапно вброс ~X() = 0 = default; и наоборот, ~X() = default = 0;

Поясни тогда семантику

а там описано как отреагирует С контекст на исключение из C++ контекста?

нет конечно, и нигде не написано но из этого можно понять, что будет на конкретной платформе, если исключение не ловить

Поясни тогда семантику

хотеть: // a.h class Base { ~Base() = 0; }; не хотеть: // a.cpp Base::~Base() {}

но выше правильно ответили, что ничего хорошего не будет

хотеть: // a.h class Base { ~Base() = 0; }; не хотеть: // a.cpp Base::~Base() {}

А зачем и =0, и =defaul

А зачем и =0, и =defaul

если не делать ~Base() {}, то наследник от Base при уничтожении вызовет несуществующий деструктор, и откроются ворота в адъ

=default ворота не закрывает?

ну вот как будто бы да, ворота можно закрыть с помощью =default, потому что по сути именно дефолтную реализацию сейчас и приходится писать руками

А зачем ещё и =0?

затем что нужен pure virtual class :)

Сделай protected конструктор

да-да, когда-то я приходил с такой идеей на SO) https://stackoverflow.com/questions/33299273/pure-virtual-destructor-vs-protected-constructor-virtual-dtor

Сделай protected конструктор

из наследника можно будет родителя тогда создать

"At a more conceptual level, if you are trying to make a class abstract, then make it abstract. "

из наследника можно будет родителя тогда создать

Строго говоря, ты и чисто виртуальный деструктор для базового из производного вызвать можешь, это C++ :)

Строго говоря, ты и чисто виртуальный деструктор для базового из производного вызвать можешь, это C++ :)

можно, но речь то о конструкторе

или это к тому что из наследника сломать можно что угодно?

А зачем нужен чисто виртуальный класс, если из виртуального там только деструктор?

или это к тому что из наследника сломать можно что угодно?

Да

Строго говоря, ты и чисто виртуальный деструктор для базового из производного вызвать можешь, это C++ :)

ага, http://www.gotw.ca/gotw/031.htm см. "Force Conscious Acceptance of Default Behaviour"

А зачем нужен чисто виртуальный класс, если из виртуального там только деструктор?

а это уже вопрос дебильности архитектуры ? от балды - в конструкторе регистрируем себя в где-нибудь, в деструкторе вычищаем, и всё это какая-нибудь GameBasicEntity

а это уже вопрос дебильности архитектуры ? от балды - в конструкторе регистрируем себя в где-нибудь, в деструкторе вычищаем, и всё это какая-нибудь GameBasicEntity

то есть деструктор уже не по умолчанию

и есть

вторая попытка ?

то есть деструктор уже не по умолчанию

и то верно)

Зачм нужно '''std: :auto_ptr<T>'''?

не нужно уже, его выкинули на мороз, используй std::unique_ptr

Зачм нужно '''std: :auto_ptr<T>'''?

Это плохая версия std::unique_ptr

unique_ptr это умный указатель

позволяет не забыть освободить выделенную руками память

не плохая, а единственно возможная на тот момент

не плохая, а единственно возможная на тот момент

от того что единственно возможная - не делает её хорошей

но и плохой тоже

она нейтрайльная, да имеет свои недостатки, как и прочие смарт-указатели в С++.

ну, уник-птр пофиксил недостатки auto_ptr'а

и как бы уже без разницы ибо устарел этот тип и удалён

ну, уник-птр пофиксил недостатки auto_ptr'а

и те что касались создание-удаление массивов?

unique_ptr<T[]>

но вообще я б подебажил, чтоб хотя б понять, что ему там надо хоть

Я дебажу профайлер :)

Я дебажу профайлер :)

наш человек!

наш человек!

Да, кстати, войс в про.асм можешь выписать?

Да, кстати, войс в про.асм можешь выписать?

да

Спасибо

unique_ptr<T[]>

и таки инициализацию массива не внесли

давай закинем DR/пропосал на stdcpp.ru

я пока не знаю как унифицированно это сделать

unique_ptr<T[]>

но зачем?

можно initialized_list

но зачем?

дуболомная замена new T[] ж)

в целом да

дуболомная замена new T[] ж)

ненужно ведь)

Какой вы компилятор используете?

Какой вы компилятор используете?

gcc

Какой вы компилятор используете?

gcc,clang,msvc,icc

clang

clang, gcc

Я дебажу профайлер :)

Лучше профайлить дебагер, чем дебажить профайлер.

gcc,clang,msvc,icc

о, всегда было любопытно как (качественно) работает icc можешь в двух словах рассказать?

о, всегда было любопытно как (качественно) работает icc можешь в двух словах рассказать?

лучше векторизует ?

Лучше профайлить дебагер, чем дебажить профайлер.

Вот как закончу, так и сразу переключусь. Мне там страсть как надо нормальные pretty printer's сделать

лучше векторизует ?

даже если шланги/гцц со всей пачкой параметров?

о, всегда было любопытно как (качественно) работает icc можешь в двух словах рассказать?

В двух?

даже если шланги/гцц со всей пачкой параметров?

ага. но разница с gcc небольшая. gcc местами даже шустрее

но gcc/icc лучше шланга/msvc

ага. но разница с gcc небольшая. gcc местами даже шустрее

шустрее работает или код более оптимизированный?

Все не так однозначно

шустрее работает или код более оптимизированный?

код более оптимизированный

но gcc/icc лучше шланга/msvc

угу, тоже для себя отмечал

кого интресует - ищите бенчмарки ч чате. я кидал

Интеловский компилятор без интеловских либ, тулзов и ПРОЦА мало пользы несет :)

А вот все в куче если, то уже есть смысл

Интеловский компилятор без интеловских либ, тулзов и ПРОЦА мало пользы несет :)

естесственно разговор про интеловские процы

Ничего не естественно. Кому-то критично под АРМ

или под PowerPC