Здравствуйте, Vamp, Вы писали:
K>>и вообще что это за подход "не для тебя"? я не отношусь к технологиям с симпатиями или антипатиями, это к женщинам такие категории применимы, а с технологиями не может быть никаких интимных чувств. V>Ну и зря. Если не любить технологию, которой пользуешься, то никогда не добьешься в ней успеха. Будешь не программист, а кодер. Надо любить то, чем занмаешься, и находить в этом кайф, иначе зачем вообще все это?
K>>есть целесообразность и эффективность — и всё, больше ничего не имеет значения и поэтому, для меня внедрить в с++ вещи из шарпа и жабы следует не потому, что это будет няшно, а потому что это целесообразно и всё. V>А еще ты неправильно понимаешь целесообразность, что, кстати, проистекает от отсутствия любви к технологии. Любовь вообще краеугольный камень, все, что делаешь, надо делать с любовью, иначе будет получаться хреново.
любовь...а еще говоришь, что никакой религиозности,
но спасибо, теперь хоть ясно на чем твой консерватизм стоит, на любви к с++, а я тут про эффективность, прогрессивность распинаюсь...
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Serjio, Вы писали:
S>сообщение выше, для меня прозвучало похожим следующему
было бы замечательно добавить в C++:
S>— нумерацию statement-ов
S>— убрать контроль типов (а то только жить мешает)
S>— ну и возможность интерпретации на виртуальной машине
в результате, хочется спросить "Зачем?" S>ведь все это уже есть, пользуйся — пожайлуста, в другом языке
потому что мне нужно скорость всего
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
а вот, отправив увидел, ответ на вопрос: "нужен неуправляемый язык"
тогда sorry
возможно в этом кроется ответ, и на вопрос о свойствах в C++
не тот ответ, что было бы приятно получить, но он имеет на это право.
(да и сказано весьма тактично)
Только на РСДН помимо ответа на вопрос, можно получить еще список орфографических ошибок и узнать что-то новое из грамматики английского языка (c) http://www.rsdn.ru/forum/cpp/4720035.1.aspx
Здравствуйте, jazzer, Вы писали:
J>Полиморфные лябмды а ля Boost.Lambda элементарно реализуются аналогичным образом, только оператор у функтора должен быть шаблонным, что сейчас запрещено для локальных классов. Если это разрешить — получим нормальные полиморфные лябмды, т.е. такая запись
Где-то читал, что такие лямбды плохо совместимы с концептами, поэтому их не стали делать. А потом и концепты отвалились
Здравствуйте, о_О, Вы писали:
о_О>вот она главная проблема: старые маразматики из комитета назвали направление развития "путем расширения стандартной библиотеки" (отсюда убогие std::function,
гм. Чем убог function? Для делегатов есть signal2, вполне себе неплох.
Здравствуйте, B0FEE664, Вы писали:
BFE>На мой вкус этот код выглядит подозрительно. Зачем lock при публичном методе g()? Почему допускается такая операция: BFE>
BFE>? А если это легально, то зачем тогда нужен lock?
да.
Но основная модели оповещает своих подписчиков об изменении полей.
если написать
a.g()=10;
a.g()=b.g();
то дважды будут оповещены подписчики.
а если сделать
lock то только по выходу из лока. причем локи могу быть вложенными
это что бы можно было менять группу полей без лишних оповещений.
...черт. не туда нажал. ...
_>Здравствуйте, B0FEE664, Вы писали:
BFE>>На мой вкус этот код выглядит подозрительно. Зачем lock при публичном методе 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;
}
Здравствуйте, о_О, Вы писали:
о_О>Здравствуйте, enji, Вы писали:
E>>гм. Чем убог function? о_О>тем что стандартная библиотека. хотелось native...
стандартная библиотека — это считай что native: компилятор может какие угодно хаки применять в реализации стандартной библиотеки.
В любом случае, даже если бы оно было встроено непосредственно в язык, что бы изменилось интерфейсно?
Это по сути указатель на функцию — так что, изобрести еще один указателеподобный значок, типа void (№)(int) ?
Так имхо, std::function< void(int) > читабельнее.
Здравствуйте, jazzer, Вы писали:
J>стандартная библиотека — это считай что native: компилятор может какие угодно хаки применять в реализации стандартной библиотеки.
будем реалистами, он не станет этого делать
J>В любом случае, даже если бы оно было встроено непосредственно в язык, что бы изменилось интерфейсно?
Например, вот придумал только сейчас:
delegate<signature> - оператор объявления типа делегата с сигнатурой signaturedelegate(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
}
Здравствуйте, о_О, Вы писали:
о_О>Здравствуйте, jazzer, Вы писали:
J>>стандартная библиотека — это считай что native: компилятор может какие угодно хаки применять в реализации стандартной библиотеки. о_О>будем реалистами, он не станет этого делать
это делается сплошь и рядом посредством intrinsic-ов.
почти вся std::type_traits — это просто обертка вокруг соответствующих intrinsic-ов, ее иначе полноценно не реализовать просто.
J>>В любом случае, даже если бы оно было встроено непосредственно в язык, что бы изменилось интерфейсно?
о_О>Например, вот придумал только сейчас:
смешались в кучу кони, люди, функции, слоты, сигналы, подписки, отписки...
Подписка/отписка/нотификация/трекинг — это существенно более сложные механизмы, чем просто универсальный указатель на функцию.
в бусте есть сигналы и сигналы2 — думаешь, почему? сигналы2 корректно поддерживают многопоточность, с соответствующими блокировками и прочими радостями. Я бы лично предпочел, чтоб это были разные механизмы, с разность степенью "тяжелости" реализации, потому что мне, например, далеко не всегда нужна многопоточность с соответствующими ей необходимыми приседаниями. (То же касается строк, кстати — нафига мне куча блокировок внутри, если я не собираюсь кидать строки между потоками?)
//капитанство поскипано
Что тебе конкретно не нравится? Что может быть несколько подписчиков? Так смысла в другой реализации нет. Якобы тяжесть этого механизма? Всё это цветочки, по сравнению с бустом, в котором потокобезопасные сигналы быстрее обычных (академики постарались).
Здравствуйте, jazzer, Вы писали:
J>эти рекламируемые сайд-эффекты я видел полраза в жизни на тысячи раз, когда я видел пустые сеттеры-геттеры безо всяких сайд-эффектов.
GUI
Здравствуйте, Kingofastellarwar, Вы писали:
K>да я в общем и не говорил что мне именно с++ нужен, мне нужен неуправляемый компилируемый в нативный код язык с современным синтаксисом, либами, метаданными и прочим
K>такого нет,
K>а мне нужен, потому что меня напрягает старческий маразм с++ и тормоза всего и вся в управляемых языках
В некоторых особенностях язык D выглядит более современным, чем C++
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, jazzer, Вы писали:
J>>эти рекламируемые сайд-эффекты я видел полраза в жизни на тысячи раз, когда я видел пустые сеттеры-геттеры безо всяких сайд-эффектов. M>GUI
Это плохой метод работы с GUI
Здравствуйте, о_О, Вы писали:
о_О>Здравствуйте, jazzer, Вы писали:
о_О>//капитанство поскипано о_О>Что тебе конкретно не нравится? Что может быть несколько подписчиков? Так смысла в другой реализации нет.
Это с чего это ты взял, что нет?
Мне вот лично сигналы с несколькими динамическими подписчиками подписчиками понадобились за все время ровно один раз, а все остальное время рулил простой как валенок boost::function.
о_О>Якобы тяжесть этого механизма?
Якобы? Поддержка многопоточности и подписки/отписки у нас теперь бесплатна?
о_О>Всё это цветочки, по сравнению с бустом, в котором потокобезопасные сигналы быстрее обычных (академики постарались).
Быстрее простого boost::function? (это я так напоминаю, что ты все хочешь в function засунуть.)
А то, что они быстрее первых сигналов — так там соображения обратной совместимости не позволили это дело улучшить, а иначе все сделали бы в рамках первых сигналов. Что никак не отменяет простого факта, что девайс с блокировками на борту в приципе не может быть быстрее такого же без каких-либо блокировок.
Здравствуйте, о_О, Вы писали:
о_О>Например, вот придумал только сейчас: о_О>
о_О>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 и будет тебе счастье, даже синтаксис почти такой же, как у тебя в примере кода.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, Mystic, Вы писали:
M>>Здравствуйте, jazzer, Вы писали:
J>>>эти рекламируемые сайд-эффекты я видел полраза в жизни на тысячи раз, когда я видел пустые сеттеры-геттеры безо всяких сайд-эффектов. M>>GUI J>Это плохой метод работы с GUI