Russian Qt Forum

Никакого практического либо теоретического смысла данный пост не имеет.
Это просто рассуждения в субботний вечер.

Зачем собственно в хедерах приватные функции?
Краеугольный камень ООП, скрыть реализацию. Реализация, как правило, в протектед и в приват. Если с протектед все понятно, то зачем же сувать приватные функции в хеадер. Они спокойно могли бы жить в cpp.

Да, может быть визуально проще читать класс в хедере.
Но! Это противорчит самой концепции ООП, мы вообще о них не должны ничего знать, а во вторых, вон исходники Qt читаем, и ничего с их приватными классами.
Где, где хоть один плюс при использовании приватный функций в хедере - кроме того что так принято и ожидаемо.

Я не спорю, есть случаи с френд классами, так же с дебагом, где при определённых условиях мы можем повышать область видимости. Но это все частные случаи.

ПЛЮСЫ отсутсвия приватных функций в хедере малозначительны, но все же есть.
Убыстряем компиляцию (при изменении хедера)
Уменьшаем простыню хедера

МИНУСЫ
Все таки мы ожидаем, что приватные функции есть, и может ступор быть в 2-3 секунды при их отсутствии.
Как то хаком все таки возможно сделать приват видимым в наследуемом классе. Ну, тут люд такой, что не думаю будет пользоваться таким приемом.
Ваш вариант.

Прошу прощения модератора, промазал, если не лень, перенесите топик в говорилку.

PIMPL, в Qt этот паттерн активно используется.

Да все знают, что он там используется. Когда Вы пишете не для разработчиков Qt, вы пишите, так как пишите, по старинке. У Qt своя парадигма, вы же под неё не подстраиваетесь. Тем более, что официально у них  - для бинарной совместимости. Какая такая бинарная совместимость у мелкого, даже пусть крупного проекта. Просто любой "крупный" Ваш проект мелкий по сравнению с Qt, и, тем более, конечный, в отличии от Qt.

Опять видно вопрос не верно задал и не те акценты расставил.

Хорошо, сформулирую лаконично - при каких условиях кто-то или Вы согласится перейти на эту парадигму.

Я специально не спросил про Qt. Я акцент сделал на C++, как таковой. Приватные классы и прятанье приватов - это разный уровень, не все готовы тратить на разработку! и продуманость столько времени.

Чтобы не было дальше сравнений с Qt  - http://habrahabr.ru/post/76248/

И самое важное, при прятаньи приватов в cpp для нас ничего не изменяется, не создаются объекты приватные (в случае Qt), нам не нужно думать, что при выделение тисячи объектов (не редкий случай) все пройдет гладко.

Я его использую, в основном по этим причинам (из статьи, что вы привели):
5. Увеличивается скорость сборки приложения (что очень актуально).
6. Прячется вся ненужная реализация от клиента, в отличие от приватных методов, pimpl объявление и реализацию не видно вообще.

У меня будет просьба к Вам - не спешите отвечать на этот пост.
Согласен со всеми Вашими пунктами.
Но! Я Вам говорил про то же самое, а Вы мне привели идеологию Qt. При чём здесь сокрытие приватный функций и приватные классы?
Ну как минимум никакой new не вызывается. Вы посмотрите продуманность классов Qt. У меня нету столько ресурсов, чтобы это реализовать.Мало того, не все классы Qt имеют приватные классы. Для меня вообще удивительно, Qt пошло по принципу медленной эволюции, где на этом же принципе загнулись все проекты - либо обрасли хламом (пример gtk), либо ушли в бездну. С каждой версией настолько мелкие изменения, однако как паровоз вперёд летит. Мы можем себе такое позвоилить, оглядываясь на команду разработчиков Qt? Да конечно нет.
Ничего там не прячется. Вы клиент Qt, и что? От вас прячется реализация приватных классов? Каким образом?

Добрый!

Скажу так:
С точки зрения работоспособности кода - возможно надобности нет.
Но.
1. С точки зрения ООП (объектно-ориентированного проектирования) их наличие необходимо. Подробности опущу.
2. Полнота класса должна быть т.к. класс может быть унаследован и некоторые методы могут, для примера, не/стать virtual. Или появиться собственная реализация. Или разделиться на части.....
3. Так-же отсутствие подобного механизма в заголовке серьезно будет мешать принципу циклической разработки при том-же ООП (только в данном случае программировании).

Но это на вскидку.
А на мой, лично, взгляд главное это целостность описания при применении ООП.

Ну просто так их нельзя не писать. Делать PIMPL - ну не знаю. Пока не назреет необходимость какой-то "еще реализации" это просто засорение кода делегированием "на всякий случай".

Вообще я часто начинаю класс - все public. Если в какой-то момент чувствую что-то пошло не так - вот тогда закрываю члены в private и дописываю нужные геттеры/сеттеры. Казалось бы, почему не "сделать сразу правильно" - все private. Такая приватность часто оказывается "псевдо", фактически public, формально прикрытый get/set

краеугольный камень ООП - инкапсуляция, а вовсе не сокрытие данных.

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

однако инкапсуляция не ставит перед собой цель эти самые детали скрыть.

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

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

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

Не было такого, я писал: "PIMPL, в Qt этот паттерн активно используется."
Просто в Qt уже есть удобный набор средств для использования этого паттерна. Пишите свои методы, не будете ни от кого зависеть.

У меня для этого визард есть, все делается очень быстро.

Как минимум, в IDE "автодополнятор" видит только то что нужно, без всякого приватного "мусора".

Считаю, что приватные методы - это излишество языка.
public и protected вполне достаточны для поддержки ООП-идеологии.
Наличие private на практике только мешает - иначе бы не было введено костыля типа friend-классов.

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

Встречный вопрос - зачем?

Чтобы показать, что приватная часть используется только в наследуемом классе. Тем самым отделяем частное от общего.

инвариант? не, не слышал.

Отлично, а теперь представьте, что вам необходимо отнаследоваться и изменить или расширить приватную часть в наследнике. Код в дллке, исходники отсутствуют (сторонняя либа), что делать будем?

Наличие приватных методов не гарантирует инвариантность объекта. Для это в принципе достаточно инициализации в конструкторе, если она выполнена должным образом.

приватная часть - это внутренняя реализация этого класса
если создатель класса поместил чтото в приват, значит он показывает этим - это мое, не лезь сюда.
если ты пользователь класса - тебе в паблик
если ты наследник - ты можешь еще и protected
пользовать dll без исходников - ССЗБ )

А если там Большой Багъ ?


А если либа коммерческая ?

Я не троллинга ради, это реальная проблема, которая возникает время от времени. Необходимо изменить реализацию приватной части в наследнике. protected - это отличный способ сказать человеку, что реализация внутренняя и так просто ее менять не следует. А что говорит приват? Только то, что код очень сильно завязан на конкретной последовательности обработки данных, и, типа, "работает - не трогай". Но, как правило, именно там и "не работает" :)

писать баг репорт, жаловаться, избегать вообще таких либ (если возможно) и такой разработки )

если ее написали криво, то конструкция языка в этом не виноваты же )

можно написать отдельное приложение с этой либой - упадет, перезапустить, не мешая основной программе

Такой хакинг оправдан только в случае острой необходимости, ибо не гарантирует работоспособности кода после правки переменных.
Одним изменением можно завести класс в тупик, из которого нет выхода.

наличие инкапсуляции ещё не гарантия инварианта.
но её отсутствие - точно сводит инвариант на нет.

protected, отличное средство для инкапсуляции :)

а наличие private подрывает один из принципов ООП - наследуемость.

1.
private ничего не подрывает.
лишь определяет контракт.

2.
вы в любом случае наследуете весь функционал и данные базового класса.
другое дело, что вы не всегда имеете к нему доступ.
и это не случайно. см пункт 1.

Приведите пример НЕОБХОДИМОГО использования private, а не protected. Т..е. когда без него либо совсем не обойтись, либо преимущества настолько велики.

приведите пример НЕОБХОДИМОГО использования модификаторов доступа вообще,
а так же квалификаторов const.

вы похоже не осознаете, насколько глупа ваша просьба.

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

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

но вы сами можете взять эти самые книжки и просто прочитать.
например: "Совершенный код" Макконелла.

Пример необходимости const? Да ради бога. C помощью const вы сообщаете компилятору, что данный метод либо переменная являются в принципе константными. Возьмем, например, метод

bool doSomething(const QList& listIn, QList& listOut) const
{
...
}

const QList& listIn обозначает то, что listIn не должен меняться внутри doSomething. Во-первых, программист, видя это определение, понимает, что listIn является входным параметром, в отличие от listOut, а во-вторых, это дает больше возможностей компилятору оптимизировать данный код.

const в конце doSomething означает, что сам по себе метод не предполагает изменений состояния объекта (чем не инваринт?), а значит, написать в коде что-то типа

m_member = listIn;

компилятор не позволит, пока m_member не будет объявлен как mutable в заголовке класса.

И не надо меня тыкать в книжки и прочую документацию. Я в своей жизни много всего перечитал. Как правило, теория и практика - вещи не всегда совместимые (хотя академику-теоретику этого, увы, не дано понять, уж простите).

Прежде чем обвинять людей в том, что они идиоты, докажите это. Не повторяйте книжные фразы. Просто приведите пример преимущества private против protected. Как видите, "глупую" просьбу насчет const я выполнил :)

Не все можно исчерпать примерами, но преимущества private (как и const) действительно могут быть очень велики. Они позволяют программисту сделать "утверждение", проводить какую-то (не побоюсь этого слова) концепцию. Правильна она или нет - др вопрос. Да, это часто конфликтует с "гибкостью", c'est la vie

Да и вообще полемика довольно беспредметна, мол, "мне не нравится это". Плохо или хорошо - но оно так будет, и наши симпатии ничего не изменят. Не навязывают идиотскую "классовость" как в др языках - и слава богу, радуйтесь жизни  :)

Просто получается, что все, что находится в привате - не имеет права на ошибку и на ее исправление (либо расширение функционала) в потомках. А это ограничивает, и не всегда в лучшую сторону.

Да, так и есть. Но недостатки есть продолжение достоинств - и наоборот. А стремление "чтобы всем было хорошо" выглядит несколько наивно  :)

Удалено

1.
мы ничего такого не сообщаем компилятору.

2.
mutable? не, не слышал.
const_cast? не, не слышал.

3.
и самое главное: это не является необходимым.
вы вполне можете писать код без каких бы то нибыло модификаторов и клвалификаторов.
будет у вас аццкий говнокод.
однако, технических препятствий не существует.

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

компилятор это делает для вас. не для себя.
ему это для работы не нужно.

именно так.
именно с этой целью это и было сделанно.

попытка исправить говнокод за счет костылей в потомке - ещё больший говнокод.

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

я хочу сказать, данная порочная практика от быдлокодера - не есть "хорошо".

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

это то, ради чего и задумывался изначально ООП.

Эх... не люблю телеги постить...

If an object is declared const, then (ISO/IEC 14882:2003 7.1.5.1(4)):

