Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+16
#include <functional>
using namespace std;
class O{};
class foo
{
public:
constexpr static auto anyGarbage = O(O(O(O())));//:Жаль, что написать auto anyGarbage = O(O(O(O()))); нельзя.
O anyGarbage2 = O(O(O(O())));
private:
int var;
public:
std::function<void(int)> setter=[this](int s){(void)s;/*var=s;*/};
};
Я хочу написать свои property, принимающие лямбды в качестве параметра setter и getter. Как сделать friend лямбду?
http://liveworkspace.org/code/39082e70108502c2e44c4fe6c5762d9a
Запостил: 
USB,
26 Октября 2012
Follow us!
Что значит "не будут занимать память"? вычисляемое поле?
Хочется инкапсуляции - напиши геттер и/или сеттер, подумай о людях, которые будут читать твой код.
не всегда же их писать
а потом он вдруг понадобился и приходится все обращения к полю переписывать на getter\setter по всему коду
А потом вдруг! у тебя вместо intа - куда перестали влазить значения появился long.
И с полями ты переписываешь весь код.
Я сам геттеры с сеттерами, недолюбливаю, если что.
Это я на хабре с год назад примерно видел, профита я в этом особого не вижу (один хрен нужно геттер и сеттер писать). Разве что как постфактумный костыль.
Походу минусаторы сами слабо предметом владеют. Следует чётко понимать нужны тебе геттеры или нет.
Если такого понимания нет - лучше пиши их везде.
>у тебя вместо intа - куда перестали влазить значения появился long.
Или появилось дополнительное действие которое надо выполнять при изменении поля.
И ты снова переписываешь весь свой код.
> Или появилось дополнительное действие которое надо выполнять при изменении поля.
Тут да.
> У тебя вместо intа - куда перестали влазить значения появился long.
А вот тут геттер и сеттер не спасут. Т.к. и у них придется менять возвращаемый тип, ну и проверять весь код который ими пользовался - не сохранили ли там результат геттера в int.
Если старый код не использует верхние биты, например.
Но вообще да, с типами пример не очень удачный.
А потом получится как в BDE и Windows. В винде добавили функцию для получения свободного места на диске с 64битным результатом, старую пометили как deprecated. Новые программы теперь понимают большие диски. А вот BDE от delphi 7, к примеру, до сих пор при удачно выбранном свободном месте (в районе 4Gb, 8Gb, 12Gb...) выдает "Недостаточно места на диске".
Так что необходимость смены типа - это во многих случаях катастрофа...
Я вот за это минуснул ;) Хотя, конечно, с первой частью фразы согласен.
Скучные_обои.жпег
так в чем была проблема с лямбдой?
http://liveworkspace.org/code/c1f6c811cd8f4655f87086595abea4af
при желании можно тип проперти прямо в шаблоне указать она r или r+w и в специализации убирать либо получение, либо присваивание (чтобы не рантайм-еррор, а компайлтайм-еррор генерить)
Как вообще в С++ сделать свойства, которые не будут занимать память, которые вообще не будут проявляться никак, кроме как сущность времени компиляции (короче как в нормальных языках)?
Ну а если этими проблемами пренебречь - то проблем с реализацией никаких, равно как и пользы от этих "свойств".
сделать проперти, не хранящую даже this внешнего класса - т.е. предполагать её модификацию изолированной вещью в себе - значит сделать такую проперти бессмысленной и эквивалентной обычному члену-объекту в классе
ну а по-другому языковые средства не позволят
Да, и поля должны быть закрыты даже для наследников.
Во тогда это приблизится к настоящему ооп.
Оффтоп вопрос: в стандартной библиотеке C++ и в boost используется гнушный код-стайл. Но практически все гайдлайны по код-стайлу, которые я видел, советуют использовать совершенно другой стиль (имена классов с большой буквы, методы в кэмел-кейсе, etc). У Страуструпа в книге другой стиль. У Александреску - третий.
Внимание вопрос: почему программисты так не любят использовать стиль, принятый в стандартной библиотеке C++? Значит ли это, что он был выбран неудачно?
Мне больше по душе стиль, который используется в Qt - имена кэмел кейсом - классы с большой, методы с маленькой. Для меня он визуально выглядит приятней, чем обилие подчеркиваний.
Ну а если весь проект написан в стиле stl, то я конечно добавляю в него новые классы в стиле stl. Все-таки единство стиля важнее личных предпочтений.
Qt это монстр, который сам в себе покрывает функциональность stl своими QSomeThing (не удивлюсь, если там есть и замена built-in типам, навроде QInt или QBool), поэтому смешивание Qt и stl само по себе будет выглядеть инородно (ну кому нужно одновременно QString и std::string)
а вот когда весь проект написан на stl+boost, примешивание своих Oh::MyGoodness::MyAwesomeString выглядит некрасиво, будь они хоть трижды великолепны
Да нет, только всякие quint16.
> будет выглядеть инородно
> выглядит некрасиво, будь они хоть трижды великолепны
Так и я о том же :) Все-таки единство стиля важнее личных предпочтений.
P.S. Хотя, если автор проекта уже начал его в стиле Oh::MyGoodness::MyAwesomeString, при этом обильно юзая boost и stl... то, имхо, лучше придерживаться стиля автора, дабы не превращать код в еще большую помойку стилей.