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

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

M>А как по мне, в Delphi и BCB он был очень неплох

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

You will always get what you always got
  If you always do  what you always did

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

J>Мне вот лично сигналы с несколькими динамическими подписчиками подписчиками понадобились за все время ровно один раз, а все остальное время рулил простой как валенок boost::function.
это удобно в MVP, MVC

о_О>>Якобы тяжесть этого механизма?
J>Якобы? Поддержка многопоточности и подписки/отписки у нас теперь бесплатна?
не обязательно их делать потокобезопасными. я бы сказал, что это лишнее

о_О>>Всё это цветочки, по сравнению с бустом, в котором потокобезопасные сигналы быстрее обычных (академики постарались).
J>Быстрее простого　boost::function? (это я так напоминаю, что ты все хочешь в function засунуть.)
я хочу отдельный встроенный тип delegate, например как в C#, дающий хороший байткод, и дедукцию компилятором (сотни ошибок bind при малейшей ошибки уже достали)

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

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

E>Замени delegate на boost::signal2 + boost::bind и будет тебе счастье
нету счастья

Здравствуйте, о_О, Вы писали:

о_О>>>Всё это цветочки, по сравнению с бустом, в котором потокобезопасные сигналы быстрее обычных (академики постарались).
J>>Быстрее простого　boost::function? (это я так напоминаю, что ты все хочешь в function засунуть.)
о_О>я хочу отдельный встроенный тип delegate, например как в C#, дающий хороший байткод, и дедукцию компилятором (сотни ошибок bind при малейшей ошибки уже достали)

Кстати насчет кода — мне кажется, жить стало бы сильно веселей, если бы можно было взять указатель на член как просто указатель на функцию (+ this). Т.е. был бы встроенный тип данных, который бы содержал собственно указатель на функцию и указатель на объект:

struct S
{
  virtual void f()
};

struct C : S
{
  void f();
};