Except that any class member declared mutable (7.1.1) can be modified, any attempt to modify a const object during its lifetime (3.8) results in undefined behavior.
Lets disregard objects that may have mutable members - the compiler is free to assume that the object will not be modified, therefore it can produce significant optimizations. These optimizations can include things like:

incorporating the object's value directly into the machines instruction opcodes
complete elimination of code that can never be reached because the const object is used in a conditional expression that is known at compile time
loop unrolling if the const object is controlling the number of iterations of a loop


Я про это писал. Жаль, что не слышали. У Страуструпа расписано.


Строго говоря, язык c++ не является необходимым, можно писать на ассемблере. И забыть про говнокод.


См.выше

А может, скажет много некультурных слов, т.к. его лишили возможности отнаследоваться?
А потом решит проблему копипастом и построит "второй тоннель",  по вашему это нормально???


ООП задумывался для проектирования расширяемых приложений. Увы, успехом полученное назвать трудно. Только местами.

Ну такая тональность хорошо известна. Вот напр (с др форума)
Ах какой "продвинутый". Это вы тут паритесь с каким-то старьем - а он впереди планеты всей.

я читал стандарт,
поэтому мне не нужно постить ваши телеги.

тем не менее он используется.
и умеет private, и это не с проста.
это нужно для поддержки механизма инкапсуляции.
которая является одним из столпов на котором жиздеццо ООП.

вам осталось лишь понять, что это такое "инкапсуляция",
и зачем это нужно.

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

(примичание: c++11 ввели дополнительное ключевое слов final, которое запрещает наследование.
в с++03 приходилось использовать особые трюки, что бы запретить наследование.
модификатор доступа private сам по себе наследоваться не запрещает)

защиту ставаят не просто так.


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

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

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


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

до его тупых мозгоф не дошло,
что метод был помечен квалификатором не спроста.

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

ОО-парадигма получила широчайшее распространение
потому что полностью отвечала требованиям бизнеса:
потребность в командной разработке.

приход оо ознаменовал новую эпоху в истории индустрии:
командная разработка.

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

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

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


вы о своей личной практике?
потому что объективно, ооп поимело бешенный саккцесс стори.

но судя по задаваемым вами вопросам, и ответам,
вы даже понятие "инкапсуляция" не осилили.
а без этого вам будет сложно в мире ооп.

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

Ну крайности бывают с обоих сторон) "самой" убогой реализацией С++ называть, конечно, нельзя. Это мощный компилируемый язык, на котором пишется львиная доля промышленных приложений, требующих высокого быстродействия и доступа к железу. С другой стороны, язык действительно несколько устарел и использует множество концепций, которые были популярны лет этак 30 назад и в настоящее время утратили свою однозначность (взять те же макросы, инклуды, стандартную библиотеку, синтаксис шаблонов и т.д.) Поэтому я сторонник динамического развития С++ в сторону очистки его от неоднозначных вещей. К сожалению, новые стандарты разрабатываются в основном теоретиками, а это чревато появлением очередного мегалозавра от ООП. Надеюсь все же, что разум победит и будущее языка будет не так печально, как его описывают плюсоненавистники. Но - это уже вопрос философский...

Угу, угу... Слив защитан ;)


20 лет было легко, и вдруг стало сложно :) Спасибо, поржал.


Чтобы быдлокодить, не обязательно использовать ооп. Достаточно не использовать мозг.


У вас что, так именно и было, да? Вы страдали от того, что коллеги не разделяли ваше желание все члены классов позасовывать в приваты и наделать геттеро-сеттеров? Сочувствую...


А, ну да. До появления ООП и программирования-то не было. Бедные Страуструс с Виртом обливались слезами, когда кодили на С и Паскале и все ждали - боже, ниспошли нам Концептуальную Парадигму, чтобы мы прозрели :)

Вы знаете, есть большое различие между теорией и практикой. В вашем академическом мире все выглядит научно, красиво и безглючно. Ведь умные люди написали очень много умных книг, читай не хочу. И в книгах этих все прекрасно, приведены фрагменты Идеального Кода, описаны Правильные Паттерны, даны Рекомендации На Все Случаи Жизни. Все пропитано духом Инкапсуляций, Полиморфизма, Инвариантов (тут еще 100500 умных слов). Объектная модель непогрешима, интерфейсы лаконичны и однозначны, данные гомогенны, ВсеКакДолжноБыть. Просто прелесть и рай земной.

И тут приходит Продакшен... Вы видели легаси С-код, написанный в стиле спагетти на основе WinApi и портированный на С++ для того, чтобы обеспечить кроссплатформенность? А сторонние промышленные библиотеки, сочетающие в себе куски 30-летней давности и поддежку C++11? А полиморфизм на уровне C-функций? Множественное наследование, построенное на темплейтах, которые специализируются под каждый определенный класс? И ведь все это должно работать, причем максимально быстро, стабильно, не вылетать по причине null pointer assignment и нехватки памяти в самых неожиданных местах. И очень часто по причине того, что людям хочется сделать собственный велосипед, потому что "в умной книге был описан СуперМегаПаттерн" и они лепят его из подручных средств, не задумываясь о том, как это, собственно, будет использоваться в будущем.

Или код из серии "Так, вот тут вот надо, чтобы порядок вызова был именно такой и никакой иначе, а то функция вернет 0, а не 1... Не дай бог мой метод вызовут извне с другим энвайронментом... О! Бинго!! Захерячим его в приват!!! Решено!" Вот подобные возможности языка и порождают потом варианты с const_cast-ами и другими аналогичными методами обхода быдлокода (хотя сами при этом становятся быдлокодом).

Или мы наваяем write-only шаблон, который теоретически мог бы работать с классом А, если бы он наследовался от Б, но его надо использовать только с В, потому что в Б у нас метод DoSomeShit объявлен константным, хотя шаблон предполагает изменение некоторых состояний объекта, а В - это вынужденная копия А, только DoSomeShit там не конст...

Когда приходится поддерживать и расширять подобный код - тут и наступает ад. Но в Умных Книгах про это не пишут...

детский сад.


верно.
поэтому я и предложил вам включить мозг,
и ознакомиться с понятием "инкапсуляции",
и не пороть чушь, как в #10

Вот допустим есть 2 программиста (или даже 2 команды). Первый четко следует всем канонам, активно применяет паттерны и крутые либы. Второй... та просто "быдлокодер", лепит const_cast, классы у него просто struct и.т.п.

Так вот, неоднократно замечал что рез-т выходит "наоборот". Недостаток техники может с лихвой компенсироваться более глубоким знанием предметной части, желанием с ней работать и, как следствие, более удачной архитектурой. Напротив, академический знаток часто чрезмерно увлекается абстракцией и в результате поверхностно относится к задаче. Другая болезнь (за)Знаек - "перфекционизм" и отсутствие гибкости, типа "вот это должно быть private - и точка!". Такая "нетолерантность к говнокоду" особенно болезненна когда выплывает ряд доделок/переделок которые, увы, часто вдребезги разбивают изначально такой стройный замысел. И еще весьма неприятный плюс (точнее минус): да-да, вот то самое "пороть чушь", "включить мозги" и.т.п. В душе каждый считает себя самым умным (иначе это не программист), но у одних хватает ума это не демонстрировать, а у других нет. 

Конечно я не призываю быдлокодить, лучше быть "богатым и здоровым"  :)

конкретно const_cast это и есть удачная архитектура ? )

Как вы можете заметить результат, если вы часто не в состоянии оценить другое решение?
Заявление по поводу: "недостаток техники компенсируется удачной архитектурой" развеселил совсем и сразу вспомнился класс MainWindow с более 200 методами, который получился после "удачного" рефакторинга.
В общем, традиционное заявление: "Быдлокодеры круче всех. Не надо учиться, все равно вас наймут на работу, пусть она и будет меняться, каждые три месяца". :)

Считаю, что Игорь практически во всем тут прав. Я насмотрелся в своей жизни и быдлокода, от которого глаза вырвать хочется, и СуперПуперКаноничъногоТруъКода "по всем аналам" теории (от которого хочется примерно того же самого). Как правило, ТруъКаноничныйъКодъ удивительно нежизеспособен из-за абстрагирования его от предметной области. Когда такой вот мегакод приходится саппортить другому программисту, и он понимает, что все члены класса были по непонятным причинам засунуты в приват-секцию (просто так, без объяснения причин, хотя их часто и нет - "ведь в книжке написано, что члны класса должны быть приватными"), ему остается только или переписывать половину кода, или быдлокодить, если на п.1 нет времени или исходников...

Я тоже насмотрелся за свои 30 лет в отрасли, и именно поэтому стараюсь все делать правильно в меру своих знаний. Поэтому, предлагать отказаться от приватных секций, по причине того что быдлокодеры не правильно ей пользуются, явно избыточно. :)
Скорее их надо учить, а пока они учаться разрабатывать прототипы классов за них. Вот я занимаюсь архитектурными решениями и сам пишу хедер-файл с классом, где расписываю все от имен до constов. Дальше отдаю его одному из своих программистов с подробным объяснением что он должен делать. А потом начинаются "циклы" - он мне рассказывает как он это будет делать, а я говорю свое мнение по этому. Только так. По другому они могут писать только в корзину. Кто более менее чему-то научился начинают работать группками, но все равно под постоянным контроллем.
Менеджмент отказывается нанимать специалистов, им проще брать средних программистов ведрами за еду. :(

А ведь в моей практике был именно такой случай.... Пришло однажды на фирму "Светило ООП",  которое должно было разработать концептуальную архитектуру будущего фреймворка. Ваяло светило долго и вдумчиво, и в какой-то момент поделка разрослась до несколько тысяч классов, многие из которых юзали один базовый метод, определенный светилом как const. До поры до времни всех устраивало, пока не выяснилось, что в данном методе в некоторых порожденных классах ну просто необходимо  менять состояние объекта.... Просто Светило ООП не особо представляло себе, что проект так разрастется :) Причем, необходимость изменения состояния возникла в одном из классов, созданных данным Светилом... И оно таки понапихало в итоге  const_castoв и объявило это "особенностью архитектуры"...

Вы же понимаете, что это была не проблема С++, а исключительно ваша. :)
Возможно вы упустили момент, когда этот метод должен был перестать быть константным или должен был появиться еще один не константный, а скорее всего просто не было времени и денег проводить рефакторинг. Сам так живу. Но повторю, это не проблема С++.
Кстати возможно, что проект развалился бы раньше, если бы этот метод изначально был объявлен без const. :)

Мой любимый пример
Вот гениальное решение троллей! И волки сыты (все private), и овцам хорошо (доступ есть!). Полагаю начальник им просто сказал: "да, оно конечно по смыслу public, но сделайте private чтобы не было ненужных вопросов/дебатов"

Рискну высказать полную ересь: иногда то что считается быдлокодом даже.. оказывается оптимальным решением. По крайней мере на текущий момент разработки. Соображение "так это быдлокод, кромсай его как угодно" нередко работает в плюс. Но вот если построена великая архитектура - кто ж даст свое детище в обиду? Надо признавать что принятые решение были неудачны, негибки - а это страшно противное дело  :)

Что тут можно сказать: все ошибаются и Тролли не были исключением.

