Re[9]: Property на C++ без расширений языка
От: Batiskaf Израиль http://www.mult.ru/
Дата: 17.10.04 09:16
Оценка: 7 (2) +1
Уже не первый раз обсуждается проблема отсутствия пропертей в С++, и прежде чем находить приемлимое решение для имплементации свойств, предлагаю обсудить необходимы ли свойства вообще, и если да то какими они должны быть.

Мне кажется свойства безусловно нужны, но не в том виде, который навязывается идеологией Delphi\VB\C#, я как раз считаю что реализация методов get\set напротив призвана скрыть недостатки и невыразительность языков. Ведь если расмотреть назначение свойств, то стоит в любом случае отталкиваться от смысла структурирования данных — когда программист выводит структуру данных в результате декомпозиции определенной задачи, он ставит перед собой задачу моделирования какого то процесса, другими словами структура:

struct Data
{
    int a;
    string b;
    float c;
};


призвана моделировать такой процесс:

Data = f( a, b, c );


где в свою очередь:

a = f_a()
b = f_b()
c = f_c()


вот эти f_a, f_b и f_c и есть свойства класса Data. Они могут представлять собой список некоторых ограничений, которые накладываются на член класса, список проверок, значение по умолчанию, специфическое для данной структуры. Все это кодируется в get\set методах, реализуя свойство, но в результате получается неоднозначность, программист в коде получает возможность модифицировать значение члена класса двумя способами, и не совсем понятно каким способом модификации пользоваться. Положение усугуюляется еще и тем, что многие считают свойство как раз тем местом, где удобно встраивать обработчики событий на изменение значений свойства, и часто возникает ситуация когда новое значение члена класса нужно было бы пропустить через set для валидации, но вместе с тем нужно каким то образом разнять структуру от обработчиков события, иначе произойдет нежелательная цепочка вызовов. Все эти размышления и опыт использования свойств привели меня к следующему:

1). свойство и член класса это одно целое (без кода дополнительных регистраций и инициализаций, о которых программист может просто забыть).
2). свойство не должно генерировать события.
3). свойство должно содержать список требований, относящихся исключительно к этому полю, для комплексных валидаций структуры данных в целом нужно использовать отдельные методы, иначе как то нелогично получается, что свойство а знает о существовании свойства б и зависимости изменения значений этих двух свойств, вся эта информация по логике декомпозиции должна быть заключена в классе Data, а не методе set, который по логике вещей является функциональным продолжением все того же члена класса.
4). требования должны добавляться (и убираться) декларативным способом, в функциональной манере, как наиболее общая и понятная для любого технически грамотного человека форма записи функциональности ( a = f_a() ).

Реализация таких свойств рассмтривается тут:
Навеяно auto_value<> ™ ( от Кодт )
Автор: Batiskaf
Дата: 10.10.04
Will I live tomorrow? Well I just can't say
But I know for sure — I don't live today.
Jimi Hendrix.
Re[13]: Property на C++ без расширений языка
От: Batiskaf Израиль http://www.mult.ru/
Дата: 19.10.04 10:44
Оценка: 3 (2)
Здравствуйте, Alexey Chen, Вы писали:

AC>Здравствуйте, Batiskaf, Вы писали:


AC>>>В этом есть что-то полезное, но развивать на таком простом юзкейсе целую теорию.... это сильно.

B>>Почему теория, я отношусь к этому как к рекомендациям для более эффективного использования языка в каждодневном программировании, думаю любой программер по прошествии времени может написать книгу с рекомендациями, не хуже чем популярные гуру.
AC>Ну там все по пунктом и с выводами, которые на мой взгляд, например, ни то что бы не очевидны, но не всегда верны.
AC>Хотя, мое ИМХО, это лиш мое ИМХО
А детальнее можно, всегда рад поменять подход на более упорядоченный...

AC>>>То, что я предлагал (как и обычно) — это так, разминка для мозга, на практике вещь если и полезная, то разве что для однороности с COM-лйк кодом.

B>>Если бы цель этого всего была лишь в однородности с СОМ кодом... Свойства уже не раз обсуждались на форуме, полистайте.

AC>Для инвариантов и условий контракта? Для чего их еще можно использовать? Такие механизмы в язык надо встраивать, а не сбоку на соплях приклеевать.

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

AC>ИМХО, от повышения сложности конструкций, код надежнее не станет. Странно, что эта простая мысль настолько сложна для понимания. У плюсов есть два кардинально разных способа написания кода. На С++ и на собственном языке построенном на основе C++. Что я имею ввиду можно понять посмотрев какуюнить прогу на BOOST C++. Это не плюсы, это какой-то хитрый, понятный только посвящённым, диалект, причем не для сабонервных. Вы тоже предлагаете, свой диалект C++? С пропертями, в том виде в котором они удволетворяют вышим требованиям.


Я не знаю, против какого стиля программирования возмущаешься ты, но мне кажется что высшая степень профессионализма программиста заключается как раз в создании того самого языка, который и способен наиболее точно и просто выразить твою задачу. Заметь, когда программист в результате декомпозиции строит библиотеку и определяет взаимоствязи между элементами библиотеки, тем самым он как бы создает примитивы своего языка и настраивает синтаксические взаимосвязи между примитивами, в результате строчка obj1 + obj2 может быть значительно содержательнее и насыщенне событиями нежели сложение двух переменных базовых типов, тем самым программист заставляет свой компилятор производить генерации достаточно емких конструкций одной строкой кода. Все это справедливо для любого мало мальски продвинутого языка, можно сказать что современная область метапрограммирования существует давно (если рассматривать метапрограммирование как написание программы, которая способна генерить код, решающий нашу задачу), просто в С++ помимо традиционных средств построения языковых примитивов и настраивания взаимосвязей есть еще и более мощные средства, которые во многих случаях помогут сгенерить и сами примитивы, и настроить автоматически взаимоотношения между ними, и многое многое другое. Всего этого можно добиться благодаря хорошим декларативным средствам, которые в полную силу и применяются в бусте. Я не большой любитель десятиэтажных for_each с байндами и лямбдами, эти средства кодогенерации как раз перекрывают лишь доли процентов из того, что подразумевается под метакодогенерацией, в идеале же речь идет о таком стиле:


typedef BusinessService< MyAppService, MyDataService, MyFrontSiteService> MyBusinessService;


где

