перфект форвардинг и варарги

Если у тебя что-то помоложе гцц4.4 с хотя бы c++0x, где tr1 есть. Я этим как раз обделён.

я так понимаю ты хочешь какой-то легаси код так прозрачно завернуть?

я так понимаю ты хочешь какой-то легаси код так прозрачно завернуть?

Хотел цпп11 и более в цпп03.

эммм

Да, лол

Вот реально, если поделить на сий макрос мы получим время, ну то есть время работы программы. На сколько он точен - я не знаю. Проблема только одна - смешивание C кода с C++ ¿?

Мы получим процессорное время. Оно может быть как сильно меньше, так и в несколько раз больше, чем физическое время.

Быстрый вопрос. Если в юнионе у нас волатильная переменная, юнион будет считать волатильным?

Не

Только "наблюдаемое поведение" члена данных

быстрый вопрос: если стрелять в ногу из мортиры, можно ли считать что все остальное тело оторвало от ноги?

есть возможность промахнуться

Всем привет! А в стандарте С++11/14 до сих пор нужно при создании хоть одной виртуальной функции объявлять виртуальный деструктор, или с этим что-то сделали уже?

Всем привет! А в стандарте С++11/14 до сих пор нужно при создании хоть одной виртуальной функции объявлять виртуальный деструктор, или с этим что-то сделали уже?

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

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

да, чтобы при уничтожении вызывался деструктор наследника, а не базовго класса

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

Объявлять его виртуальным автоматически.

ну и что ты предлагаешь с этим сделать?

ну можно автоматом его добавлять, если есть хоть одна виртуальная функция

а если я не хочу вызывать деструктор наследника?

А есть такие кейсы?

а если я не хочу вызывать деструктор наследника?

ну а с фига ли ты не хочешь? :)

Всем привет! А в стандарте С++11/14 до сих пор нужно при создании хоть одной виртуальной функции объявлять виртуальный деструктор, или с этим что-то сделали уже?

Не было никогда такого требования

А есть такие кейсы?

ну я могу придумать парочку да

ну я могу придумать парочку да

давай, даже интересно стало

Не было никогда такого требования

пичаль беда

Быстрый вопрос. Если в юнионе у нас волатильная переменная, юнион будет считать волатильным?

Встречный вопрос. Зачем вообще волатильные переменные?

Причём возможны случаи, когда деструктор не должен быть виртуальным

Встречный вопрос. Зачем вообще волатильные переменные?

Вроде чтобы компилятор не соптимизировал

давай, даже интересно стало

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

Встречный вопрос. Зачем вообще волатильные переменные?

чтобы не кешировались операции чтения и записи

Встречный вопрос. Зачем вообще волатильные переменные?

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

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

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

тоже вариант

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

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

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

Обычно если используется просто volatile переменная, без барьеров, то где-то в программе баг. Если речь про многопоточность. Если нет, то мне любопытно применение.

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

ну и?

ещё публичный интерфейс может быть невиртуальным. а поведение объекта полиморфируется через защищённый интерфейс, который таки виртуальный

Обычно если используется просто volatile переменная, без барьеров, то где-то в программе баг. Если речь про многопоточность. Если нет, то мне любопытно применение.

Обмануть компилятор, когдя явное UB

ещё публичный интерфейс может быть невиртуальным. а поведение объекта полиморфируется через защищённый интерфейс, который таки виртуальный

ничего не понял сейчас, причет тут виртуальный деструктор?

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

ну так в этом случае не надо делать его виртуальным. по второму поводу то что Анатолий написал - у тебя есть контейнер vector<MyDerived> а функция принимает MyBase* виртуальные деструкторы не нужно, т.к. удаляешь ты их by value, в функицю передаешь по указателю, всё норм

ничего не понял сейчас, причет тут виртуальный деструктор?

А при том, что в virtual protected interface деструктор невиртуальный )