Отнюдь. C++ дает прекрасную возможность по сокрытию данных с помощью protected-секции. Этим самым поддерживается и инкапсуляция данных, т.к. все, что не является публичным интерфейсом, закрыто для внешнего использования, и возможность наследования. private же грубо нарушает этот принцип, поскольку не обеспечивает обратной связи потомка с предком. После подобных "светил инкапсуляции и гур полиморфизма" и появляются конструкции вроде #define private protected (да, видел такое не раз).

Я просил уже привести пример преимущества использования private перед protected (пусть даже искусственно созданный). Если никто не в состоянии этого сделать - возникает вопрос, а так ли данная фича необходима?


Да нет, шутка в том, что const там был изначально не к месту, но "гуру" это слишком поздно понял, и поэтому закостылил как мог.

Не жульничайте :) Вы прекрасно понимаете что не все может быть показано примерами, есть и концептуальные вещи. Библия говорит что protected члены гораздо больше "подвержены злоупотреблениям". Рез-т отказа от private явно отрицательный, побуждает к интенсивному наследованию - ведь оно становится легким и легальным решением всех проблем. Но опять-таки, Вам прекрасно известно сколь часто наследование бывает неудачным. Как раз private это и пресекает и заставляет искать др решения которые часто оказываются лучше. Напр посылка ивента (вместо того чтобы лезть грязными руками).

"А что же делать если вот НАДО изменить, в оно (зараза) private  :'(". Ну значит кто-то из двоих неправ (и необязательно Вы). По крайней мере, проблема четко обнаружена

Это не проблема языка, это проблема средних специалистов, которые не умеют им пользоваться. Глупо ломать язык, что бы у кого-то лучше получалось им пользоваться. :)
А вот для интереса, сколько раз вам приходилось применять подобные хаки с define при работе с Qt? А его разработчики очень активно пользуются private. А я и при наследовании часто использую квалификаторы отличные от public. :)

А так ли необходимы темплейты, итераторы, исключения? Спросите здесь на форуме. :)

Все ошибаются. Да. :)
Но это не повод менять язык. :)

Это понятно, но язык предоставляет конструкции, которые потенциально опасны, а их ценность под вопросом. Может, для теоретиков и выглядит все стройно и гладко, но на практике "гуру" превращаются в "дуру" :)


Ну кутишники на самом деле многие вещи сделали достаточно хорошо расширяемыми. Хотя, иногда приходится обходить кривые места, особенно когда нужна собственная отрисовка, например. Иногда проще с нуля виджет накрапать, чем расширить готовый (опять же, слава богу, не часто, но все же).


Все хорошо в меру. Без темплейтов трудновато бы было создавать контейнеры, без итераторов - ходить по ним. Исключения - вещь несколько спорная (знаю фирмы, в которых было в Code Guidelines строжайше запрещено юзать исключения), но в принципе идея их применения неплоха.

Плохо, когда начинаются злоупотребления, потому что "так в книжжке написано", или "мой код крут - его никто не должен менять".


Почему же? Если некоторые вещи непродуманы и приводят к проблемам - их надо пересматривать.

Видите, вы опять говорите про крайности - "злоупотребления". Почему, для тех кто не злоупотребляет эту возможность нужно убрать? :)
Вы сами вышли на codestyles, вот на уровне своих компаний, а не языка, и стоит вводить ограничения для "средних программистов". Как и поступают большинство компаний. :)
А исключения запрещены в очень многих компаниях, включая гугл. Слишком мало людей умеет ими пользоваться, что бы разрешать их использования всем.

Эти вещи не нужны вам - не пользуйтесь, но оставьте мне возможность решать их надобность для меня. :)

Потому, что она ПОТЕНЦИАЛЬНО опасна и проблем от (заведомо неправильного, или неспрогнозированного) использования будет гораздо больше, чем профита (в чем профит,  кстати, так никто объяснить внятно до сих пор и не смог).

Я приведу пример из реального мира - private это как смартфон с неснимаемым корпусом. Т.е. вы не можете ни аккумулятор поменять, если он сдох, ни карту памяти заменить - ничего. Выхода в итоге два - либо купить новый телефон, либо отнести в сервисник типа "дядя Вася в подвале", который что-то, вероятно, захакает (а может, и нет, если все намертво залито компаундом). Какие от этого профиты для ПОЛЬЗОВАТЕЛЯ?

А что можно запердролить с обычными указателями? Давайте отменять.
В С++ слишком много потенциально опасных мест, проще отказаться от него.

Проблему с указателями можно локализовать и поправить в том месте, где она возникла.
В случае же заприваченных мемберов, нужно либо менять структуру классов, либо "быдлокодить" :(
Я лично вижу лишь одно оправданное применение привата: какие-нибудь локальные "хелперы", которые на 200% больше нигде не понадобятся, чем в данном конкретном классе. Но и тогда, вы никогда не знаете, как будет использоваться ваш код в будущем другими людьми...

Ну это фантастика. Каждый класс можно использовать только так, как это предполагал его автор. И это касается даже самых, на первый глаз, универсальных классов. Включая стандартную библиотеку.
Сможете привести пример такого класса, который был разработан для одного, а вы бы легко его приспособили для другого?

Хых.
Пример класс скачивания странички.
Используем как класс определения доступности интернета :D

Класс пишется для определенных ситуаций. Но он как кубик рубика, имеет десятки различных сторон применения.

Он все так же будет скачивать странички, только на их содержимое вам будет наплевать. И приватными методами вы этого не измените.

QWidget ;)

Ну в принципе да, его можно использовать как коллекцию виджетов...
Но даже в настолько универсальном классе нашлось место для приватных данных и методов. И я уверен, что без чтения исходников вы о них даже не знали. ;)

Радикальный взгляд с другой стороны:
(Building user interfaces for object-oriented systems (http://www.javaworld.com/article/2076459/core-java/building-user-interfaces-for-object-oriented-systems--part-1.html))
Как думаете, что скажет автор этой статьи, если запретить ему использовать private? :) И я согласен с его доводами. А с Вашими нет.

Protected-секции недостаточно.

C++ (Qt)
 
class Status
{
...
}
 
class A
{
    A() : m_status() {}
 
protected:
    const Status & status() const { return m_status; }
 
private:
    Status m_status;
}
 

Достаточно ясно сказано, что если сильно надо, то в наследнике можете посмотреть значение статуса, а вот менять его нельзя. Автор класса лучше знает, где и как может меняться статус, и почему изменение статуса сторонними классами может быть опасно. Исходя из Вашей позиции, широкий круг пользователей этого класса может лучше автора знать, как изменять статус объекта. Если этот широкий круг пользователей поломает логику работы объекта несанкционированным изменением статуса, и будут писать автору, что он криворукий, что на это должен отвечать автор? :)


Когда есть чёткое разделение кода по секциям доступа, то точнее будете знать, как этот код может, и главное будет использоваться. По крайней мере есть возможность исключить неправильное использование класса. Ну и документацию никто не отменял, где можно расписать, что можно, что нельзя и почему. То, что Вам непосчастливилось встретиться с плохим кодом, это прискорбно. Но это частный случай, и как уже неоднократно указывали, язык тут не при чём.

Ну а чего возвращаем по ссылке, провоцируя const_cast?  :)

Ах как легко делать выводы вот на таком примерчике с нулевым ф-ционалом :) Как все стройно и логично! В действительности автор часто вообще ничего не знает, а тупо лепит "по книжке". Или знает но не в состоянии представить себе все варианты использования, это нормально. В любом случае пользователь класса оказывается в тупиковой ситуации.

Основной посыл здесь в том, что отказываясь от привата, вы, фактически, только представьте: развязываете руки целой команде "Практиков" (с большой буквы П) из подмостерья Racheengel, например..
Представляете, чем это чревато? А эти люди ещё всерьёз говорят о
 
Так вот, отказ от приват, открывает эту потенциальную опасность, поподя ваш код не в те руки)

И да, нет ничего практичнее хорошей теории)

Хороший вопрос :). А как надо? Как бы Вы метод status() написали?

В примерчике показан смысл, а не функционал. В простыне функционального примера экрана на два, смысл остался бы точно таким же :).

Возвращать по значению.

Так же как и Вы. Тут, правда, есть манечка, дескать, "бинарная совместимость" - но положил я на нее.

Та ничем, это дорога в светлое будущее. А вообще private - это скорее светлая сторона языка, особенно по сравнению с таким калом как template ...

Ну судя по заявлениям типа:
Это скорее, дорога в тёмное прошлое, даже не скорее, а точно  :)

Мои подмастерья вполне безобидные и без необходимости const_cast не пихают во все дыры (ну, или по рукам вовремя получают). Я не писал, вообще-то, что мы СОВСЕМ не используем приват. Но на практике почему-то от него было больше проблем, чем позитива. Или сделать данные приватными и на каждую переменную завести по геттеросеттеру (java style) - это хорошая практика???


Нормальный метод, возврат по ссылке исключает создание копии. Что с ней дальше будут делать - вопрос, если очередной Гуру Полиморфизма придет, то const_cast напишет :) Он же ГУРУ.


Если под "калом" имеется в виду синтаксис - соглашусь. Если т.н. "метапогромирование" - то тоже соглашусь (но это все-таки больше проблема Гур, чем темплейтов). Но в целом-то фича важная и нужная, когда правильно используется, а не write-only.

Просто изначально темплейты были для другого придуманы, а как без шаблонов контейнеры лепить? Ась? :)

А если нет такого члена как m_status, а статус вернуть надо? :)
А если сейчас такой член есть, а через год он станет не нужен и его уберут, а статус возвращать по прежнему надо? :)

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


По-моему, у Вас тут противоречие. Нужен статус или нет? Если да - зачем его убирать? Если нет - зачем его возвращать?

У нас есть какой-то класс:

C++ (Qt)
class Hardware
{
private:
    Status    m_status;
};
 

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

C++ (Qt)
class Hardware
{
public:
    const Status &status() const { return m_status; }
 
private:
    Status    m_status;
};
 

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

C++ (Qt)
class Hardware
{
public:
    const Status &status() const
    {
        Status status;
        status.device1( m_device1->status() );
        status.device2( m_device2->status() );
        return status;
    }
};
 

И упс, мы возвращаем ссылку... Приходится менять интерфейс изменяя метод status, что он он возвращал значение.
А если бы сразу возвращали по значению, ничего менять бы не пришлось.
А что бы эффективно возвращать объекты, есть много разных способов: от умных указателей и до pimplов. :)

Так спор то как раз и том, что Вы сейчас достаточно категорично пытаетесь списать это на проблему языка, не пытаясь принять и другую, более правдоподобную (на мой взгляд)  причину этой проблемы  :) Выше об этом уже писали Old и _Bers

А если при изменении переменной требуется делать дополнительные действия? Даже если сейчас этого и не предусмотрено, но завтра потребуется? Согласен, в некоторых случаях (например std::pair) в этом нет необходимости. Я и сам в некоторых случаях открываю переменные..
Но я готов принять get/set, если этого требует, например code style. Но это уже другой вопрос..

С этого места можно поподробнее? Чем возврат по ссылке исключает создание копии? И чем const мешает, если доступ к статусу даётся только для чтения?