typedef AppService<Stateless, RemoteTransport, blabla> MyAppService;
typedef HttpServer<SessionContainer, blabla, blabla> MyFrontSiteService;


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


if( m_ObjState1 )
    OneExcecustionPath();
else if( m_ObjState2 )
    AnotherExcecutionPath();
else if( m_ObjState3 && m_bSocketClosed )
{
    switch (...)
    case:
    case:

bla bla
}


код полон шаманства крупнейших знатоков в области WinSocket, XWindow\Motiff, и прочей чепухи, из-за этого в программинг не привлекается масса специалистов которые не в состоянии разбираться со всем этим шаманстом, но логическое мышление которых способно моделировать сложные задачи повседневной жизни, при моделировании они предпочли бы мыслить функциональными блоками, нежели разбираться в чихарде флагов. Мне кажется что идеология буста во многом способствует выработке методологий с подобным уровнем решения задач, тем более что рынок ПО сегодня становится все более ориентирован на решение комплексных задач повседневной жизни, со сложными моделями, сегодня мало кого интересует просто красивая картинка или простое подключение сети, методы пересылки данных, методы хранения данных.
Will I live tomorrow? Well I just can't say
But I know for sure — I don't live today.
Jimi Hendrix.
Re[5]: Property на C++ без расширений языка
От: yxiie Украина www.enkord.com
Дата: 16.10.04 17:28
Оценка: 1 (1) +1
Здравствуйте, Alexey Chen, Вы писали:

...
AC> DECLARE_PROPERTY(Test,float,a);
AC> DECLARE_PROPERTY(Test,float,b);
...

тип в таких конструкциях всегда лучше в конце писать:

DECLARE_PROPERTY(Test,a,float);


а то типом может оказаться что-то типа pair<string, long> и будут проблемы
... << RSDN@Home 1.1.3 stable >>
Re[19]: Property на C++ без расширений языка
От: Batiskaf Израиль http://www.mult.ru/
Дата: 20.10.04 11:56
Оценка: 6 (1)
Здравствуйте, Alexey Chen, Вы писали:

AC>Здравствуйте, Batiskaf, Вы писали:


B>>Байнд вещь термоядерная, в сочетании со scope_guard — только благодаря этой маленькой фишке можно значительно повысить надежность кода и одновременно сократить количество строк кода с количеством потенциальных ошибок, замыкания(хотя есть решения и лучше), токенайзер, спирит, варианты, смарт поинтеры, thread, файловая система наконец появилась в С++, куча архитектурных решений.


AC>Та надежность о которой ты говоришь — это надежность первого порядка. Самая простая и достпная для понимания. И указанный спооб ее достижения не самый лучший.

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

AC>Я говорю про устойчивость кода к модификациям и прозрачность поиска ошибок по крашдампу. Про простоту отслеживания влияния нового кода на носледовнный, как по средствам явных зависимостей, так и по средствам ошибок. Про эту надежность кода вообще мало кто задумывается. Здесь уже всякие навесные мегафичи, типа того же бинда или вообще mpl'я — это одна большая бомба замедленного действия.

Библиотека решает эти проблемы лишь в общем виде, в той же джаве у тебя не будет готового решения для стратегии диагностик. И с самыми продвинутыми компонентными средами быстро можно приехать к тупику, никто не избавляет программиста от ошибок архитектурного уровня, где уже никакая диагностика не поможет. Вообще нужно спокойнее относиться к неудачам, если разработчик вовремя не понимает важности наращивания базовых сервисов, которые будут отделять предметные области и упрощать логику кода, то рано или поздно его заставят это понять, иначе как дать понять человеку что пора совершенствоваться
Will I live tomorrow? Well I just can't say
But I know for sure — I don't live today.
Jimi Hendrix.
Re: Property на C++ без расширений языка
От: Nuald Россия http://nuald.blogspot.com
Дата: 16.10.04 01:29
Оценка: 1 (1)
Здравствуйте, Undead, Вы писали:

U>Вот попробовал написать код поддержки так называемых свойств (как в C#).

U>Есть замечания и предложения по дизайну или ссылки на уже существующие реализации?

Статья: "Свойства в С++"
Автор(ы): Денис Майдыковский

В этой статье автор рассматривает различные способы реализации свойств в
стиле Visual Basic на C++. Некоторые способы специфичны для Visual C++,
тогда как другие годятся для применения в любой программе, написанной на
языке C++.
Re[3]: Property на C++ без расширений языка
От: vdimas Россия  
Дата: 16.10.04 09:39
Оценка: 1 (1)
Здравствуйте, Undead, Вы писали:

U>Вы писали:

V>>- можно сеттеры и геттеры вынести в параметры шаблона
U>Отлично, вынес в параметр шаблона, так намного экономней и красивей.

V>>- вместо хранения this объекта в шаблоне использовать смещение от this этого проперти

U>А вот этого не понял. Можно подробней?

да, можно,
есть такая штука в С++ — offsetof, причем, раз это константа, то ты ее можешь тоже как параметр шаблона указать.
а потом, из this инстанса проперти обратно по смещению можешь получить this объекта-парента, и таким образом — не нужно его хранить в экземпляре проперти.

...навороченное может получиться объявление, но тут и макросами разбавить не грех.
Property на C++ без расширений языка
От: Undead  
Дата: 15.10.04 19:40
Оценка: :)
Вот попробовал написать код поддержки так называемых свойств (как в C#).
Есть замечания и предложения по дизайну или ссылки на уже существующие реализации?

использование:
class Temp
{
public:
    Temp(): Length(this, getLength, setLength), len(0) {}
    Property<Temp, float, PropertyType::GetSet> Length;
private:
    float getLength() const { std::cout << "get called\n"; return len; }
    void setLength(float newLength) { std::cout << "set called\n"; len = newLength;}    
    float len;
};

int main()
{
    Temp t;
    t.Length = t.Length+2;
    std::cout << t.Length;
}


реализация:
#pragma once

namespace PropertyType { enum Type{ Get, Set, GetSet }; };
template <class Class, typename T, PropertyType::Type> class Property;

template <class Class, typename T>
class Property<Class, T, PropertyType::Get>
{
protected:
    typedef typename T (Class::*GetFunc)(void) const;
public:
    Property(Class* ptr, GetFunc g): obj_ptr(ptr), get(g) {}
    operator typename T() const { return (obj_ptr->*get)(); }
private:
    Class* obj_ptr;
    GetFunc get;
};

template <class Class, typename T>
class Property<Class, T, PropertyType::Set>
{
protected:
    typedef void (Class::*SetFunc)(typename T);
public:
    Property(Class* ptr, SetFunc s): obj_ptr(ptr), set(s) {}
    Property& operator=(const T& value)
    {
        (obj_ptr->*set)(value);
        return *this;
    }
private:
    Class* obj_ptr;
    SetFunc set;
};

template <class Class, typename T> 
class Property<Class, T, PropertyType::GetSet>:
    public Property<Class, T, PropertyType::Get>, public Property<Class, T, PropertyType::Set>
{
    typedef Property<Class, T, PropertyType::Get> BaseGet;
    typedef Property<Class, T, PropertyType::Set> BaseSet;
public:
    Property(Class* ptr, GetFunc g, SetFunc s): BaseGet(ptr, g), BaseSet(ptr, s) {}
    Property& operator=(const T& value)
    {
        BaseSet::operator=(value);
        return *this;
    }
};


Мои собственные замечания:
использование:
1) при использовании парит писать имя класса, которому свойство принадлежит
2) использование this в списке инициализации конструктора не безопасно.
реализация:
1) при множественном наследовании объект GetSet занимает 16 байт вместо положенных 12.
2) operator= не наследуется, поэтому приходится писать дублирующий код в GetSet
Re: Property на C++ без расширений языка
От: vdimas Россия  
Дата: 16.10.04 01:12
Оценка: +1
Здравствуйте, Undead, Вы писали:

U>Вот попробовал написать код поддержки так называемых свойств (как в C#).

U>Есть замечания и предложения по дизайну или ссылки на уже существующие реализации?

— можно сеттеры и геттеры вынести в параметры шаблона
— вместо хранения this объекта в шаблоне использовать смещение от this этого проперти

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

-------------------
__declspec(property ...)

а вообще, заканчивайте вы с этими пропертями на С++
Re[4]: Property на C++ без расширений языка
От: Undead  
Дата: 16.10.04 10:23
Оценка: -1
Здравствуйте, vdimas, Вы писали:

V>есть такая штука в С++ — offsetof, причем, раз это константа, то ты ее можешь тоже как параметр шаблона указать.

V>а потом, из this инстанса проперти обратно по смещению можешь получить this объекта-парента, и таким образом — не нужно его хранить в экземпляре проперти.

Ошибка: error C2027: use of undefined type 'Temp'
да и в любом случае объявление действительно слишком некрасивое получается.

V>...навороченное может получиться объявление, но тут и макросами разбавить не грех.

Макросы сами по себе грех. Хуже этого только ms specific
Re[5]: Property на C++ без расширений языка
От: Аноним  
Дата: 16.10.04 23:37
Оценка: :)
Здравствуйте, Shady, Вы писали:

S>Здравствуйте, vdimas, Вы писали:


V>>вот еще...

V>>просто не такое уж это востребованное качество — доступ к св-вам в стиле OPascal или там VB.
S>Ну почему же, очень удобная фича...

V>>на худой конец, если ОЧЕНЬ хочется, чем не устраивает __declspec(property ...)?, тем более, что он и индексированные проперти поддерживает (а C#, кстати, нет).

S>Ну да, ms specific? Увольте...

A C# не ms specific?
Re[8]: Property на C++ без расширений языка
От: Alexey Chen Чили  
Дата: 17.10.04 06:53
Оценка: :)
Здравствуйте, yxiie, Вы писали:

AC>>Хм, об этом я не подумал. А макрос на этом вообще не сломается? Скажет еще, что неправильное количество аргументов.

Y>ну если в таком виде как сейчас, то конечно сломается, но ведь можно заюзать workaround типа моего
Автор: yxiie
Дата: 08.10.04


Хум-хоу
Я лучше typedef напишу. Оно так проще и надежнее будет.
Re[14]: Property на C++ без расширений языка
От: Alexey Chen Чили  
Дата: 19.10.04 12:34
Оценка: -1
Здравствуйте, Batiskaf, Вы писали:

AC>>Хотя, мое ИМХО, это лиш мое ИМХО

B>А детальнее можно, всегда рад поменять подход на более упорядоченный...

Дык нет его — более упорядоченного подхода. Для меня, например, проперти — это лишь синтаксический сахар для Set/Get. Как будем на ваш список отображать? Вот инварианты и услови (пре/пост) надо в язык встраивать, и как расширения в некоторых компилерах они есть. Причина проста — эти проверки могут определятся, и чаще всего определяются, для интерфейса, а не реализации. Пропертя ведь тоже интерфейс к некоторому виртуально агрегированному виртуально существующему обьекту.

А вот стиль auto_value<int> мне не нравится. Хотя, это мое ИМХО А почему бы просто не добавить в стандарт, что примитивные типы ДОЛЖНЫ быть инициализированны нулем. Нет мы пририсуем мега конструкцию, и в язык добавлять ни че не будем, потому как известным способом это все делается. Даже больше скажу, года три или четыре назад я так и делал, но потом отказался от этой практики. Слишком неудобно получается.

Про лерический этюд о декларативном программировании и шаманстве с системным API могу сказать следующее: Есть разные области программирования. Например системное. Там это 'шаманство' — необходимые проф. навыки. А есть прикладное, там оно скрыто за интерфесом библиотек. Есть еще интересные звери, кторым и нужно 'нормальное функциональное описание нашей задачи' — их интеграторами называют или IT специалистами. Им наверное 'typedef BusinessService< MyAppService, MyDataService, MyFrontSiteService> MyBusinessService' могло бы понадобиться. Только нафиг им это не нужно, а нужны законченые отделимые блоки которые связываются файлами конфигов или простым скриптом, по известным протоколам. С++ тут вообще не приделах. Короче, это все теория не имеющая никакого отношения к реальности. Так, философия вокруг мегафич.

P.S.
Мне кажется что идеология буста во многом способствует выработке методологий с подобным уровнем решения задач, тем более что рынок ПО сегодня становится все более ориентирован на решение комплексных задач повседневной жизни, со сложными моделями, сегодня мало кого интересует просто красивая картинка или простое подключение сети, методы

