Re[22]: Пропертя
От: Kingofastellarwar Украина  
Дата: 07.05.12 14:50
Оценка: -1
Здравствуйте, Vamp, Вы писали:

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

V>Ну и зря. Если не любить технологию, которой пользуешься, то никогда не добьешься в ней успеха. Будешь не программист, а кодер. Надо любить то, чем занмаешься, и находить в этом кайф, иначе зачем вообще все это?

K>>есть целесообразность и эффективность — и всё, больше ничего не имеет значения и поэтому, для меня внедрить в с++ вещи из шарпа и жабы следует не потому, что это будет няшно, а потому что это целесообразно и всё.

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

любовь...а еще говоришь, что никакой религиозности,
но спасибо, теперь хоть ясно на чем твой консерватизм стоит, на любви к с++, а я тут про эффективность, прогрессивность распинаюсь...
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Re[20]: Пропертя
От: Kingofastellarwar Украина  
Дата: 07.05.12 14:57
Оценка:
Здравствуйте, Serjio, Вы писали:

S>сообщение выше, для меня прозвучало похожим следующему

было бы замечательно добавить в C++:
S>— нумерацию statement-ов
S>— убрать контроль типов (а то только жить мешает)
S>— ну и возможность интерпретации на виртуальной машине

в результате, хочется спросить "Зачем?"

S>ведь все это уже есть, пользуйся — пожайлуста, в другом языке

потому что мне нужно скорость всего
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Re[20]: Пропертя
От: Serjio Россия  
Дата: 07.05.12 15:43
Оценка:
а вот, отправив увидел, ответ на вопрос: "нужен неуправляемый язык"
тогда sorry



возможно в этом кроется ответ, и на вопрос о свойствах в C++

не тот ответ, что было бы приятно получить, но он имеет на это право.
(да и сказано весьма тактично)
Только на РСДН помимо ответа на вопрос, можно получить еще список орфографических ошибок и узнать что-то новое из грамматики английского языка (c) http://www.rsdn.ru/forum/cpp/4720035.1.aspx
Автор: ZOI4
Дата: 28.04.12
Re[9]: КЫВТ GUI—надо быть проще
От: enji  
Дата: 08.05.12 13:25
Оценка:
Здравствуйте, jazzer, Вы писали:

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


Где-то читал, что такие лямбды плохо совместимы с концептами, поэтому их не стали делать. А потом и концепты отвалились
Re[10]: КЫВТ GUI—надо быть проще
От: enji  
Дата: 08.05.12 13:27
Оценка:
Здравствуйте, о_О, Вы писали:

о_О>вот она главная проблема: старые маразматики из комитета назвали направление развития "путем расширения стандартной библиотеки" (отсюда убогие std::function,

гм. Чем убог function? Для делегатов есть signal2, вполне себе неплох.
Re[3]: Пропертя
От: kov_serg Россия  
Дата: 08.05.12 20:12
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>На мой вкус этот код выглядит подозрительно. Зачем lock при публичном методе g()? Почему допускается такая операция:

BFE>
BFE>ModelExample2 a;
BFE>ModelExample2 b;
BFE>a.g() = b.g();
BFE>

BFE>? А если это легально, то зачем тогда нужен lock?
да.

Но основная модели оповещает своих подписчиков об изменении полей.
если написать
a.g()=10;
a.g()=b.g();
то дважды будут оповещены подписчики.
а если сделать
lock то только по выходу из лока. причем локи могу быть вложенными
это что бы можно было менять группу полей без лишних оповещений.
Re[4]: Пропертя
От: kov_serg Россия  
Дата: 08.05.12 20:19
Оценка:
Здравствуйте, kov_serg, Вы писали:

...черт. не туда нажал. ...

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


BFE>>На мой вкус этот код выглядит подозрительно. Зачем lock при публичном методе g()? Почему допускается такая операция:

BFE>>
BFE>>ModelExample2 a;
BFE>>ModelExample2 b;
BFE>>a.g() = b.g();
BFE>>

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

Основная задача модели оповещать своих подписчиков об изменении полей.
если написать
a.g()=10;
a.g()=b.g();

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

схема простая как валенок.
вот остаток кода если вдруг интересно поэкспериментировать.
Notifier.cpp
#include "Notifier.h"

#define ERR_MODIFY_READONLY    "modify in readonly mode"
#define ERR_LOCK_READONLY      "unable to lock in readonly mode"
#define ERR_ALREADY_SUBSCRIBED "listener already subscibed"
#define ERR_NOT_SUBSCRIBED     "listener not registered"
#define ERR_HAS_CHILD          "this node already attached"
#define ERR_NO_CHILD           "no such child node found"
#define ERR_BAD_LOCK_LEVEL     "lock_level must be 0"
#define ERR_BAD_LOCK_LEVEL_RO  "lock_level<0 must be 0"
void throw_exception(const char* reason) {
    throw reason;
}

Notifier::Notifier() {
    lock_level=0;
    modified=false;
}
Notifier::~Notifier() {
    if (lock_level!=0) {
        // fatal error!
        lock_level=lock_level;
    }
}
void Notifier::Modified() {
    modified=true; 
    if (lock_level>0) return;
    if (lock_level<0) throw_exception(ERR_MODIFY_READONLY);
    NotifyAll(); 
}
void Notifier::NotifyChange() {
    Modified();
}
void Notifier::Lock() {
    if (lock_level<0) throw_exception(ERR_LOCK_READONLY);
    if (++lock_level==1) LockChildren();
}
void Notifier::Unlock() {
    if (--lock_level==0) {        
        lock_level++;
        UnlockChildren();
        lock_level--;
        if (modified) NotifyAll();
    }
}
void Notifier::AttachChild(Notifier& child) {
    if (children.find(&child)!=children.end()) throw_exception(ERR_HAS_CHILD);
    children.insert(&child);
    if (lock_level>0) child.Lock();
    child.Subscribe(*this,!modified && child.IsModified());
}
void Notifier::DetachChild(Notifier& child) {
    children_it it=children.find(&child);
    if (it==children.end()) throw_exception(ERR_NO_CHILD);
    children.erase(it);
    child.Unsubscribe(*this);
    if (lock_level>0) child.Unlock();
}
void Notifier::Subscribe(NotifyListener &listener,bool notify_attach) {
    if (listeners.find(&listener)!=listeners.end()) throw_exception(ERR_ALREADY_SUBSCRIBED);
    listeners.insert(&listener);
    if (notify_attach) listener.NotifyChange();
}
void Notifier::Unsubscribe(NotifyListener &listener) {
    listeners_it it=listeners.find(&listener);
    if (it==listeners.end()) throw_exception(ERR_NOT_SUBSCRIBED);
    listeners.erase(it);
}
void Notifier::LockChildren() {
    for(children_it it=children.begin();it!=children.end();++it) {
        (*it)->Lock();
    }
}
void Notifier::UnlockChildren() {
    for(children_it it=children.begin();it!=children.end();++it) {
        (*it)->Unlock();
    }
}
void Notifier::NotifyAll() {
    if (lock_level!=0) {
        if (lock_level<0) throw_exception(ERR_BAD_LOCK_LEVEL_RO);
        else throw_exception(ERR_BAD_LOCK_LEVEL);
    }
    lock_level=-1; // enter read only mode
    for(listeners_it it=listeners.begin();it!=listeners.end();++it) {
        (*it)->NotifyChange();
    }
    modified=false;
    lock_level=0; // leave readonly mode
}
int  Notifier::GetDeepLevel() const {
    int deep=0;
    for(children_cit it=children.begin();it!=children.end();++it) {
        int d=(*it)->GetDeepLevel();
        if (deep<d) deep=d;
    }
    return deep+1;
}
bool Notifier::IsDeepUnlocked() const {
    for(children_cit it=children.begin();it!=children.end();++it) {
        if (!(*it)->IsDeepUnlocked()) return false;
    }
    return true;
}
Re: Пропертя
От: Piko  
Дата: 08.05.12 22:30
Оценка: 1 (1)
http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Keynote-Bjarne-Stroustrup-Cpp11-Style

1:13:00
Вопрос про property.
+ в комментариях к видео эта тема затрагивается (почти в самом низу)
Re[11]: КЫВТ GUI—надо быть проще
От: о_О
Дата: 09.05.12 08:28
Оценка:
Здравствуйте, enji, Вы писали:

E>гм. Чем убог function?

тем что стандартная библиотека. хотелось native...
Re[12]: КЫВТ GUI—надо быть проще
От: jazzer Россия Skype: enerjazzer
Дата: 09.05.12 21:40
Оценка:
Здравствуйте, о_О, Вы писали:

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


E>>гм. Чем убог function?

о_О>тем что стандартная библиотека. хотелось native...

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

В любом случае, даже если бы оно было встроено непосредственно в язык, что бы изменилось интерфейсно?
Это по сути указатель на функцию — так что, изобрести еще один указателеподобный значок, типа void (№)(int) ?
Так имхо, std::function< void(int) > читабельнее.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[13]: КЫВТ GUI—надо быть проще
От: о_О
Дата: 10.05.12 06:40
Оценка:
Здравствуйте, jazzer, Вы писали:

J>стандартная библиотека — это считай что native: компилятор может какие угодно хаки применять в реализации стандартной библиотеки.

будем реалистами, он не станет этого делать

J>В любом случае, даже если бы оно было встроено непосредственно в язык, что бы изменилось интерфейсно?


Например, вот придумал только сейчас:
delegate<signature> - оператор объявления типа делегата с сигнатурой signature

delegate(function, оbject, (arg1, arg2, ... argN | _1, _2, ... _N) ) - оператор создания функционального объекта для делегата с сигнатурой function,
из функции function и (если function - член-функция) указателя на объект оbject
//короче std::bind-like синтаксис, пусть только дедукцией занимается компилятор, а не костыли вида std::bind


Живой пример:
enum class EventType
{
  Test  = 0x0001,
};

struct Object
{
  void OnEvent(EventType event)
  {
    //1st subscriber callback
  }
};

void OnEvent(EventType event)
{
  //2nd subscriber callback
}

int main()
{
  Object object;
  delegate<void(EventType event)> d = delegate(&Object::OnEvent, &object); //делегат d инициализируется первым подписчиком
  d += delegate(OnEvent); //добавляется второй подписчик
  d += [](EventType event) { /*3rd subscriber callback*/ }; //добавляется третий подписчик

  d -= delegate(OnEvent); //второй, пожалуй, лишний
  d(EventType::Test); //вызов подписчиков 1 и 3: метода Object::OnEvent объекта object и анонимной функции
  //???
  //ENJOY!!1
}
Re[14]: КЫВТ GUI—надо быть проще
От: jazzer Россия Skype: enerjazzer
Дата: 11.05.12 01:50
Оценка:
Здравствуйте, о_О, Вы писали:

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


J>>стандартная библиотека — это считай что native: компилятор может какие угодно хаки применять в реализации стандартной библиотеки.

о_О>будем реалистами, он не станет этого делать
это делается сплошь и рядом посредством intrinsic-ов.
почти вся std::type_traits — это просто обертка вокруг соответствующих intrinsic-ов, ее иначе полноценно не реализовать просто.

J>>В любом случае, даже если бы оно было встроено непосредственно в язык, что бы изменилось интерфейсно?


о_О>Например, вот придумал только сейчас:

смешались в кучу кони, люди, функции, слоты, сигналы, подписки, отписки...
Подписка/отписка/нотификация/трекинг — это существенно более сложные механизмы, чем просто универсальный указатель на функцию.
в бусте есть сигналы и сигналы2 — думаешь, почему? сигналы2 корректно поддерживают многопоточность, с соответствующими блокировками и прочими радостями. Я бы лично предпочел, чтоб это были разные механизмы, с разность степенью "тяжелости" реализации, потому что мне, например, далеко не всегда нужна многопоточность с соответствующими ей необходимыми приседаниями. (То же касается строк, кстати — нафига мне куча блокировок внутри, если я не собираюсь кидать строки между потоками?)
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[15]: КЫВТ GUI—надо быть проще
От: о_О
Дата: 11.05.12 05:06
Оценка:
Здравствуйте, jazzer, Вы писали:

//капитанство поскипано
Что тебе конкретно не нравится? Что может быть несколько подписчиков? Так смысла в другой реализации нет. Якобы тяжесть этого механизма? Всё это цветочки, по сравнению с бустом, в котором потокобезопасные сигналы быстрее обычных (академики постарались).
Re[6]: Пропертя
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 11.05.12 05:23
Оценка: :)
Здравствуйте, filkov, Вы писали:

F>Это случилось чуть раньше — в OLE/COM.

F>Там надо было.
F>А на них уже соорудили Дельфу.

Свойства были еще в Delphi первой версии (16-битная Windows), когда никакой другой языковой поддержки OLE/COM не было.
Re[4]: Пропертя
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 11.05.12 05:26
Оценка:
Здравствуйте, jazzer, Вы писали:

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

GUI
Re[23]: _eter_
От: _Eter_ http://mnazarov.ru
Дата: 11.05.12 06:14
Оценка:
Здравствуйте, Kingofastellarwar, Вы писали:

K>да я в общем и не говорил что мне именно с++ нужен, мне нужен неуправляемый компилируемый в нативный код язык с современным синтаксисом, либами, метаданными и прочим


K>такого нет,


K>а мне нужен, потому что меня напрягает старческий маразм с++ и тормоза всего и вся в управляемых языках


В некоторых особенностях язык D выглядит более современным, чем C++
Re[5]: Пропертя
От: jazzer Россия Skype: enerjazzer
Дата: 11.05.12 06:24
Оценка:
Здравствуйте, Mystic, Вы писали:

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


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

M>GUI
Это плохой метод работы с GUI
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[16]: КЫВТ GUI—надо быть проще
От: jazzer Россия Skype: enerjazzer
Дата: 11.05.12 06:39
Оценка:
Здравствуйте, о_О, Вы писали:

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