Возвращать по ссылке или по значению - отдельная тема. Если это публичный метод, то лучше по значению. Если же это детали реализации конкретного класса (куда посторонние если и должны залезать, то с особой осторожностью) можно и по ссылке.

Вот-вот, это то, про что я писал еще 5 страниц назад.

Есть у нас класс типа


и в cpp у него:


Все работает замечательно добрый десяток лет, пока не появляется стандарт SomeNewCrap, который подразумевает вариабельное вычисление SomeShit.
Наследуемся:


Гуру, засунувший CalculateSomeShit() в приват, не мог знать, что появится новый стандарт...
Но он появился... Что делать?

Racheengel - в твоем примере класс не предназначен для наследования изначально. И насрать, что CalculateSomeShit приватный.

Спрошу проще. Вам подарили смартфон с несъемной батареей. Она сдохла. Чья это проблема, что вы не можете заменить батарею? Ваша? Или производителя? По логике гугу, виноваты вы.


Бинго! См. мой пример с кодом :)

Да, в этом виноват private, а не virtual вовсе :). Предлагаю задвинуть ещё одну фишку: все методы обязать быть виртуальными!

Дык правильно, Гуру решил, что надо все в приват засунуть, он же не предвидел, что придет новый стандарт...

Напишем в привате virtual double CalculateSomeShit() const;   
Что изменится?

Мы сможем его переопределить, это называется NVI.

В принципе, если бы не совместимость с С, было бы неплохо, если бы по умолчанию в C++ все методы были виртуальными, пока не указано обратное - таким образом можно было бы избежать совсем глупых ошибок.

Да, конечно, можно решить проблему и так. Но это уже дополнительный оверхед. И человек, который потом будет читать этот код, акуеет :(

Просто не тратится время на создание возвращаемой копии, конечно потом вызвавший ее скопировать может.

"Вот если у нас в объекте ссылка исчезнет - все равно по значению мы вернуть сможем". Но собирались ли мы убирать ее сейчас? А в обозримом будущем? Нет, мы просто очень умны, мы "сразу делаем правильно" - и потом не придется переделывать (ну это мы сейчас так полагаем). Плохо здесь то что соображение (само по себе разумное) возведено в ранг "абсолюта" - все, это уже непреложное правило которому должен следовать каждый считающий себя грамотным. Также заметим - такой подход репродуцирует сам себя. Ведь возвращать приличную структуру по значению - ошибка начинающего. И немедленно вызывающему навязывается вумный указатель. И опять-таки, нормальная вещь, но не вызванная никакой необходимостью. Вот так и лепится псевдо-грамотный код который по сути говнокод, т.к. усилия направлены не на содержательную часть, а так - соблюсти мнимую грамотность.

Открываем букварь наугад

C++ (Qt)
const QBrush & QPainter::brush() const
Returns the painter's current brush.

Как же так? А вдруг brush перестанет существовать ???

Это было бы плохо, потому что нельзя переопределять всё подряд. И привело бы к большему числу глупых ошибок. Поэтому лучше явно указать, какие методы можно переопределить.

Кстати, было бы интересно посмотреть, как должен выглядеть правильный класс SomeCrap с вашей точки зрения.

Плач Ярославны комментировать смысла нет. :)

А вот это причина всех слезных ошибочных доводов:

И доказательства (если мы рассматриваем код Qt как эталон :) ) находятся в том же букваре. Стоит взглянуть например на QSqlDatabase или QDBusConnection. Интересно насколько приличны (или не приличны) эти структуры? :)
А в сухом остатке, возвращаем по значению, а копируется только указатель. Шайтан. :)

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

Обоснуйте, пожалуйста.


Вариант 1:


Вариант 2:   



И еще вдогонку вопрос для Гугу: c++ позволяет использовать virtual опционально, например, так:


или так:


Наверное, это ДляЧегоТоБылоНужно и НеОшибкаЯзыка?

Это все конечно так, но копирующий конструктор тоже не обязан быть атомарным. Поэтому придется создание копии защищать мютексами и т.д.

Что значит опционно? Как только вы определяете метод виртуалом, он попадает в vtbl. Дальше он всегда будет виртуальным, отменить это нельзя.

В отнаследованном классе метод так и останется виртуальным. То, что ты не написал virtual ничего не меняет.

Racheengel, если архитектура класса не подразумевает изменение логики, то значит так и было задумано. Не можешь изменить, скопируй его и доработай под свои нужды. Или попроси человека для тебя переработать архитектуру.

Это то все так, никто не спорит :) Но человек, увидевший метод без virtual в десятом наследнике, не будет знать, виртуальный ли он на самом деле или нет, пока не дойдет до предка.

Сути, конечно, не меняет, но ИМХО создает неудобства. Хорошо, что в 11-м это запатчили. Но это значит, что была проблема в языке, не?

В нормальном кодстайле virtual надо писать во всех наследниках.

Вот так и рождается копипаста на свет... Может такое быть, что придется пол-проекта копипастить :( Это разве хорошо...?

Еще хуже - а если код попал в закрытую библиотеку? И "человека" никакого нет, что делать?

Я не спорю :) Но язык-то позволяет опускать virtual  в наследниках, может, в этом был ВеликийСмысл?

Это решалось культурой программирования: всегда указывать virtual перед виртуальными методами.
И я понимаю, что далеко не все делают так же, но это одна из причин не использовать их код. :)

Тут соглашусь, это они зря сделали. Хотя, в этом мог быть какой-то свой скрытый смысл.

Кстати, поделюсь ссылкой на гайдлайн от Страуструпа и Саттера. Советую почитать всем https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md/

Забудет какой-нить невнимательный программёр указать nonvirtual для метода, а другой программёр полностью изменит логику работы метода, и получат оба сюрпризы. Когда метод объявляется виртуальным, то явно ожидается, что его логика может измениться, и с ним нужно быть внимательнее. Можно посмотреть на класс QAbstractItemModel, на всякие Insert/Move/Remove/Columns/Rows и им сопутствующие.


Много тонких моментов, которые нужно учитывать при наследовании от QAbstractItemModel, чтобы не поломалось модель-отображение. Почему beginInsertColumns() не виртуальный? А если я хочу его переопределить и что-то своё там сделать? И по фиг что он посылает сигнал columnsAboutToBeInserted, который приватный и сам я его не могу послать. И зачем его сделали приватным? Им есть что скрывать? Может я лучше разработчиков знаю, когда посылать этот сигнал, а когда не надо.  И пускай разработчики QAbstractItemView подстраиваются под мои хотелки. Я-то умнее их намного :).

По SomeCrap как такой вариант?

C++ (Qt)
class SomeCrap
{
public:
    virtual double GetSomeShit() const = 0;
};
 
class SomeConcreteCrap : public SomeCrap
{
private:
    virtual double GetSomeShit() const
    { return CalculateSomeShit(); }
 
protected: 
    virtual double CalculateSomeShit() const;
 
	double GetShitValue() const { return m_shitValue; }
 
private: 
    double m_shitValue;	
};

Этих ConcreteCrap'ов может быть хоть мильён, каким надо таким и инициализируй SomeCrap.  И пользователям SomeCrap не важно, как внутренности ConcreteCrap'а устроены, что там приватно, что публично, можно ли от него наследоваться или нет, есть там поля m_shitValue или всё магией создаётся. Главное чтобы в GetSomeShit() возвращалось ожидаемое по логике класса значение.

Опять-таки - это неудачный пример, который вовсе не илюстрирует изначально заявленную проблему (проблему для некоторых). Это проблема не языка, а скорее того, кто единственным решением видит вариант  отнаследоваться..

Мы как то здесь уже обсуждали хороший архитектурный пример, как аналогичное решается в реализации boost::tokenizer. Где подход, использованный там,  позволяет легко менять поведение токенайзера без всякого наследования и при этом, не меняя интерфейса самого класса tokenizer.  


http://www.prog.org.ru/topic_22338_45.html
 (http://www.prog.org.ru/topic_22338_45.html)
Обсуждение начинается с поста #50

 

В вашем случае SomeCrap - это уже чистый интерфейс. В принципе реализация-то может быть какой угодно - это правда, но это хорошо, когда так с нуля проектируется. А если SomeCrap существует уже достаточно долго и используется везде, где только можно, к тому же у него с десяток методов типа GetSomeShit() - то рефакторинг будет болезненным :(

Что касается переопределений в наследниках... ИМХО, человек, наследующийся от чего-либо, должен иметь возможность использовать унаследованный функционал в полном объеме, поскольку он может иметь больше актуальных знаний о предметной области и текущей архитектуре. Пример - опять же, появление нового стандарта/метода/оборудования, о котором изначальный разработчик мог и не подозревать, разве не так?

Нет, не так. Класс проектируется со своей внутренней логикой и предоставляет только нужные части для переопределения. Иначе внутренняя логика может полностью "поехать".

Извините, а чья это вина? Кто принимал решение использовать этот класс? Не тот ли  практик, что проектировал архитектуру, стремился сделать её как можно гибче и расширяемой? Или у практиков таких понятий нет? Сразу садимся писать class MainWindow, а дальше разберёмся по-ходу?  ;)  

Я бы сказал, что класс может эволюционировать в каких-то определенных пределах, и как правило, продуманных автором. Вряд-ли кто-то напишет класс аппаратного устройства, который после наследования можно превратить в базу данных. :)

В чем же его неудачность? Этот пример - выжимка из реальной проблемы, которую я наблюдал.


ммм... ООП как раз и подразумевает наследование, не так ли?


Прошу прощения, но я там кроме холивара, ничего не увидел. В чем суть, если в двух словах? Переопределить оператор () ?

Архитектуру проектировал Гугу-Теоретик. По его представлениям, класс не должен был расширяться, ибо 10 лет как существовал единственный стандарт, в котором Гугу шарил. И Гугу считал свой код непогрешимым, поэтому столкал все, что можно, в приваты.


Это не практик, а быдлокодер...

В том, что вместо одного класса MainWindow, можно предложить пользователю набор кубиков из которых, он будет собирать свое решение. Это позволит менять, расширять, дополнять кубики и соответственно расширять варианты решений.

Ок, но вы же понимаете, что, чтобы использовать данный подход, архитектуру надо изначально проектировать расширяемой. А если Гугу приватит все, что можно - какая может идти речь о расширяемости?

Чем меньше кубик, тем меньше на нем функциональных обязанностей, тем меньше надо приватить. :)

P.S. Кстати, вы эпохальное решение "финдреплейсера" видели? Попробуйте его расширить хоть как нибудь. ;)

Ну я об этом чуть выше написал, так что позвольте сразу перейти к последнему вопросу)

Ну хорошо, не увидели, ладно.. В двух словах:
Вот Вы садитесь разрабатывать архитектуру приложения, так, чтоб с заделом на будущее. Этот этап, пожалуй, самый ответственный и требует определённого времени  и анализа - это выделение сущьностей (классов), их взаимодействие (их интерплей), их интерфейса, критический анализ и разбор возможных решений, который бы позволил наименее безболезненно в будущем расширить функционал.  Вы, как главный архитектор, должны (нет, просто обязаны) предугодать возможность, что завтра, например, вдруг измениться стандарт (по вашей терменологии). Вот это всё продумывается N-ное время вдали от компьютера с ручкой  в руке и туевой хучей листов бумаги (нет, не туалетной). И вот на этой теоретической (не практической) стадии проектирования у вас в голове должно стрельнуть - ан нет, этот класс SomeCrap не отвечает нашим амбициозным требованиям.. Как бы нам его переделать, так, чтобы в случае чего мы могли применить к нему новый стандарт?