Для этого есть замечательные _средства_разработки_. Не _языки_, а именно интегрированные инструмены. Я конечно понимаю что C++ очень гибкий язык, но он изначально системный и писать на нем после книги C++ за 21 день, практически бесполезно. Буст.... ладно не будем о грустном. Вобщем НЕ надо ИСПОЛЬЗОВАТЬ C++ ДЛЯ того, для ЧЕГО он НЕ ПРЕДНАЗНАЧЕН.
Re[2]: Property на C++ без расширений языка
От: Undead  
Дата: 16.10.04 07:22
Оценка:
Веселая ссылка, прямо один в один
Re[2]: Property на C++ без расширений языка
От: Shady Россия  
Дата: 16.10.04 07:40
Оценка:
Здравствуйте, vdimas, Вы писали:

V>а вообще, заканчивайте вы с этими пропертями на С++

а это типа намёк на c#?
... << RSDN@Home 1.1.3 stable >>
"Man feed machine
Machine feed man"
Peter Gabriel — OVO — The Tower That Ate People
Re[2]: Property на C++ без расширений языка
От: Undead  
Дата: 16.10.04 07:43
Оценка:
Вы писали:
V>- можно сеттеры и геттеры вынести в параметры шаблона
Отлично, вынес в параметр шаблона, так намного экономней и красивей.

V>- вместо хранения this объекта в шаблоне использовать смещение от this этого проперти

А вот этого не понял. Можно подробней?
Re[3]: Property на C++ без расширений языка
От: vdimas Россия  
Дата: 16.10.04 09:43
Оценка:
Здравствуйте, Shady, Вы писали:

V>>а вообще, заканчивайте вы с этими пропертями на С++

S>а это типа намёк на c#?

вот еще...
просто не такое уж это востребованное качество — доступ к св-вам в стиле OPascal или там VB.