ну так в этом случае не надо делать его виртуальным. по второму поводу то что Анатолий написал - у тебя есть контейнер vector<MyDerived> а функция принимает MyBase* виртуальные деструкторы не нужно, т.к. удаляешь ты их by value, в функицю передаешь по указателю, всё норм

не нужно, но ничего плохого если он там и будет

а виртуальная функция может просто использоваться из обобщенной реализации struct processor { void process() { before(); doprocess(); after(); } virtual void before() = 0; virtual void doprocess() = 0; virtual void after() = 0; }; }

не надо в общем этого вашего "автоматически виртуальным" - это ДЕоптимизация получается

в данном случае, предполагается, что у тебя будут конкретные наследники

не нужно, но ничего плохого если он там и будет

таки у вас С++ и правда медленнее С?

Обмануть компилятор, когдя явное UB

А можно пример?

Я за то, что бы программисты знали что делают и почему делают. А не тупо следовали догматам

concreteprocess1 p1; p1.process(); concreteprocess2 p2; p2.process();

которые не предполагают полиморфного удаления

таки у вас С++ и правда медленнее С?

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

которые не предполагают полиморфного удаления

у меня все просто. Если ты не предпологаешь полиморфного удаления, значит не делай класс полиморфным :)

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

сожрет больше памяти на vtbl, доказал?

т.е. вирутальным :)

где мой пирожок

т.е. вирутальным :)

дык ортогональные вещи

полиморфное удаление и полиморфное поведение - я же тебе привел пример

сожрет больше памяти на vtbl, доказал?

нет, в современных компиляторах можно вообще без vtbl :)

полиморфное удаление и полиморфное поведение - я же тебе привел пример

ну т.е. твою задачу никак без полиморфизма не решить что ли? :)

нет, в современных компиляторах можно вообще без vtbl :)

мнээ, что

Ладно кароче, я свой вопрос выяснил, надо поработать теперь :)

А можно пример?

Есть некий шаблонный класс, который является враппером для синглетона. И у него есть bool inited. Который при инициализации ставится true, а в деструкторе false Но мы же знаем, что в С++ нельзя использовать объекты после вызова деструктора. Это UB. И компилятор знает. Поэтому любое присваивание мемберов класса в деструкторе он просто выкидывает. Зачем присваивать то, что не будет больше никогда использоваться? В результате, если у нас есть несколько синглетонов и один зависит от второго, то он может использовать его после удаления, так как флаг inited у него true и в деструкторе не очистился

еще миф ходит, что если в классе нет виртуального деструктора, то от него наследоваться опасно

Да ладно. Хорошая идея сделать создавать в таких классах витруальный деструктор по умолчанию и запрещать его явно. В большинстве случаев его отсутствие это баг. Но совершенно непонятно как это добавить в c++ сохраняя совместимость

вижу, что это одна гвардия

Да ладно. Хорошая идея сделать создавать в таких классах витруальный деструктор по умолчанию и запрещать его явно. В большинстве случаев его отсутствие это баг. Но совершенно непонятно как это добавить в c++ сохраняя совместимость

баг, если я буду удалять через базу

во всех остальных случаях нафиг не нужен виртуальный деструктор

а то слышал "ты отнаследовался от std::vector? но у него же нет виртуального деструктора"

Ну тут можно в holywars идти обсуждать, нужно ли вообще наследование в случаях отличных от интерфейса.

нет, я просто показал, что виртульная функция конкретизирующая поведение и виртуальный деструктор две ортогональные по назначению вещи

Иногда деструктор может быть и pure

гы-гы

но с реализацией, без реализации - pure virtual call

при попытке удалить объект такого класса

поскольку цепочку автоматического вызова деструктора ты прервать не можешь

Ага, важное уточнение :)

баг, если я буду удалять через базу

Проблема в том что ты не знаешь как будут юзать класс поэтому публичное наследование без Вирт деструктора опасно

ой, все

ты смотришь на публичный интерфейс и видишь, что можно делать, а что нельзя

это не кот в мешке, интерфейс тебе доступен

И что я там вижу? Вижу нет деструктора виртуального а мне прилетает указатель