И вот случай с boost::tokenizer как раз иллюстрирует это) Его разработчики дали возможность конечным пользователям изменять его поведение, в определённых пределах, разумеется)

Я понимаю, что Ваш пример в достаточной степени абстрактный, но если предположить (а мне больше ничего не остаётся, поскольку нет иных сведений) что приватный метод CalculateSomeShit определяется особенностями текущего конкретно "стандарта" и подразумевается, что этот стандарт не сегодня-завтра может измениться, то, проводя "пальцевую" аналогию с boost::tokenizer его реализация могла бы быть следующей:

C++ (Qt)
template <class T, class Standart>
class SomeCrab
{
public:
    T get_some_shit() const
    {
        T result = 0;
        result += Standart::CalculateSomeShit(m_shit_value);
        return result;
    }
private:
    T m_shit_value;
};
 
template <class T>
struct currennt_standart
{
    static T CalculateSomeShit(const T & x)
    {
        return sqrt(x*0.001);
    }
};
 
template <class T>
struct new_standart
{
    static T CalculateSomeShit(const T & x)
    {
        return cos(x)  + sin(x);
    }
};
 
SomeCrab<double, current_standart<double>> someCrab;
SomeCrab<double, new_standart<double>> newSomeCrab;
...
 

       
Всё.. От Вас требуется выделить, обозначить интерфейс тех минимальных частей (сущностей), которые полностью зависят от стандарта и предоставить возможность легко его модифицировать. Но здесь, конечно, тоже существует определённая грань - глупо пытаться состряпать  супер класс на все случаи жизни)    

Это кто такой, почему не знаю? :)

Я про тот парсер, который был предложен Igors, в теме на которую ссылался m_ax.
А финдреплейсерами я называю почти все решения этого автора, уж очень ему функции findReplace с использованием QString удаются. ;)

Ок, вы заменили наследование конструированием классов с помощью шаблонов. Конечно, для интерфейса с десятком методов типа get_some_shit() шаблон получится не маленьким (Игорь, не надо про говно :)), но для небольших классов мы сами время от времени делаем что-то подобное.

Но возвращаясь к примерам выше - Вы исходите из того, что в Standart::CalculateSomeShit(m_shit_value); передается значение m_shit_value. В моем же случае Гугу даже этого решил избежать, и использование m_shit_value было им захардкожено в CalculateSomeShit(void) :( Я не уверен пока, что эту проблему можно разрешить подобным образом, не вижу пока хорошего варианта решения (ну, кроме "переделать все нафиг")...

помоему, у вас тут противоречие.

очевидно жеж - эффективность.

терять в эффективности ради
жалкой попытки защищать инвариант от конченных дибилов - напрасная трата времени и сил.

это - проблема пользователя.
и это не проблема производителя.
пока их покупают и дарят.

К слову, мне тут недавно на ДР подарили большую мультимедийную клавиатуру, со всякими там колёсиками, usb разъёмами и прчими плюшками.. Но вот так она у меня в коробке и лежит.. Клавиши там уж слишком высокие и большая она (на столе много места отъедает) да  и я всё же больше сторонник минималистичного стиля..
Вот думаю, сижу и боюсь, а что если они ко мне в гости не с того ни с сего завалятся и обнаружат свой подарок пылящейся за шкафом? Как оправдываться то?) Как не спалиться?)
И кто виноват?)   

Бывает, но вы то точно не виноваты :) Дареному коню ,как говорится... Тем более мало ли, сдохнет старая клава - а тут подарок как нельзя кстати.

Толсто, слишком толсто ;)

Угу.. Ох уж эти этические штучки (с)

паяльником микросхему перепаивать - вот это - толсто.

а одноразовый телефон я выброшу, и возьму другой.

мне моё время и нервы - дороги.

А потом мы удивляемся, а почему же новый софт еле-еле взлетает на суперкрутом Ксеоне...

Отнюдь. Вот одна из задач (http://www.prog.org.ru/index.php?topic=29358.msg215466#msg215466) которой я занимаюсь сейчас. Почему очень немногие (что столь активны здесь) отозвались там? Так ведь там же нет ни постановки, ни дизайна - и вообще неясно что надо делать. А на мой взгляд как раз основная работа программиста в этом и состоит. Когда будет четкий алгоритм, сформулированы все ограничения - мне будет совершенно не нужен какой-то знаток с изумительной техникой и глубочайшим знанием языка, я сам это с удовольствием реализую, и не исключено что очень быстро.

Кто проектирует - тот и "заказывает музыку", а остальные лишь ее исполняют. А проектирование неизбежно захватывает предметную область, даже в приведенной сопливой задачке нужно иметь понятие что такое вертексы и производная. И вот что-то я не вижу живого интереса там где настоящая работа, зато потрепаться "нужно ли private"  все горазды (включая меня :))

Вам уже много раз говорили разные форумчане, почему они не хотят отзываться в ваших темах. И предметная область значения не имеет. ;)

Ага, ага, но сами-то Вы начали было продумывать, да не очень получилось, тогда хапнули подходящий класс из дуста - и все. 

Знаем те пределы, парность кавычек у Вас так и не работает. Остается петь дифирамбы дусту, мол, мое решение - это не отказ от проектирования, а напротив.. и все такое  :)

Скажу "оффтоп" сейчас, наверно... У нас на фирме буст строго-настрого запрещен к применению :) Т.к. Code Review не выдерживает.

Racheengel
Буст, конечно, то ещё говно, но не могли бы вы привести примеры, когда код ревью конфликтует с кодом, написанным на бусте. У вас что, мувы запрещены, или шаред птры?)

Ну насчет говно или нет, честно скажу - не знаю, т.к. как-то не нужен был (вообще). Наезды в основном из-за синтаксиса, с фирменными гад-лайнами расходится очень.

Дуст - крутая либа, может самая крутая из общих для плюсов. Но там не проходит "прицепил и поехали", нужно вникать, и это трудно (по крайней мере для меня). Ну ничего, я никуда не тороплюсь  :)

Igors
Да-да, очень крутая, компилируется быстро, размер бинарника совсем не увеличивает и АПИ простое и понятное.

Ещё один "Практик", адепт финдреплейсов)

А может всё-таки проблема не в бусте вовсе, мм)



 

и как это коррелирует с моим нежеланием терять в эффективности на пустом месте?

Я вот ради интереса поглядел сонным глазом в первый попавшийся файлик из дустовой кучи... Впечатление: нафталин из 80-х, попытка создать свое расширение языка на базе макросов и шаблонов... ну вот например:


 Вот что должен подумать инженер,  увидя подобный код? Что он делает? Что за криптография? Как такое поддерживать?

Может, оно не все такое, хз. Но просто в глаза бросилось.

что создаются кортежи, и запихиваются в вектор.
далее идет проверка пост-условий.

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

и казалось бы, причем тут нафталин из 80х?

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

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

По примеру хорошо понятно. Без этого пришлось бы объявлять структуру (int, string, int), делать ей конструктор, а так лихо схлопывается десятка полтора строчек. Но закрыв пример - я не смог бы его воспроизвести :) Надо помнить tuple_list_of, причудливый get и.т.п. Конечно, если этим плотно заниматься, запомнится. Но так есть риск увлечься и заниматься "непрерывным изучением" - увы, так и произошло с нашим молодым товарищем. 

Т.е. порог вхождения высоковат, а каких-то немедленных выгод (как в Qt) не видно, ну объявлю я еще структуру - не переломлюсь. Зато никаких запоминаний не потребуется. В команде кто-то на бусте, а кто-то нет быстро станет невыносимо, поэтому решение запретить имеет резоны.

И теперь ему не придется тратить по пол месяца, что бы разобраться с пулами в бусте и написать себе эффективное решение за 15 минут. Это действительно страшно. :)
Лучше ничего не изучать, а спрашивать здесь, на форуме. :)

Ну тут уже дважды нарушено правило - не перегружать операторы без необходимости. Во-первых, это оператор(), который в бусте любят перегружать по поводу и без. Во вторых, у структуры, возвращаемой tuple_list_of, судя по всему, перегружен оператор vector<tuple>(), что вообще адище (и, возможно, operator list). А deque перегружен? А буст интрузив? А как мне теперь запихать это в QVector без копирования?

Понимаете ли... Оправдывать плохой дизайн можно задумкой архитектора, недостатки языка - неправильным использованием, ограниченность - теоретическими возможностями расширения. Но, как мне кажется, если человек начинает расширять язык направо и налево - значит, ему ЭТОТ язык не нужен. Ему нужно использовать другой язык.

Можно макросами определить, например, #define BEGIN { и #define END }. Но тогда вопрос - а может, просто стоит писать на Паскале и не умничать?

Можно купить велосипед и приделать к нему еще 2 колеса. Но, может быть, лучше купить квадроцикл или машину?
Ибо такой велосипед будет ехать объективно хуже нормального квада.

list_of использует конструктор вида Container( InputIt first, InputIt last ), который почему-то для QVector определить забыли.
Если вы добавите такой конструктор, то легко сможете использовать с list_of и QVector:

C++ (Qt)
template<typename T>
class MyVector : public QVector<T>
{
public:
	template< class InputIt >
	MyVector<T>( InputIt first, InputIt last )
	{
		this->reserve( std::distance( first, last ) );
		for( InputIt it = first; it != last; ++it )
			this->append( *it );
	}
};
 
int main( int argc, char *argv[] )
{
	typedef boost::tuple<int,std::string,int> tuple;
 
	MyVector<tuple> v = tuple_list_of( 1, "foo", 2 )( 3, "bar", 4 );
	BOOST_ASSERT( v.size() == 2 );
	BOOST_ASSERT( boost::get<0>( v[1] ) ==  3 );
}
 

Old
Вы не до конца правы. Он, безусловно, использует этот конструктор (а мог и не использовать), но этот конструктор используется в
Очень безопасно.

Так а что не так?
list_of можно использовать со всем, что умеет MySuperClass( InputIt first, InputIt last ), т.е. со всем, что может получать какие-то серии элементов.

ОМГ, прелесть то какая :)

То Вы не понимаете! "Настоящий" программист должен держать в голове все это страхомудие, остальные так, программисты "средние".

Однако находятся такие кто не видит здесь никакого "творческого элемента", скорее это печальная расплата за обещанную "общность". Ну (допустим) выучу я BOOST_NESTED_TEMPLATE и даже convert_to_container, и что? Как это подымет мой (жалкий) уровень?  Это ж тупейшая зубрежка - и ничего более. Никогда не понимал в чем кайф "запоминающего"  :)

Конечно. Это исходники буста, зачем туда лезть без дела? А тем более что-то зазубривать? :)
boost можно использовать не зная всех этих подробностей.