на худой конец, если ОЧЕНЬ хочется, чем не устраивает __declspec(property ...)?, тем более, что он и индексированные проперти поддерживает (а C#, кстати, нет).
Re[4]: Property на C++ без расширений языка
От: Shady Россия  
Дата: 16.10.04 09:48
Оценка:
Здравствуйте, vdimas, Вы писали:

V>вот еще...

V>просто не такое уж это востребованное качество — доступ к св-вам в стиле OPascal или там VB.
Ну почему же, очень удобная фича...

V>на худой конец, если ОЧЕНЬ хочется, чем не устраивает __declspec(property ...)?, тем более, что он и индексированные проперти поддерживает (а C#, кстати, нет).

Ну да, ms specific? Увольте...
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
"Man feed machine
Machine feed man"
Peter Gabriel — OVO — The Tower That Ate People
Re[2]: Property на C++ без расширений языка
От: Alexey Chen Чили  
Дата: 16.10.04 10:26
Оценка:
Здравствуйте, vdimas, Вы писали:

V>т.е. само пропертине должно хранить данных, в параметрах шаблона можно все указать,

V>получишь 1 байт на проперти в целевом классе
А нулевой оверхед слабо сделать?


P.S.
В понедельник опубликую.
Re[3]: Property на C++ без расширений языка
От: Shady Россия  
Дата: 16.10.04 11:11
Оценка:
Здравствуйте, Alexey Chen, Вы писали:

AC>P.S.

AC>В понедельник опубликую.
А почему в понедельник? Это так долго...
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
"Man feed machine
Machine feed man"
Peter Gabriel — OVO — The Tower That Ate People
Re[4]: Property на C++ без расширений языка
От: Alexey Chen Чили  
Дата: 16.10.04 15:16
Оценка:
Здравствуйте, Shady, Вы писали:

S>Здравствуйте, Alexey Chen, Вы писали:


AC>>P.S.

AC>>В понедельник опубликую.
S>А почему в понедельник? Это так долго...

Ну если думать не хочется, могу сейчас На самом деле, все просто тривиально.
Идея в том, что ...
( для http://www.rsdn.ru/Forum/Message.aspx?mid=854815&amp;only=1 )
  union {
    getset_property<Temp, float, getLength, setLength> Length;
    get_property<Temp, float, getLength> LengthGetter;
  };
Так будет константный оверхед.

Это, кстати, решает проблему инициализации всех пропертей (вообще это ub, но работать будет) с которой у автора ошибка.
Можно еще реализовать пропертя без хранения указателя на контейнер, тогда можно поместить в обьеденени какой либо мембер котейнера, и оверхед будет нулевой.
Re[5]: Property на C++ без расширений языка
От: Undead  
Дата: 16.10.04 16:22
Оценка:
Здравствуйте, Alexey Chen, Вы писали:

AC>Это, кстати, решает проблему инициализации всех пропертей (вообще это ub, но работать будет) с которой у автора ошибка.

Я заметил ошибку, попытался модернуть, но как-то тут с этим туго оказалось

AC>Можно еще реализовать пропертя без хранения указателя на контейнер, тогда можно поместить в обьеденени какой либо мембер котейнера, и оверхед будет нулевой.

Интрузивный подход.
Re[4]: Property на C++ без расширений языка
От: Alexey Chen Чили  
Дата: 16.10.04 16:32
Оценка:
Здравствуйте, vdimas, Вы писали:

V>>>- вместо хранения this объекта в шаблоне использовать смещение от this этого проперти

U>>А вот этого не понял. Можно подробней?

V>да, можно,

V>есть такая штука в С++ — offsetof, причем, раз это константа, то ты ее можешь тоже как параметр шаблона указать.
V>а потом, из this инстанса проперти обратно по смещению можешь получить this объекта-парента, и таким образом — не нужно его хранить в экземпляре проперти.

Странно эта штука местами работает...

V>...навороченное может получиться объявление, но тут и макросами разбавить не грех.

Ну как вариант, набрасал тут ...

#include <stdio.h>

#define DECLARE_PROPERTY_(T,type,Set,Get,name) \
struct __Property_##name; friend struct __Property_##name; \
struct __Property_##name { \
  operator type () const { return resolve_(this,1)->Get(); } \
  __Property_##name& \
  operator = (const type& a) { resolve_(this,1)->Set(a); return *this; } \
  \
  template <class fake> static T* resolve_(const void* p,fake) {\
    T* _ = 0; \
    return (T*)( (char*)p - ( (char*)(&_->a) - (char*)(_) ) );\
  } \
}
#define PROPERTY(name) __Property_##name name
#define DECLARE_PROPERTY(T,type,name) DECLARE_PROPERTY_(T,type,set_##name,get_##name,name)

struct Test {

  DECLARE_PROPERTY(Test,float,a);
  DECLARE_PROPERTY(Test,float,b);

  union {
    PROPERTY(a);
    PROPERTY(b);
  };

private:

  float a_;
  float b_;
  float get_a() const  { printf("Test::Get1\n"); return a_; }
  void set_a(float val) { printf("Test::Set1\n"); a_ = val; }
  float get_b() const  { printf("Test::Get1\n"); return b_; }
  void set_b(float val) { printf("Test::Set1\n"); b_ = val; }

};
  
int main() {
  Test* t = new Test;
  printf("%d\n",sizeof(*t));
  t->a = 2;
  printf("%f\n",float(t->a));
  return 0;
}


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

Кстати, вопрос нашим Гуру, так вообще делать можно? А то некоторые компилеры как-то странно ругаются.

Не работает с: Borland C++ (кто бы сомнивался), Gcc 2.95 (компиллер еррор), Sun C++ 5.5 (момбер обьеденения не может иметь оперетор = ).
Работает с: MS C++ 6/7, MWCC 3.x, DMC 8.4x, ICL8, GCC 3.2
Re[6]: Property на C++ без расширений языка
От: Alexey Chen Чили  
Дата: 16.10.04 18:08
Оценка:
Здравствуйте, yxiie, Вы писали:

Y>DECLARE_PROPERTY(Test,a,float);

Y>а то типом может оказаться что-то типа pair<string, long> и будут проблемы

Хм, об этом я не подумал. А макрос на этом вообще не сломается? Скажет еще, что неправильное количество аргументов.
Re[6]: Property на C++ без расширений языка
От: _nn_ www.nemerleweb.com
Дата: 16.10.04 19:41
Оценка:
Здравствуйте, yxiie, Вы писали:

Y>Здравствуйте, Alexey Chen, Вы писали:


Y>...

AC>> DECLARE_PROPERTY(Test,float,a);
AC>> DECLARE_PROPERTY(Test,float,b);
Y>...

Y>тип в таких конструкциях всегда лучше в конце писать:


Y>
Y>DECLARE_PROPERTY(Test,a,float);
Y>


Y>а то типом может оказаться что-то типа pair<string, long> и будут проблемы


Почитайте здесь
Автор: SergH
Дата: 08.10.04
и проблем не будет
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[7]: Property на C++ без расширений языка
От: yxiie Украина www.enkord.com
Дата: 16.10.04 20:02
Оценка:
Здравствуйте, Alexey Chen, Вы писали:

AC>Здравствуйте, yxiie, Вы писали:


AC>
Y>>DECLARE_PROPERTY(Test,a,float);
AC>

Y>>а то типом может оказаться что-то типа pair<string, long> и будут проблемы

AC>Хм, об этом я не подумал. А макрос на этом вообще не сломается? Скажет еще, что неправильное количество аргументов.


ну если в таком виде как сейчас, то конечно сломается, но ведь можно заюзать workaround типа моего
Автор: yxiie
Дата: 08.10.04
... << RSDN@Home 1.1.3 stable >>
Re[7]: Property на C++ без расширений языка
От: yxiie Украина www.enkord.com
Дата: 16.10.04 20:02
Оценка:
Здравствуйте, _nn_, Вы писали:

__>Здравствуйте, yxiie, Вы писали:


Y>>Здравствуйте, Alexey Chen, Вы писали:


Y>>...

AC>>> DECLARE_PROPERTY(Test,float,a);
AC>>> DECLARE_PROPERTY(Test,float,b);
Y>>...

Y>>тип в таких конструкциях всегда лучше в конце писать:


Y>>
Y>>DECLARE_PROPERTY(Test,a,float);
Y>>


Y>>а то типом может оказаться что-то типа pair<string, long> и будут проблемы


__>Почитайте здесь
Автор: SergH
Дата: 08.10.04
и проблем не будет




может вы бы сразу ссылку на мой
Автор: yxiie
Дата: 08.10.04
ответ дали бы?
... << RSDN@Home 1.1.3 stable >>
Re[8]: Property на C++ без расширений языка
От: _nn_ www.nemerleweb.com
Дата: 17.10.04 06:23
Оценка:
Здравствуйте, yxiie, Вы писали:

Y>Здравствуйте, _nn_, Вы писали:


__>>Здравствуйте, yxiie, Вы писали:


Y>>>Здравствуйте, Alexey Chen, Вы писали:


Y>>>...

AC>>>> DECLARE_PROPERTY(Test,float,a);
AC>>>> DECLARE_PROPERTY(Test,float,b);
Y>>>...

Y>>>тип в таких конструкциях всегда лучше в конце писать:


Y>>>
Y>>>DECLARE_PROPERTY(Test,a,float);
Y>>>


Y>>>а то типом может оказаться что-то типа pair<string, long> и будут проблемы


__>>Почитайте здесь
Автор: SergH
Дата: 08.10.04
и проблем не будет


Y>


Y> может вы бы сразу ссылку на мой
Автор: yxiie
Дата: 08.10.04
ответ дали бы?


Лень было идти по ветке
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[10]: Property на C++ без расширений языка
От: Alexey Chen Чили  
Дата: 17.10.04 12:55
Оценка:
Здравствуйте, Batiskaf, Вы писали:

B>Реализация таких свойств рассмтривается тут:

B>Навеяно auto_value&lt;&gt; ™ ( от Кодт )
Автор: Batiskaf
Дата: 10.10.04


В этом есть что-то полезное, но развивать на таком простом юзкейсе целую теорию.... это сильно.

Меня конечно будут пинать ногами и говорить, что я ничего не смыслю в высоком искусстве, НО C++ — это высокоуровневый АССЕМБЛЕР, и не надо делать из него черти-знает-что с хвостиком.

То, что я предлагал (как и обычно) — это так, разминка для мозга, на практике вещь если и полезная, то разве что для однороности с COM-лйк кодом.
Re[11]: Property на C++ без расширений языка
От: Batiskaf Израиль http://www.mult.ru/
Дата: 17.10.04 13:20
Оценка:
Здравствуйте, Alexey Chen, Вы писали:

AC>Здравствуйте, Batiskaf, Вы писали:


B>>Реализация таких свойств рассмтривается тут:

B>>Навеяно auto_value&lt;&gt; ™ ( от Кодт )
Автор: Batiskaf
Дата: 10.10.04


AC>В этом есть что-то полезное, но развивать на таком простом юзкейсе целую теорию.... это сильно.

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

AC>Меня конечно будут пинать ногами и говорить, что я ничего не смыслю в высоком искусстве, НО C++ — это высокоуровневый АССЕМБЛЕР, и не надо делать из него черти-знает-что с хвостиком.


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

Асм тоже язык, и на нем люди тоже стараются писать с меньшими для себя проблемами.

AC>То, что я предлагал (как и обычно) — это так, разминка для мозга, на практике вещь если и полезная, то разве что для однороности с COM-лйк кодом.


Если бы цель этого всего была лишь в однородности с СОМ кодом... Свойства уже не раз обсуждались на форуме, полистайте.
Will I live tomorrow? Well I just can't say
But I know for sure — I don't live today.
Jimi Hendrix.
Re[3]: Property на C++ без расширений языка
От: vdimas Россия  
Дата: 17.10.04 17:12
Оценка:
Здравствуйте, Alexey Chen, Вы писали:

AC>Здравствуйте, vdimas, Вы писали:


V>>т.е. само пропертине должно хранить данных, в параметрах шаблона можно все указать,

V>>получишь 1 байт на проперти в целевом классе
AC>А нулевой оверхед слабо сделать?

Нулевой оверхед невозможен в принципе.
Компилятор ВЫНУЖДЕН гарантировать уникальный адрес каждого экземпляра класса (не важно, поля-мембера или же глобальной/локальной переменной). Эта фишка компиляторно зависима, VC делает размер 0-го класса 1 байт, Борланд — 8 байт и т.д.

Другое дело, что можно использовать нечто, типа PropertyWithValue, т.е. хранить и целевое значение в классе-свойстве (это и так требуется в 90% случаев грубо ), то здесь и есть шанс получить твой 0-ой оверхед.
Re[4]: Property на C++ без расширений языка
От: Alexey Chen Чили  
Дата: 17.10.04 21:30
Оценка:
Здравствуйте, vdimas, Вы писали:

AC>>А нулевой оверхед слабо сделать?

V>Нулевой оверхед невозможен в принципе.
V>Компилятор ВЫНУЖДЕН гарантировать уникальный адрес каждого экземпляра класса (не важно, поля-мембера или же глобальной/локальной переменной). Эта фишка компиляторно зависима, VC делает размер 0-го класса 1 байт, Борланд — 8 байт и т.д.
Может быть всетаки не ВООБЩЕ, а в общем случае. Разница весьма существенная. Для некоторых случаев это возможно. Как именно, пример я привел.Но это в больешй степени зарядка для ума, чем практический приём. Как впрочем и сами пропертя в C++.

V>Другое дело, что можно использовать нечто, типа PropertyWithValue, т.е. хранить и целевое значение в классе-свойстве (это и так требуется в 90% случаев грубо ), то здесь и есть шанс получить твой 0-ой оверхед.

Скажем так, существует реализация проперти с нулевым размером. Константный оверхед достигается обеденением пропертей в union.
Если в классе есть мемберы поля, а они обычно есть, можно положить такой мембер в тот же union, и будет нулевой оверхед.
Re[12]: Property на C++ без расширений языка
От: Alexey Chen Чили  
Дата: 17.10.04 21:54
Оценка:
Здравствуйте, Batiskaf, Вы писали:

AC>>В этом есть что-то полезное, но развивать на таком простом юзкейсе целую теорию.... это сильно.

B>Почему теория, я отношусь к этому как к рекомендациям для более эффективного использования языка в каждодневном программировании, думаю любой программер по прошествии времени может написать книгу с рекомендациями, не хуже чем популярные гуру.
Ну там все по пунктом и с выводами, которые на мой взгляд, например, ни то что бы не очевидны, но не всегда верны.
Хотя, мое ИМХО, это лиш мое ИМХО

AC>>То, что я предлагал (как и обычно) — это так, разминка для мозга, на практике вещь если и полезная, то разве что для однороности с COM-лйк кодом.

B>Если бы цель этого всего была лишь в однородности с СОМ кодом... Свойства уже не раз обсуждались на форуме, полистайте.

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

ИМХО, от повышения сложности конструкций, код надежнее не станет. Странно, что эта простая мысль настолько сложна для понимания. У плюсов есть два кардинально разных способа написания кода. На С++ и на собственном языке построенном на основе C++. Что я имею ввиду можно понять посмотрев какуюнить прогу на BOOST C++. Это не плюсы, это какой-то хитрый, понятный только посвящённым, диалект, причем не для сабонервных. Вы тоже предлагаете, свой диалект C++? С пропертями, в том виде в котором они удволетворяют вышим требованиям.
Re[5]: Property на C++ без расширений языка
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 18.10.04 01:07
Оценка:
Здравствуйте, Undead, Вы писали:

V>>есть такая штука в С++ — offsetof, причем, раз это константа, то ты ее можешь тоже как параметр шаблона указать.

V>>а потом, из this инстанса проперти обратно по смещению можешь получить this объекта-парента, и таким образом — не нужно его хранить в экземпляре проперти.
U>Ошибка: error C2027: use of undefined type 'Temp'
U>да и в любом случае объявление действительно слишком некрасивое получается.

Ну, во-первых — правильные компиляторы, а во-вторых — макросы.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[5]: От модератора
От: Павел Кузнецов  
Дата: 19.10.04 01:50
Оценка:
Ветка
Автор: yxiie
Дата: 16.10.04
с обсуждением отношения к макросам выделена в отдельную тему.
--
ПК
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[15]: Property на C++ без расширений языка
От: Batiskaf Израиль http://www.mult.ru/
Дата: 19.10.04 17:17
Оценка:
Здравствуйте, Alexey Chen, Вы писали:

AC>Здравствуйте, Batiskaf, Вы писали:


AC>>>Хотя, мое ИМХО, это лиш мое ИМХО

B>>А детальнее можно, всегда рад поменять подход на более упорядоченный...

AC>Дык нет его — более упорядоченного подхода. Для меня, например, проперти — это лишь синтаксический сахар для Set/Get. Как будем на ваш список отображать? Вот инварианты и услови (пре/пост) надо в язык встраивать, и как расширения в некоторых компилерах они есть. Причина проста — эти проверки могут определятся, и чаще всего определяются, для интерфейса, а не реализации. Пропертя ведь тоже интерфейс к некоторому виртуально агрегированному виртуально существующему обьекту.

Ну так и к чему тогда свойства нужны, вон в джаве не было их, и никто не обижается, все на уровне соглашений именования. Если это все преимущества тогда я отвечу, что для меня есть проперти — это неразрывное целое с членом класса, двух сущностей быть не должно, это лишь мешает, и все требования, которые реализуют сегодня в гетах и сетах хотелось бы выражать на месте, и какими средствами это будет сделано это уже меня не интересует, пусть дотнетчики атрибуты наприбумывают, джависты аннотации какие то, главное что в одной строчке на месте объявления поля будет четко прописано по каким правилам может модифицироваться значение этого поля, в декларативной манере, по человечески. Очень здорово что эти вещи можно выражать в сегодняшнем С++ без введения дополнительных конструкций языка, в дотнете к примеру, при все его навороченности такого не получится проделать, так что остаются геты и сэты. Но!! Прийдет то время когда вся эта недостающая метаинформация будет ой как необходима в рантайме, и при каком то экзотическом виде сериализации структуры в другой формат ( например в HTML, идея рассматривается тут : клик хере
Автор: Batiskaf
Дата: 23.08.04
) было бы не плохо еще и содержимое сэтов и гетов выпотрошить туда же ( в джава скрипте к примеру ), и вот тогда на проперти взглянут немного под другим углом, не через призму синтаксического сахара.

AC>А вот стиль auto_value<int> мне не нравится. Хотя, это мое ИМХО А почему бы просто не добавить в стандарт, что примитивные типы ДОЛЖНЫ быть инициализированны нулем. Нет мы пририсуем мега конструкцию, и в язык добавлять ни че не будем, потому как известным способом это все делается. Даже больше скажу, года три или четыре назад я так и делал, но потом отказался от этой практики. Слишком неудобно получается.

Да auto_value<int> тут как раз не причем, это так, workaround, мне сама форма кодирования метаданных симпатична, на этой фишке можно много самых разных идиом построить, бесконечные свойства можно на поле нагружать, можно так эти насадки написать что потом в рантайме в абстрактной форме получить ( сегодняшняя рефлексия в джавоидах это просто детский лепет по сравнению с этими идиомами ), я не сторонник событий над полями структуры, но если кто то любит то можно соорудить очередную насадку, которая будет подписывать на пре и пост модифай, и все это будет кодироваться с пол пинка одно строкой кода, мониторинг, полиси всяческие, которые опять же можно ставить и снимать в одной строке кода...

AC>Про лерический этюд о декларативном программировании и шаманстве с системным API могу сказать следующее: Есть разные области программирования. Например системное. Там это 'шаманство' — необходимые проф. навыки. А есть прикладное, там оно скрыто за интерфесом библиотек. Есть еще интересные звери, кторым и нужно 'нормальное функциональное описание нашей задачи' — их интеграторами называют или IT специалистами. Им наверное 'typedef BusinessService< MyAppService, MyDataService, MyFrontSiteService> MyBusinessService' могло бы понадобиться. Только нафиг им это не нужно, а нужны законченые отделимые блоки которые связываются файлами конфигов или простым скриптом, по известным протоколам. С++ тут вообще не приделах. Короче, это все теория не имеющая никакого отношения к реальности. Так, философия вокруг мегафич.


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


AC>P.S.

AC>Мне кажется что идеология буста во многом способствует выработке методологий с подобным уровнем решения задач, тем более что рынок ПО сегодня становится все более ориентирован на решение комплексных задач повседневной жизни, со сложными моделями, сегодня мало кого интересует просто красивая картинка или простое подключение сети, методы

AC>Для этого есть замечательные _средства_разработки_. Не _языки_, а именно интегрированные инструмены. Я конечно понимаю что C++ очень гибкий язык, но он изначально системный и писать на нем после книги C++ за 21 день, практически бесполезно.

Ну вот, я к примеру на интеллиджей поработал, и на эклипсе немного. И знаешь что мне это все напоминает, сишные макроподстановки и старые юниксовые пёрл скрипты которые генерили код сериализации для С++ классов. Особенно доклеты, когда класс с разметкой передается парсеру доклета и тот строит хмл для энтити бина, который потом скормится либе которая будет генерить SQL запросы в базу для десериализации персонов из оракла. 10 лет такие фишки на плюсах используются в тихую, а тут оказывается что это интегрировать нужно. А главное понять не могут, что нужен кардинально другой метод описания структур данных, и пропертя в том представлении которое предлагают в ВБ или C# это уже вчерашний день.

AC>Буст.... ладно не будем о грустном. Вобщем НЕ надо ИСПОЛЬЗОВАТЬ C++ ДЛЯ того, для ЧЕГО он НЕ ПРЕДНАЗНАЧЕН.

По твоему Буст нужно было не на С++ -е реализовывать? Тогда на чем, если не секрет?
Will I live tomorrow? Well I just can't say
But I know for sure — I don't live today.
Jimi Hendrix.
Re[16]: Property на C++ без расширений языка
От: Alexey Chen Чили  
Дата: 19.10.04 17:53
Оценка:
Здравствуйте, Batiskaf, Вы писали:

B>Да auto_value<int> тут как раз не причем, это так, workaround, мне сама форма кодирования метаданных симпатична, на этой фишке можно много самых разных идиом построить, бесконечные свойства можно на поле нагружать, можно так эти насадки написать что потом в рантайме в абстрактной форме получить ( сегодняшняя рефлексия в джавоидах это просто детский лепет по сравнению с этими идиомами ), я не сторонник событий над полями структуры, но если кто то любит то можно соорудить очередную насадку, которая будет подписывать на пре и пост модифай, и все это будет кодироваться с пол пинка одно строкой кода, мониторинг, полиси всяческие, которые опять же можно ставить и снимать в одной строке кода...

О! Теперь понятно к чему все это было. Мысли здравые и правильные. Однако способ применения на практике от меня укользает.Да и к пропертям, в обыденном смысле, это уже отношения имеет очень мало.

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

Естественно.

AC>>Для этого есть замечательные _средства_разработки_. Не _языки_, а именно интегрированные инструмены. Я конечно понимаю что C++ очень гибкий язык, но он изначально системный и писать на нем после книги C++ за 21 день, практически бесполезно.

B>Ну вот, я к примеру на интеллиджей поработал, и на эклипсе немного. И знаешь что мне это все напоминает, сишные макроподстановки и старые юниксовые пёрл скрипты которые генерили код сериализации для С++ классов.
Я вообще то не о том. Точнее и об этом тоже, но в большей степени, про _среду_ не только разработки но и _исполнения_. Про то, что продукт разработанный в этой среде, саму среду _разрушить_не_может_. А все прелести метопрограмминга в C++ перечеркиваются одним мемори денсом, от которого никто не застрахован.

AC>>Буст.... ладно не будем о грустном. Вобщем НЕ надо ИСПОЛЬЗОВАТЬ C++ ДЛЯ того, для ЧЕГО он НЕ ПРЕДНАЗНАЧЕН.

B>По твоему Буст нужно было не на С++ -е реализовывать? Тогда на чем, если не секрет?
Давай определим что в твоем понимании буст. В моем, это куча неэфективного заумного и абсолютно бесполезного кода, за очень редким исключением. Может быть ты имеешь в виду концепции биндинга и тулкит для метапрограмминга? Дык я предпочел бы видить полноценный шаблонный препроцессор/транслятор встроенный в средство разработки, а не это убожество. Причем с возможностью препроцессирование в C++, для оценки что же собственно получилось.
Re[17]: Property на C++ без расширений языка
От: Batiskaf Израиль http://www.mult.ru/
Дата: 20.10.04 10:21
Оценка:
Здравствуйте, Alexey Chen, Вы писали:

AC>>>Для этого есть замечательные _средства_разработки_. Не _языки_, а именно интегрированные инструмены. Я конечно понимаю что C++ очень гибкий язык, но он изначально системный и писать на нем после книги C++ за 21 день, практически бесполезно.

B>>Ну вот, я к примеру на интеллиджей поработал, и на эклипсе немного. И знаешь что мне это все напоминает, сишные макроподстановки и старые юниксовые пёрл скрипты которые генерили код сериализации для С++ классов.
AC>Я вообще то не о том. Точнее и об этом тоже, но в большей степени, про _среду_ не только разработки но и _исполнения_. Про то, что продукт разработанный в этой среде, саму среду _разрушить_не_может_. А все прелести метопрограмминга в C++ перечеркиваются одним мемори денсом, от которого никто не застрахован.

Полностью согласен, рантайм у С++ сегодня желает быть лучше, точнее он соответствует потребностям шестилетней давности... Про новые фичи языка я не говорю, даже с тем что есть не плохо было бы получить более упорядоченную среду выполнения, существует же боее менее приемлимое решение для С, типа там shared crt, было бы не плохо иметь один общий базовый менеджер памяти на весь процесс, централизованную таблицу type_info, с тем что бы информация о типе в рамках аппликации во всех модулях была идентична всегда, многое другое — все это можно получить без изменения стандарта, просто получить добротную реализацию.

AC>>>Буст.... ладно не будем о грустном. Вобщем НЕ надо ИСПОЛЬЗОВАТЬ C++ ДЛЯ того, для ЧЕГО он НЕ ПРЕДНАЗНАЧЕН.

B>>По твоему Буст нужно было не на С++ -е реализовывать? Тогда на чем, если не секрет?
AC>Давай определим что в твоем понимании буст. В моем, это куча неэфективного заумного и абсолютно бесполезного кода, за очень редким исключением. Может быть ты имеешь в виду концепции биндинга и тулкит для метапрограмминга? Дык я предпочел бы видить полноценный шаблонный препроцессор/транслятор встроенный в средство разработки, а не это убожество. Причем с возможностью препроцессирование в C++, для оценки что же собственно получилось.

Байнд вещь термоядерная, в сочетании со scope_guard — только благодаря этой маленькой фишке можно значительно повысить надежность кода и одновременно сократить количество строк кода с количеством потенциальных ошибок, замыкания(хотя есть решения и лучше), токенайзер, спирит, варианты, смарт поинтеры, thread, файловая система наконец появилась в С++, куча архитектурных решений.
Will I live tomorrow? Well I just can't say
But I know for sure — I don't live today.
Jimi Hendrix.
Re[18]: Property на C++ без расширений языка
От: Alexey Chen Чили  
Дата: 20.10.04 10:39
Оценка:
Здравствуйте, Batiskaf, Вы писали:

B>Байнд вещь термоядерная, в сочетании со scope_guard — только благодаря этой маленькой фишке можно значительно повысить надежность кода и одновременно сократить количество строк кода с количеством потенциальных ошибок, замыкания(хотя есть решения и лучше), токенайзер, спирит, варианты, смарт поинтеры, thread, файловая система наконец появилась в С++, куча архитектурных решений.


Та надежность о которой ты говоришь — это надежность первого порядка. Самая простая и достпная для понимания. И указанный спооб ее достижения не самый лучший. Еще ещё и другая надежность кода, о которой беспокоятся люди разрабатывающие/поддерживающие несколько продуктов существующих достаточно долго и имеющих большую клиенскую базу при этом развиваясь.

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

То же, что так любят мусолить на программерских форумах, всякие супер макросы и ультра бинды — это пшик. теоретические изыскания, зарядка для мозга. Несмоненно, практика черпает идеи из фундаментальных теорий, но вот прямо так это использовать....
Re[4]: Property на C++ без расширений языка
От: Шахтер Интернет  
Дата: 26.10.04 20:15
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Undead, Вы писали:


U>>Вы писали:

V>>>- можно сеттеры и геттеры вынести в параметры шаблона
U>>Отлично, вынес в параметр шаблона, так намного экономней и красивей.

V>>>- вместо хранения this объекта в шаблоне использовать смещение от this этого проперти

U>>А вот этого не понял. Можно подробней?

V>да, можно,

V>есть такая штука в С++ — offsetof,

Только для POD.
... << RSDN@Home 1.1.0 stable >>
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[19]: Property на C++ без расширений языка
От: yxiie Украина www.enkord.com
Дата: 27.10.04 07:28
Оценка:
Здравствуйте, Alexey Chen, Вы писали:

AC>Я говорю про устойчивость кода к модификациям и прозрачность поиска ошибок по крашдампу. Про простоту отслеживания влияния нового кода на носледовнный, как по средствам явных зависимостей, так и по средствам ошибок. Про эту надежность кода вообще мало кто задумывается. Здесь уже всякие навесные мегафичи, типа того же бинда или вообще mpl'я — это одна большая бомба замедленного действия.


ну почему же бомба. просто нужно без фанатизма этот mpl использовать.
еще есть boost::preprocessor — тоже здорово помогает.
... << RSDN@Home 1.1.3 stable >>
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.