typedef void (### PF)();

S* s = new C;

PF pf = &s->f; // тут генерируется код, который лезет в vtbl и находит C::f()

pf(); // в pf лежат два указателя - адрес C::f и s. В результате произойдет вызов s->C::f()

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

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

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

E>Кстати насчет кода — мне кажется, жить стало бы сильно веселей, если бы можно было взять указатель на член как просто указатель на функцию (+ this). Т.е. был бы встроенный тип данных, который бы содержал собственно указатель на функцию и указатель на объект
не сыпь мне соль на рану...

E>Кстати насчет кода — мне кажется, жить стало бы сильно веселей, если бы можно было взять указатель на член как просто указатель на функцию (+ this). Т.е. был бы встроенный тип данных, который бы содержал собственно указатель на функцию и указатель на объект
Ну, bind + mem_fun спасут отца русской демократии, нет?

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

E>мне кажется, жить стало бы сильно веселей, если бы можно было взять указатель на член как просто указатель на функцию (+ this). Т.е. был бы встроенный тип данных, который бы содержал собственно указатель на функцию и указатель на объект:

в Borland С++ это называется __closure

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

K>почему ни в одном стандарте с++ до сих пор не предложили нормальные пропертя?

Конечно, надо их ввести! А то как-то стыдно. Откроешь какой-нибудь файл на java или C# и пожалуйста — десяток полей, десяток геттеров, десяток сеттеров, сотня строк, выглядит солидно и убедительно. А на С++ позор один — несчастный struct на 10 строк и все. А уж если class, то в нем почти что и нет замечательных методов с телом return x; или this.x = x. Стыд и позор!

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


MZ>Отвечу коротко и надеюсь ясно: потому что нахрен они никому не нужны.

Добавлю коротко и ясно — они есть в Visual C++ (__declspec(property)) , но никем не используются по той же самой причине.

Вот из MSDN

// declspec_property.cpp
struct S {
   int i;
   void putprop(int j) { 
      i = j;
   }

   int getprop() {
      return i;
   }

   __declspec(property(get = getprop, put = putprop)) int the_prop;
};

int main() {
   S s;
   s.the_prop = 5;
   return s.the_prop;
}

Здравствуйте, Pavel Dvorkin, Вы писали:

MZ>>... потому что нахрен они никому не нужны.

PD>Добавлю коротко и ясно — они есть в Visual C++ (__declspec(property)) , но никем не используются по той же самой причине.

Они не используются, потому что при переходе на другую платформу придётся всё переписывать

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


W>Они не используются, потому что при переходе на другую платформу придётся всё переписывать

1. Не все. Но многое, верно.
2. В Visual C++ много есть такого, чего нет в стандарте, но тем не менее используется

Здравствуйте, Pavel Dvorkin, Вы писали:

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

MZ>>Отвечу коротко и надеюсь ясно: потому что нахрен они никому не нужны.

PD>Добавлю коротко и ясно — они есть в Visual C++ (__declspec(property)) , но никем не используются по той же самой причине.

Говорите за себя. Я использую.

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

PD>>Добавлю коротко и ясно — они есть в Visual C++ (__declspec(property)) , но никем не используются по той же самой причине.

A>Говорите за себя. Я использую.

Уточняю — практически никем не используются

> PD>Добавлю коротко и ясно — они есть в Visual C++ (__declspec(property)) , но
> никем не используются по той же самой причине.
>
> Говорите за себя. Я использую.

Значит, ты и есть тот самый Никто!
Люди, мы его нашли! Это он!

Здравствуйте, Pavel Dvorkin, Вы писали:

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

K>>почему ни в одном стандарте с++ до сих пор не предложили нормальные пропертя?

PD>Конечно, надо их ввести! А то как-то стыдно. Откроешь какой-нибудь файл на java или C# и пожалуйста — десяток полей, десяток геттеров, десяток сеттеров, сотня строк, выглядит солидно и убедительно. А на С++ позор один — несчастный struct на 10 строк и все. А уж если class, то в нем почти что и нет замечательных методов с телом return x; или this.x = x. Стыд и позор!

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

class IService
{
public:
   IMemeber Member;
};

class CService : public IService
{
   CMember MemberImpl;

   void InitMember()
   {
       Member = MemberImpl = new CMember(); // такое как? очень красиво когда у вас два мембера за одну и туже сущность отвечает?
   }
   // или мне нада писать этот приватный сеттер для своего же собственного мембера?
private:
   void SetMemeber(CMemeber * m)
   {
       Member = MemberImpl = m;     
   }
};

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

>> PD>Добавлю коротко и ясно — они есть в Visual C++ (__declspec(property)) , но
>> никем не используются по той же самой причине.
>>
>> Говорите за себя. Я использую.

MZ>Значит, ты и есть тот самый Никто!
MZ>Люди, мы его нашли! Это он!

Мне бы такое зрение. Увидеть Никого, на таком расстоянии, через километры IP-пакетов и десятки файрволлов...

Здравствуйте, Pavel Dvorkin, Вы писали:

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

K>>почему ни в одном стандарте с++ до сих пор не предложили нормальные пропертя?

PD>Конечно, надо их ввести! А то как-то стыдно. Откроешь какой-нибудь файл на java или C# и пожалуйста — десяток полей, десяток геттеров, десяток сеттеров, сотня строк, выглядит солидно и убедительно. А на С++ позор один — несчастный struct на 10 строк и все. А уж если class, то в нем почти что и нет замечательных методов с телом return x; или this.x = x. Стыд и позор!

В C++ тоже длинные сопли с :: и < > очень радуют академический глаз.

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

class A {
  List list; // потом могу переделать по другому и в других местах ничего не меняем.
  public void Add(object a) { list.Add(); }
  property int Count { get { return list.Count; } }
}

— Что бы не писать функции getX setX

struct SomeInterface {
  virtual int getX()=0;
  virtual int setX(int x)=0
};

— Для рефакторинга и отладки
было

class A {
  public int X;
};

стало

class A {
  int x;
  public int X { get { return x; }
    set {
      if (value==100) 
         Debug.BreakPoint();
      x=value;
    }
 }
}

— Можно использовать для валидации и оповещении об измении поля.

class A {
  int x;
  Validator validator;
  Notifier notifier;
  public int X { get { return x; }
    set {
      validator.validate(x);
      if (x!=value) {
        x=value;
        notifier.notify_subscribers();
      }
    }
 }
}

при этом из вне синтаксис как к обычному полю a.X=a.X+1;
и внутренние изменения переход от поля к гетерам и сетерам не приводит к изменению остального кода.

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

V>Такие языки уже есть. Называются Java, .NET. Превращать С++ в Джаву никакого смысла нет, да и стремно — можно нарваться на патентный иск со стороны Оракла.

Почему? Что-то могло бы быть и в С++.

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

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

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

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

W>Они не используются, потому что при переходе на другую платформу придётся всё переписывать

По идее проперти обычно продвигаются, как инструмент разработчика GUI.
А виндовый GUI на другой OS, всё равно переписывать...

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

K>как просто у вас, а если вам интерфес нужен а не класс?

class IService
{
public:
   virtual IMemeber* GetMember() = 0;
};

class CService : public IService
{
   CMember MemberImpl;
   virtual IMemeber* GetMember() { return &MemberImpl; }
};

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