Например, std::pair

Можно чуть подробней.
Не очень понимаю в чем проблема. Вы говорите о том, что можно определить pair с двумя итератора и присвоить этой переменной результат list_of?

Old
Ну типа если у нас пара, скажем, указателей, то это 1 в 1 удовлетворяет сигнатуре необходимой.

Ну тогда не взлетит. :)
Но в C++ очень много подобных возможностей и без буста. :)

Ну нет же, никто в здравом уме не будет писать шаблонный implicit operator T. Где вы в std:: такое видели? Даже оператор bool помечают explicit.

Я говорил в общем. Так сказать, обо всех возможностях С++ отстрелить себе ногу по самые помидоры. :)

в задницу ваши правила, если решение простое и удобное.
правила ради правил что ли?

вы чего то фантазируете.

у туплей не просто отличный дизайн.
он практичен.

это оценит каждый, кто столкнется с потребностью в туплях.

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

метапрограммингом не владеете.

ну хоть один здравомыслящий человек в теме.

что бы пользоваться, вовсе не обязательно вникать в детали.
это называется "грамотная инкапсуляция".

конечно, быдлокодерам, которые не понимают, зачем нужен private,
этого не понять.

Давайте не говорить за всех. А то гугу получается.


Секта Одного Румына?


Небось, на грузовом лифте ездить приходится?  ;D

Хотелось бы увидеть пример где выгоды (весьма) ощутимы. Спасибо

А что за "тупли"?

первое что пришло в голову из личной практики:
с++03, вариадик шаблонов ещё нет.


под капотом SendMessage в статике генерируется тупль.
и уже в виде тупля он доставляется подписчикам.
что бы прочитать сообщение,
от подписчика требуется лишь уметь принимать тупель
с определенным набором  типов полей.

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



другой пример:
это из библиотеки libpqxx
если не в курсе: библиотека для работы с серверами базы данных PostgreSQL.
поставляется разработчиками самого постгре.

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

тупель здесь (в старых версиях использовался boost::tuple, в новых - std::tuple),
используется как основа для построения вариативного механизма.

дизайн примерно следующий:


ещё один пример:

я подозреваю, что тупли изначально были изобретены
именно для решения этой инженерной задачи:
нужно забиндить входные аргументы для последующего использования в некотором будущем.


std::bind умеет биндить любые функции с любым количеством любых аргументов.
и вот как прикажите ему запоминать списки аргументов?

я сам лично делал собственные велосипеды-делегаты,
и там столкнувшись с этой проблемой,
естественным способом вывел велосипедный-тупель.

других вариантов просто нет.


---------------------------------------------------------------------------

резюмируя:

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

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

киллер-фича туплей - диагностика ошибок времени компиляции.

тупль... tuple... кортеж, же! :)

см #139

QVariantList :)

"все уже придумано до нас"

Ну вот у меня сразу вопросы - что такое 10? Что такое пустые скобочки в конце? Могу ли я их не писать?  Не заглядывая под капот SendMessage, на это ответить нельзя. А код должен быть читаемым, в первую очередь, так как пишется он 1 раз, а читается потом много и разными людьми.

Идея понятна, спасибо за примеры. Но вот.. как же без структур? Хорошо, принимающий получил это чудо, что он будет с ним делать не зная типы? И еще
Шо это за козырный сынтаксыс? Во что это отливается в asm? Это аргументы подаваемые на стек или как? Могу ли это я как-то в языке юзать  "просто так", без туплей? Спасибо

Приехали) Вот оно, плоды "светлого будущего" и творческого подхода)

Это ж оператор()

C++ (Qt)
struct SendMessage
{
    template <class T>
    SendMessage & operator()(const T & x)
    {
        std::cout << x << std::endl;
        return *this;
    }
};
 
SendMessage m;
 
    m(10)("hello")(3.1415);
 

Вы сейчас разрушили всю магию... :)

;D
Не удержался, простите)

Во блин, и так можно...

Тогда переформулирую первый вопрос. А как это "передать"? Т.е. хорошо, оператор получил на вход очередной "T", и что дальше?

C++ (Qt)
struct Message
{
	template <class T>
	Message &operator()( const T &x )
	{
		m_values.push_back( x );
		return *this;
	}
 
	void operator()()
	{
		std::cout << "Sending message: ";
		for( auto &val : m_values )
			std::cout << val << ' ';
		std::cout << std::endl;
	}
 
	typedef boost::variant<int, std::string>	Value;
	std::deque<Value>		m_values;
};
 
template <class T>
Message SendMessage( const T &x )
{
	Message msg;
	msg( x );
	return msg;
}
 
int main( int argc, char *argv[] )
{
	SendMessage( 10 )( "Test string" )( "asdasd" )();
	return 0;
}
 

А можно не делать специальный оператор () для отправки, а выполнять ее в деструкторе Message.

Повторюсь, пожалуй... Аналог QVariantList. Ну или QVariantMap, если с ключами :)

Но есть момент. :)
Ни первый, ни второй не сможет контролировать количество и типы аргументов, а tuple сможет. :)

Ну это банально, да и расходно

В смысле?? QVariantList это по сути QList, количество доступно через count(). А каждый QVariant можно опросить, какого он типа, через QVariant::type().

Это понятно.
Я про то, что если определили кортеж:

C++ (Qt)
tuple<int, string, string>

то запихнуть туда три числа не получиться и 8 строк не получится.
В отличие от... :)

Вариант (в любом виде) - самый гнусный тип (или паттерн, хз), по сути расписались в собственном бессилии со слабой надеждой разобраться в runtime

10 - это такая циферка, которая имеет тип int,
и является частью сообщения состоящего из трех полей.

пустые скобки в конце детонируют отправку сообщения.

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


верно. именно поэтому и был создан этот механизм.

классическая альтернатива (по школе банды четырех):
нельзя просто так взять и отправить тип int

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


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

и что самое хреновое:


классическая школа в духе банды четырех в этом смысле - унылое Г.
тормозной рантайм с тормознутой проверкой на ошибки только в рантайме.

кода придется вручную фигачить немерянно.
а работать это будет неэффективно.

подписчик на сообщение как бы знал на что подписывался.



c точки зрения эффективности, это тоже самое, что и вариадик-шаблоны.

в c++03 я делал так:
в с++11 я делаю так:

там нет никаких аллокаций, левых копирований,
и все прекрасно inline

Да, конечно

Тут неясно, если можно, подробнее. Как управление попадет на точку "того самого" ReadMessage?

Ну дык в новом стандарте так можно и без всяких туплей сделать..)
Наверное, boost::fusion служит примером того, где они (тупли) используются) Ну и boost::spirit, например)  Если речь зашла о метошаблонной магии)

Что вы имеете в виду под Меташаблонами? Если это те, что появились в результате случайной ошибки, то оправдание их использования очень спорно.

detected: ниосилятор

из &Reader::ReadMessage
получаем список параметров функции.

в случае с туплем получим тип этого тупля.
ну а далее, делегируем вызов функции-хранения,
которая параметризуется типом этого тупля,
передав ей ссылку на подписчика.

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

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

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

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

поэтому, функция SendMessage(10, true, "hello");
напрямки запустит цикл только для тех подчисчиков, кто подписался на набор:
void  ReadMessage(const int&, const bool&, const char*)

единственная заморочь со строками:
"hello" - это неизменяемый массив буковок,
а вовсе не указатель на неизменяемый объект.
поэтому, формально набор типов при отправке и получении
может получаться немножко различный.
и это нужно учитывать.
но эта хрень легко разруливается при помощи мета-функций-хелперов.

если не понятно, то чутка попозже будет время,
могу привести простейший хэлло-ворлд с примером-иллюстрацией.

да это все фигня. дизайн и косметика.

лучше вот что расскажите:
как вы без туплей в с++11 сможете забиндить аргументы?

представьте себе: клиент зовет функцию  с аргументами.
нужно запомнить с какими аргументами она была вызвана.

и спустя какое то время,
когда нибудь в будущем запустить нечто с этими аргументами.

если вам запретить использовать std::tuple,
то единственный способ решить эту задачу - либо взять какие нибудь boost::tuple,
либо построить собственный велосипед.

потому что иначе такую задачу решить будет невозможно.
даже если у вас там с++1y

Да, точно - не подумал об этом

Было бы очень к месту. Спасибо

Преимущества в студию, пожалуйста. Только без книжных примеров, а реальные. Или очередной раз пук в лужу?

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

полагаю, неосиляторы вроде вас,
это те, остановившиеся в развитии кодерки,
что пишут на "си с классами".

ну так вот вам простой не книжный пример из реальной жизни:
http://www.cplusplus.com/reference/functional/function/function/


фраза построена так, словно существуют предыдущие "пуки в лужу".
однако, вы не сможете привести ни одного такого примера.

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

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

что было добавлено в ядро с++1y ?

auto, decltype, static_assert, constexpr ? не, не слышал.
шаблоно-тайпдефы, лямбды, шаблоно-лямбды ? не, не слышал.
концепты, type_traits ? не, не слышал.

что хотят добавить в с++17 ? статическую рефлексию? не, не слышал.

пуканье в лужу - это например #183
потому что написав такое,
долбодятел расписался в собственном бахвальстве и невежестве:
не знании основ языка
"не знаю, не умею, и знать не хочу" - зато понты выше крыши.

такой кодерок никогда не сможет построить механизмы наподобие:
std::function/std::bind, std::shared_ptr, и др.

он не умеет стандартую библиотеку.

а об этом разделе вообще ни разу не слышал,
а если и слышал, то представления не имеет,
как эти пользоваться:
http://www.cplusplus.com/reference/type_traits/

А я полагаю, что теоретики вроде вас ни разу не работали на реальных проектах с большим объемом кода и функционала.
Иначе бы знали, почему "метапрограммирование" на шаблонах в них малоприменимо.
Для вас языки программирования - это предмет для теоретического обсуждения, за которым, как правило, нет ничего из разряда реального применения.
Вы рассыпаетесь книжными фразами и терминами, но не можете ответить на вопросы по существу.
Может это и должно возыметь эффект на джуниоров и студентов, но не все тут такие, поверьте.



Отнюдь.
Ни одного ответа по сути о необходимости приватных методов - раз.
Незнание того, как и для чего используется модификатор const - два.
И это только в этом треде.


Опять голословное и бездоказательное утверждение. Впрочем, неудивительно.

полагать - это все, что вы можете.
причем высасываете из пальца
ничем не обоснованные свои влажные фантазии.

однако, скажу по собственному опыту:
"крупными проектами", и "седыми яйцами" - кичаццо в основном только новички.

просто вы оказались слишком тупой, что бы понять простую вещь:
технической необходимости (ситуации, когда по другому сделать просто не получится) - не существует.

модификаторы public/protected/private были созданы для людей,
как средство обеспечения инкапсуляции (и следовательно - инварианта) классов.

мне лениво объяснять тупым людям, зачем это было нужно.
(все равной не поймут)
я лишь предложил вам самостоятельно почитать об этом,
и не нести всякий бред.

я не давал вам повода так думать.

