в политике вот далеко не у всех опыт есть однако отличить мудака-политика от хорошего многие могут. так какой смысл в фаллометрии?

в политике вот далеко не у всех опыт есть однако отличить мудака-политика от хорошего многие могут. так какой смысл в фаллометрии?

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

как ни странно, если ваш опыт превышает мой, я задумаюсь над тем, что вы говорите

не стоит задумываться. все фигня. пиши на джаве. я просто развлекался

всем спокойной ночи

в частности, меня категорически удивляет, что Human со ссылками на Universe для вас необычны

потому что естественный порядок владения в дереве от потомка к предку

как ни странно, если ваш опыт превышает мой, я задумаюсь над тем, что вы говорите

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

Вообще странно, у меня как то наоборот, чем больше узнаю, тем больше понимаю, что учитывать надо любые мнения

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

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

это как "больший рейтинг на олимпиадках что-то значит, меньший - нет"

ну... больший опыт значит только... больший опыт, и все

статистически человек, имеющий больший опыт, сделал больше ошибок :)

как минимум такой аргумент - считаете ли вы, что три года назад понимали хуже?

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

т.е. если вы возьмете себя из будущего, очевидно, его советы нужно слушать

как минимум такой аргумент - считаете ли вы, что три года назад понимали хуже?

да, хуже

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

т.е. если вы возьмете себя из будущего, очевидно, его советы нужно слушать

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

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

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

C++ Concurrency in Action?

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

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

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

я лишь доказываю, что нужно слушать больше людей

а, так с этим я согласен

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

(больше людей в случае большего опыта)

C++ Concurrency in Action?

сеньк

сеньк

ещё в Advanced Programming in UNIX Environment, насколько я помню, неплохо рассказывается за примитивы вроде мьютексов и семафоров

да, кстати, @AsGreyWolf, окна должны быть неперемещаемыми, чтобы без проблем в лямбдах биндаться

ещё в Advanced Programming in UNIX Environment, насколько я помню, неплохо рассказывается за примитивы вроде мьютексов и семафоров

Мне не про параллелизм, а про асинхронность надо, где рассказывалось бы чё это такое, какие проблемы есть, как они в цивилизованном мире решаются и прочее

оу тогда Concurrency in Action тоже несколько мимо леса( хотя возможно я просто не дочитал до продвинутых вещей

оу тогда Concurrency in Action тоже несколько мимо леса( хотя возможно я просто не дочитал до продвинутых вещей

По крайней мере если судить по оглавлению - то да - мимо

Даже гугол молчит, странно что по этой теме так туго с теоретическими материалами

если честно, не понял эту фразу. кто от чего плюется и кто кого и зачем грохнуть должен

если некоторое окно создает команду для контекстного меню, оно очень хочет биндать this в этой команде, чтобы получать назад инфу это С++, детка, тут бывают битые ссылки и вообще все не очень хорошо, поэтому над этой фигней привинчен отладочный reference checker запущенная менюшка имеет состояние, в частности, хранящее все переданные команды так вот, если трек продержит лишнего это состояние, то в этом состоянии будет битая ссылка на окошко

если некоторое окно создает команду для контекстного меню, оно очень хочет биндать this в этой команде, чтобы получать назад инфу это С++, детка, тут бывают битые ссылки и вообще все не очень хорошо, поэтому над этой фигней привинчен отладочный reference checker запущенная менюшка имеет состояние, в частности, хранящее все переданные команды так вот, если трек продержит лишнего это состояние, то в этом состоянии будет битая ссылка на окошко

не сильно понятнее стало) this биндит, полагаю, команда, а не менюшка. По остальному... попробую догадаться: речь о ситуации, когда кто-то убил окно, а контекстное меню осталось?

не сильно понятнее стало) this биндит, полагаю, команда, а не менюшка. По остальному... попробую догадаться: речь о ситуации, когда кто-то убил окно, а контекстное меню осталось?

команда содержит непосредственно вызываемый callback при выборе пользователем нет, там из-за особенностей механики работы передерживал Track в собственной статической переменной

кто такой трек?

TrackPopupMenu это условное название функции, которая непосредственно показывает popup menu

собственно её винапи-название

и кто передерживал в своей статической переменной трек?

причем передерживал функцию, как я понял

TrackPopupMenu передерживала std::shared_ptr<PopupMenuState> в своей статической переменной

по-моему, наличие только статичекой переменной в самой функции уже говорит о том, что пора перерабатывать архитектуру

предложите другое решение для вот какого момента

(а) TrackPopupMenu не имеет права выпускаться из стека до конца

она синхронная

я вот так с наскоку в эту ситуацию не смогу погрузиться, тем более посреди ночи

(б) повторный вызов TrackPopupMenu может означать переход на другой пункт в MenuBar

т.е. TrackPopupMenu должна знать, что в стеке уже лежит TrackPopupMenu и знать состояние этого меню

навскидку, если у функции есть состояние, значит она напрашивается на переименовывание в метод

т.е., возможно, нужен класс типа PopupMenuTracker

как вы вообще умеете определять, что некоторая функция находится в стеке?

этим будет заниматься объект. Если нужно, с помощью поля-стека

?

я не понял про поле-стек

vector<...>

отлично, но как я получил ссылку на этот объект?

тот, который был первым в вызове?

stack[0]?

т.е. TrackPopupMenu должна знать, что в стеке уже лежит TrackPopupMenu и знать состояние этого меню

а чё если оформить это в класс и запретить создание нескольких инстансов?

типо синглтон

(блин не бейте за синглтон)

я не самый большой специалист

но у меня синглтоны реализуются через статическую переменную функции

ну я чаще видел реализацию через статическое поле класса-синглтона и статическую функцию (и приватные конструкторы)

stack[0]?

у кого? глобальной переменной?

ERROR: S client not available

у кого? глобальной переменной?

нет, у поля

меня интересует, как я нашел тот объект, у которого прочитал stack[0]

мне тот же трекер не дадут

так что я должен на том же вызваться

меня интересует, как я нашел тот объект, у которого прочитал stack[0]

Я рассуждаю типа такого class PopupMenuTracker { protected: vector<...> stack; public: auto TrackPopupMenu(...); // тут используем stack };

отлично

это как минимум отвязывает от глобального контекста приложения

а это развязывание возможно?

если мы лопатим архитектуру - почему нет?

два TrackPopupMenu невозможны в рамках одного приложения

потому что TrackPopupMenu имеет уникальный системный ресурс

погоди, тут TrackPopupMenu это метод

что значит два их невозможны

два вызова

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

ну вы очень странно недолюбливаете статические переменные

SomeSingleton & get_SomeSingletonInstance { static SomeSingleton object; return object; //я ой как не уверен, что вы можете это повторить }

в частности, код выше потокобезопасен, вы умеете в оптимальный потокобезопасный код?)

я не недолюбливаю, они хороши для своих целей. Но для синглтона статической переменной функции мало

а что там еще не хватает?

можно в любом месте программы написать SomeSingleton

инстанцировать класс т.е.

хм...

да, нужно писать приват конструктор и friend на функцию геттер

namespace { class SomeSingleton : public SomeSingletonInterface { }; } SomeSingletonInterface & get_SomeSingletonInstance { static SomeSingleton object; return object; //я ой как не уверен, что вы можете это повторить }

но это уже выглядит, как обычная статическая функция класса

кстати, статические переменные функции thread-local?

нет

thread_local отдельное ключевое слово

тогда где там потокобезопасность?

гарантия языка