о_О>//капитанство поскипано

о_О>Что тебе конкретно не нравится? Что может быть несколько подписчиков? Так смысла в другой реализации нет.
Это с чего это ты взял, что нет?
Мне вот лично сигналы с несколькими динамическими подписчиками подписчиками понадобились за все время ровно один раз, а все остальное время рулил простой как валенок boost::function.

о_О>Якобы тяжесть этого механизма?

Якобы? Поддержка многопоточности и подписки/отписки у нас теперь бесплатна?

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

Быстрее простого boost::function? (это я так напоминаю, что ты все хочешь в function засунуть.)
А то, что они быстрее первых сигналов — так там соображения обратной совместимости не позволили это дело улучшить, а иначе все сделали бы в рамках первых сигналов. Что никак не отменяет простого факта, что девайс с блокировками на борту в приципе не может быть быстрее такого же без каких-либо блокировок.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[14]: КЫВТ GUI—надо быть проще
От: enji  
Дата: 11.05.12 06:53
Оценка:
Здравствуйте, о_О, Вы писали:

о_О>Например, вот придумал только сейчас:

о_О>
о_О>delegate<signature> - оператор объявления типа делегата с сигнатурой signature

о_О>delegate(function, оbject, (arg1, arg2, ... argN | _1, _2, ... _N) ) - оператор создания функционального объекта для делегата с сигнатурой function,
о_О>из функции function и (если function - член-функция) указателя на объект оbject
о_О>//короче std::bind-like синтаксис, пусть только дедукцией занимается компилятор, а не костыли вида std::bind
о_О>


Замени delegate на boost::signal2 + boost::bind и будет тебе счастье, даже синтаксис почти такой же, как у тебя в примере кода.
Re[6]: Пропертя
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 11.05.12 07:08
Оценка:
Здравствуйте, jazzer, Вы писали:

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


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


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

M>>GUI
J>Это плохой метод работы с GUI

А как по мне, в Delphi и BCB он был очень неплох
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.