я сообщил вам, что квалификатор конст,
точно так же, как и модификаторы доступа public/protected/private
нужен человеку для поддержания пресловутой инкапсуляции,
и обеспечения инвариантов, а не компилятору.

то есть необходимости в нем так же не существует.
вы вполне можете писать код без всяких const.

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

технических ограничений язык не накладывает.


понимаете, даже Ватикан уже признал, что земля круглая.

я вам ссылок накидал на стандартную библиотеку,
в которой внезапно полно инструментария для мета-программирования.

ключевых слов c++11 накидал,
которые внезапно завезли для нужд мета-программирования.

механизмы привел из стандартной библиотеки,
которые существуют лишь благодаря возможности мета-программирования.

и вы считаете это - голословным утверждением?

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

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

и кстати, не пытайтесь взять меня на понт по части знания стандарта языка.
я уже понял, что ваш уровень - это "си с классами".
на моем поле вы играть все равно не сможете.
слишком плохо знаете язык.

например, предложи вам запилить аналог std::function и std::bind.
вы ж такую задачку уже не осилите.

ну или вот пример, попробуйте ответить на вопросы по коду
http://rextester.com/UICA90733


сейчас я больше чем уверен,
что вы не в состоянии прочитать исходный код std::shared_ptr,
и понять его устройство.

но вы можете попробовать меня переубедить.
(интересно понаблюдать, как вы пойдете в отказ, и начнет отмазываться)

кстати, внезапно std::shared_ptr/std::make_shared
так же использует мета-программирование
для проворачивания всяких штук.

один только инжект счетчиков в объект-ресурс,
который выполняет std::make_shared чего стоит.
по сути получается, что std::make_shared превращает
std::shared_ptr в интрузивный указатель.

шаблоны выносят в инструментальные библиотеки в силу их "шаблонной" природы:
инструменты для эксплуатации в самых разных проектах.

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

а вот использование библиотечного шаблоно-класса - да пожалуйста, сплошь и рядом.
армия программистов, включая самых маленьких спокойно используют STL.
многие не в состоянии понять исходный код того же std::vector.

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

В коде это "присвоение"
Что отливается в такую бадягу
Хмм.. не могу понять какому же конструктору из справочника это соответствует :) Это MSVC, хотелось бы  посмотреть шланг, но там отладчик слабенький, не покажет.

Ну ладно, в любом случае как он удаляет ясно: его "deleter" (_Ref_count_obj) инстанциируется типом der (а не base) и зовет деструктор der без затей

Чтобы использовать др "traits", напр уникод

Да, да, и еще раз ДА. Усложняют. Чрезмерно. Чем меньше темплейтовской заразы - тем лучше. К сожалению, она часто понимается как "грамотность" и "знание языка". В результате человек изо всех сил хочет быть "грамотным" и сует std:: во все возможные места. Или, хуже того, начинает творить свои темплейты. У одних эта болезнь проходит, у других - увы  :'(

Откройте раздел "Алгоритмы" и возьмите любую мою тему. Попытайтесь ответить на хоть какую-то. Даже не "дать исчерпывающий ответ", а хотя бы выдать идею (пусть очень сырую). Мне почему-то кажется что Вы не будете даже пытаться. 

Ведь это (вроде бы) "не программирование", вот пусть кто-то другой этим занимается. Так?
Но если так, то выходит что вот тот "другой" и будет главной фигурой, а программист - так себе, лишь реализатор, делает что скажут. А может так оно и есть, в сериалах часто показывают "компьютерщиков" - юнцоа, подгоняемых поджопниками :)  Какие уж тут "ребята 120+", дай бог "12-"

Компании надо решать свои прикладные задачи, и виртуозное владение командной строкой или манечка темплейт-общности может оказаться совсем не главным. Нужна идея решения, понять что вообще делать-то, насколько это реально, уметь рискнуть или наоборот, воспользоваться аналогами - много чего нужно. И только потом, когда все уже принципиально решено, вот тогда (может быть) какое-то значение будет иметь знание какого-нибудь "decltype" - ну а может и не будет.

А что будет делать "знаток"? Да ничего, сидеть играться с очередной конструкцией. Ну и нафиг он нужен? Попортить кровь окружающим назвав их "средними"? Другого применения его талантам часто не находится  :)

Это потому, что вы не знаете, чем его нагрузить. Эх, мне бы таких хотя бы парочку ... :)
А сейчас десятки "средних специалистов" ждут когда "папа" им придумает занятие, все разжевав и в рот положив.

Переход на поросячий визг и личности, как правило, означает неправоту и не украшает вас как человека.


Вот именно. Все, что вы можете - это накидать ссылок. Я специально просил пример, который оправдывал бы
НЕОБХОДИМОСТЬ применения меташаблонов в РЕАЛЬНОМ коде. Вы же просто приводите ссылки на справочную информацию,
функционал стандарной библиотеки, которую и так может прочитать любой желающий. Что это доказывает?
Только то, что вы "книжный программист" и не более.


Открою одну истину: программирование ради программирования - бесполезно. Само по себе программирование не имеет смысла,
так же как бесполезны математика, экономика, хирургия и пр. без области их применения. Программирование - это не самоцель,
это всего лишь средство достижения цели. А язык программирования - это инструмент, а не предмет гордости, и ничего более. Всякий язык имеет область
своего применения, так же как и всякое средство языка может быть использовано по-разному для решения различных задач.
Говорить о том, что кто-либо "слишком плохо знает язык", не зная контекста - это примерно то же, что говорить, что стоматологи - не специалисты,
поскольку они не владеют приемами нейрохирургии.


Шаблоны - это мощное и нужное средство языка, которое, как и другие вещи, имеет свою область применения.
Они были задуманы прежде всего как механизм построения контейнеров типа std::vector и решения одинаковых задач
для различных типов данных. Конечно, их синтаксис оставляет желать лучшего, но это уже другая тема.

То, что люди злоупотребляют их использованием - это еще полбеды, настоящая беда в том, что они не осознают последствий.
То, что сейчас модно называть "метапрограммированием" - как правило, сводится к разработке франкенштейна "на шаблонах",
потому что "так завещал Александреску". Конечно, для говноконторы в полтора программиста это не особо трагично, поскольку
разработка на базе подобного кода не волнует ровным счетом практически никого (как впрочем и саму говноконтору). "Гуру"
может сколько угодно ваять метаконструкции и упиваться собственной крутостью и "знанием языка". Но дело в том, что это
никого не колышет, кроме самого "гуру" :)

А теперь представьте, что речь идет о компании, которая создает промышленный продукт. Этот продукт создается усилиями не одного-двух,
а десятков и сотен разработчиков. Такие компании дорожат своей репутацией и временем как своим, так и клиентов,
поскольку время - это очень важный ресурс. Простой системы из-за программной ошибки в течении несколько минут может стоить десятки, а то и сотни
тысяч денежных единиц. Чем быстрее она будет устранена - тем ниже будут потери.

Вот как вы думаете, почему в серьезных компаниях частно проводится аудит кода и спорные и неочевидные вещи запрещаются к использованию?
Совсем не потому, что код-ревьюверы - идиоты, неспособные понять написанного, а инженеры-программисты - бангалорские обезьянки,
работающие за еду (такое тоже бывает, к сожалению, но это в итоге не играет в плюс менеджменту, который решил сэкономить). А потому, что
код является собственностью компании - раз, и должен быть ПОДДЕРЖИВАЕМЫМ - два.

Представьте, что "гуру", наваявший супермегашаблонный код, в один прекрасный день пойдет на повышение/уволится/выпиздят с конторы/сойдет с ума и заедет на дурку.
Сколько времени потребуется другому инженеру, который придет на место "гуру", чтобы разобраться в его хитросплетениях и найти ошибку либо
расширить функционал? Особенно если "гуру" не оставил практически никаких комментариев и руководства? Должна ли компания нести убытки
из-за того, что кто-то решил, что он "умнее" других?


Дело даже не только в этом. ПРАВИЛЬНО использованный шаблон - это несомненный и жирный плюс. Но надо исходить из реальности, а она такова,
что шаблоны - это корм для компилятора. А перевариваются они гораздо дольше "plain"-кода именно в силу своей иерархичной структуры.
Поэтому когда шаблонный рак (опять же, имеется в виду злоупотребление) проникает в самые глубокие уровни корпоративного фреймворка,
наступает коллапс билдсервера. Да и на местах разработчики вынуждены затрачивать лишнее время на сборку проекта, и все ради того, чтобы
какая-нибудь статическая штука была посчитана во время компиляции.

Кстати, по поводу компиляторов. Известно ли вам, что довольно часто есть необходимость использовать старые версии компиляторов для сборки
проектов? Здесь опять же я имею в виду проекты, имеющие жизненный цикл в несколько лет (а то и десятков). Продиктовано это может быть чем угодно,
от целевой системы заказчика до специфики используемых библиотек. Как вы думаете, что произойдет, если придет "гуру"-знаток 17-го стандарта и запилит в код
свое меташаблонное решение? :) Нет, здесь, конечно, можно много об эффективности старых компиляторов - тут я не спорю, что переход на новые
версии в основном приносит значительные преимущества. Но не нужно забывать о том, во сколько обойдется фирме собственно портирование продукта,
и его тестирование...

Фух... Вот, вроде, вкратце, что я хотел сказать (писал сей опус с перерывами во время компиляции фреймворка, пронизанного шаблонами).

Я не играю в игры под названием "кто назовет больше паттернов", эти времена уже прошли.

В общем-то ключевой вопрос :). Все ли "гуру" плохие? Бывают ли хорошие Гуру? Могут ли "другие инженеры" понять проектирование и код хорошего Гуру? Если не могут, то почему? Виноват ли в этом Гуру или таки "инженеры"?

Может ли быть такое, что группа настоящих, хороших Гуру спроектировала всё как надо, написала основу, и далее инженеры должны следовать этим правилам и дописывать остальное. Гуру следят за инженерами, и если они делают что-то не так, то бьют их по рукам и говорят: "Не делай так. Делай вот так. Я лучше знаю." (и они действительно лучше знают). Если Гуру говорит, что надо использовать шаблоны, то его надо послушать или предать анафеме? Или такие команды из области фантастики? И надо не париться, а подстраиваться под "среднего инженера", всех гуру выгнать, чтоб не мешали код фигачить :). А потом каждые год-два половину проекта переписывать, потому что он плохо спроектирован и не расширяем. Когда вместо того, чтобы изменить 500 строк, приходится переписывать 50 000.

Ну, вы знаете, это палка о двух концах. Я позволю процитировать себя же:


Если в проект внедряется нестандартное либо трудносопровождаемое решение, то оно ОБЯЗАНО быть описано в документации, причем таким образом, чтобы даже "средний" инженер это понял. Да что там средний инженер, даже гуру гуре рознь. У каждого нового "гуру", как правило, имеется "своя" точка зрения на все, и он, увидев "чужой" код, может сразу заявить - "что за дурак это делал? Я щас тут переделаю быренько, как НАДО" Так что, это как повезет. HR-щики при приеме гуру на работу же не спрашивают, что он будет делать конкретно с этой частью проекта.

Да и понятие "среднего" инженера, как правило, утрировано - все "гуру" были когда-то "средними" инженерами.

Я просто что хочу сказать - люди приходят и уходят, а код остается. Если каждый "гуру" будет переписывать его под свои видения просто потому, что вчера вышел новый стандарт языка - проект превратится рано или поздно в мусорную кучу. Для этого и существуют аудиты.

Насчет расширяемости - есть фундаментальные принципы KISS & DRY, и их придумали отнюдь не идиоты. Проектировать надо с умом, но не всегда можно охватить всех аспектов, будь ты даже супергуру в кубе. Поэтому общего решения "на все случаи жизни" - увы, не существует.

Понятие "средний программист" на форуме появилось после темы "хотите ли вы в этом разбираться" и определяет программиста, который не хочет (или не считает нужным) учиться. :)
А вовсе не уровень его умений.

для поддержания темы вот такой вопрос интересен:
при использовании qt стараюсь не использовать std:: т.к. в qt есть лучшая замена, например qstring вместо std::string
в каких случаях std будет лучше qt ?

Ну, например, когда надо использовать фичи с++11 - emplace, например. В случае std::string - никогда:)
Или там unique_ptr в массив положить.

Пример из жизни, баг висит на qt багтрекере. std::vector значительно быстрей, чем QVector.

Уточню, для винды по крайней мере.

Я тут просмотрел последние пару страниц... Чтобы не быть неправильно понятым - я не агитирую против шаблонных решений из стандартной библиотеки, как раз они довольно неплохо продуманы и готовы к применению. Я имел в виду  код из разряда "кулибин 90-го меташаблонного уровня", который может пролезть во все дыры проекта, как рак - и вот с подобной хренью и надо бороться беспощадно :)

А решения из буста к каким решениям будем относить? :)

Я вроде уже писал, что с бустом как-то не приходилось работать - просто не нужен был...
Так что тут ничего не скажу)

Как автор топика позволю себе влезть в вашу беседу.
Тут я понял, как и у меня бывает, пересеклись психологические проблемы (в хорошем смысле) с проблемами проектирования.

Так вот, идите в баню.

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

Вот к примеру:

Ну чтож, мы не знаем, правда это или нет. И если правда, разницу вы уж нам покажите своим примитивным тестом. Приведите примеры (учитывая особенность примимения вектора). Я вам лично не верю - с какой стати доверять кому либо?


Я так понимаю, вы говорите про использование готовых темплейтов. И от того, что он суёт его во все доступные места? Я тогда немного не понимаю, как можно темплайт засунуть, там где он не засовывается. 


Ну, тут бы я с вами ой как поспорил. Как раз всё остальное не имеет смысла. Про себя говорю - тех людей, что видел, программирование ради программирования (уберём крайнойсти постоянное переписывание кода рада перфрекционизма) - только с ними можно работать. Ну, видно есть люди от бога, типа Джобса, может у них программирование .... Хотя, это так тонко, что, возможно, вы другое имели в виду.

По моим наблюдениям - успешные (в плане денег и не в мировом значении) - это те, кто программировал ради программирования, потом они немного устали и основали своё..... А через некоторое время устали от того, что у них есть и захотели опять программировать, но так устали от всего..... Что решили - я уже это прошёл.

*Аплодисменты*
Да!
 :)

Никому нельзя верить.

http://www.qtcentre.org/threads/36619-QVector-Slower-than-STL-Vector (http://www.qtcentre.org/threads/36619-QVector-Slower-than-STL-Vector) хоть и байан.
https://bugreports.qt.io/browse/QTBUG-44566 (https://bugreports.qt.io/browse/QTBUG-44566) а тут даже с тестиком.

Запустил щас у себя в винде на старом интеле...
Результаты (Release, 32 бит, везде полная оптимизация):

Qt 5.2.1, MinGW:       QVector<int> 653 ms, std::vector<int> 225 ms
Qt 5.4.2, MSVC 2010: QVector<int> 468 ms, std::vector<int> 294 ms

QVector как бы тормоз в данном сценарии...  Может, у других не так, не знаю.
На рабочем проекте тоже были проблемы, в итоге мы повыкидывали почти все QVector из него.
Стало лучше.

Имеете в виду - все, кроме программирования? :)

Слышал звон, да не знает где он. Лучше поглядите бенчмарки (http://www.kdab.com/~marc/effective-qt/containers/results-append-tickcounter-linux_x86-64_473_gcc43.html).

std::vector не "значительно" (в 3 раза, как написано в тикете) быстрее, а либо равен (с небольшим выигрышем std:: за счет отсутствия d_ptr), либо проигрывает в скорости (в случае Q_MOVABLE типов).

Смотрим бенчмарку... ось: linux_x86-64
Теперь смотрим тикет... ось: Windows 7 32 bit

Где там, какой звон? :)

Ну да, на маргинальном случае вектор медленее, какой кошмар. Я вам даже скажу, какая строка тормозит:
Так ли часто вы делаете takeLast в цикле?

Он бы еще operator[] замерил, тот тоже, я слышал, тормозной.

Ну и если заменить вектор интов на вектор строк, то ВНЕЗАПНО эта проверка даёт нулевой оверхед.

Ну, опять свалились в примитивные тесты. Причем опять не дальше вектора :) И что хотите получить? Узнать "вот этот быстрее" и в дальнейшем юзать его (он ведь лучше). Это наивно.

На разницу в реализациях можно спокойно забить. Другое дело насколько контейнер хорош (или "адекватен") в конкретном случае. Но там думать надо. Напр у меня был случай когда по скорости удаления вектор оказался лучше чем std::map или др ассоциативный контейнер :)

да, в данном использовании он тормоз
но его могут исправить )
данный сценарий нереален - добавлять по одному int много раз сразу не оптимально
да и всеже разница невелика, не на порядок же )

Вообще-то, append у std::vector и QVector одинаковый. В данном примере тормозит pop_back. В случае std::vector он занимает 0 (0 миллисекунд) - надо передвинуть 500000 указателей. В случае QVector он занимает 100 миллисекунд - надо передвинуть 500000 указателей и сделать 500000 проверок isShared().
Но никто в реальности не делает pop_back циклом, для этого есть QVector::erase(begin, end), к-ый делает 1 (одну) проверку isShared(). Автор теста - ССЗБ и не умеет пользоваться инструментом.

Тут главное сообщение в том, что вы указали на проблему - проверка isShared. Тогда все становится понятным и прозрачным. Но.... На то оно и но. Мы же используем std и его аналог. Зачем  менять тест? К чему я веду. STD - и Qt:STD  - это одно и тоже? Если нет, тогда вопросы отпали. Но ведь здесь хотят использовать однообразие, а не разные реализации стд, так что вопрос не закрыт. Это как использовать разный код с++ для разных компилеров, чтобы доказать, что какой-то лучше.

Если QList сравнивать с std, то там ещё мрачней по отличиям. Это такое. Но слушайте, объясните мне, для чего лист. Я вообще очень абстрактно понимаю, а точнее не понимаю. Я настолько часто вижу его использование, по сравнению с вектором, что реально не понимаю почему люди его туда суют. Возможно это связано с радость в энных годах, что он стал доступен, а не его ручками реализовывали, как раньше. Ну объясните мне! Очень хочу понять, искренне причем, где куча вставок важней быстроты доступа. И не подсказываете задачи про лист, которым вы не пользовались, я  сам вам могу примеров теоретических с вагон накатать.

Вы про linked list или QList?

QList - основной контейнер Qt. Это как бы "гибрид"

1) Если sizeof(T) <= sizeof(void *) (т.е. размер эл-та не больше указателя на него), то QList работает как вектор. Плюс возможность prepend. Это оптимально не только для простых int но и для типов "формально указателей" напр QString

2) Иначе QList работает как вектор указателей, память выделяется под каждый эл-т (что довольно расходно). Но с более удобным синтаксисом, обращения как к вектору, нет забот по удалению (как с вектором указателей). Вставка/удаление в такой QList намного быстрее чем в вектор за счет того что двигаются/вставляются указатели (а не сами эл-ты). Хотя конечно "быстрой" ее не назовешь. Также ценная возможность - адреса эл-тов не "уплывают" как в векторе.

В общем - ничего гениального, но очень удобный, приятный контейнер. Немного сбивает с толку название - к "списку" он не имеет никакого отношения.

Кстати, вот тут была бы в тему ваша присказка про букварь:) В букваре написано неправильно, дефолтным контейнером должен быть (Q)vector.
QList - устаревшее говно, к-ое проигрывает QVector'у по многим параметрам.
Основная беда в том, что "хороших" типов для QList не так много. Внезапно, QModelIndex - "плохой" тип (sizeof > sizeof(T*)), QImage - плохой тип (наследует PaintDevice и имеет vtable!), пользовательские типы - скорее всего плохие. То есть, в огромном количестве случаев QList будет фоллбечится в массив указателей, а значит а) жрать больше памяти б) делать туеву хучу аллокаций.

Я (визуально) помню из какой статьи почерпнуто это мнение. Не верьте :) Да, память жрется, но соображение "должен быть неперемещаемым" часто важнее (или необходимо), а QVector этого не обеспечивает.

Можно подробней, про что вы, ничего не понял.

Независимо ни от чего, практически всегда (мы про глобальные вещи, правда?) индексные массивы используются для поиска по значению. Т.е. тупого перебора. И доступ по листу проигрывает жутко сильно вектору. Была бы задача  -  там поиск пользователь устроил, эка беда. Но вы возьмите Model-View Qt. Такой перебор он использует когда хочет, сколько хочет и как хочет и причем довольно часто.

Поиск по значению применим только если есть уверенность что число эл-тов невелико. Иначе есть все основания создавать ассоциативный контейнер

Нет там никакого "жуткого" проигрыша, неоткуда ему взяться. Ну еще одно разыменование, и что?  А вектор часто просто по смыслу не годится (см предыдущий ответ).

Не знаком с такими злоупотреблениями. Примеры?

А если есть увереность, а поиск всё одно делается?

Привожу пример.
QModelIndex QAbstractItemModel::parent(const QModelIndex & index) const
Абстрактный метод, который мной был протестирован на предмет вызовов в разных версиях Qt. Вызывается когда хочет, сколько хочет по "тысячи" раз когда ему вздумается. Вам нужно найти парент элемент. "Родитель" - это обычный список, который, правда, вы создаёте сами.

Зато там есть O(n) аллокаций против O(1) у вектора.

Кажется, я уже кидал ссылку (https://marcmutz.wordpress.com/effective-qt/containers/) про контейнеры. Там всё про кулист разжевано.

В смысле все равно создается ассоциативный контейнер? Ну перестарались, но греха особого здесь не вижу  :)

Зато вставка/удаление куда шустрее. Впрочем это мы уже ходим по кругу

Хорошая ссылка, но не все разжеванное надо кушать. Давным-давно пора иметь и собственное мнение.

Напоминает случателей 1го канала.
Своё мнение иметь полезно. Кроме тех случаев, когда 1) это не своё мнение 2) это мнение опровергается фактами.

пипец, вы тупой.

Да уж, вам понадобился почти месяц, чтобы сформулировать столь аргументированный ответ :) Это уже мастерство, не каждый так сможет...