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

EP>>·>Под умными указателями понимается всё что угодно. Unique да, просто языковая конструкция, но он и не потокобезопасный.
dot>Кстати, в java unique практически сам выводится — в тех тривиальных случаях когда ты бы стал использовать unique, java обыно делает escape analysis,

Escape analysis вообще из другой оперы. Это например про аллокации объектов на стэке вместо кучи — в таких случаях никакой unique_ptr не нужен
Более того аллокация на стэке — это default для C++, и работает даже в случаях escape.

dot>да и Young Generation собирается очень быстро.

Во сколько раз "быстро" быстрее "мгновенно"?

EP>>·>Если нужна передача данных между тредами — нужен shared pointer,
EP>>Он нужен только в случаях когда потоки владеют какими-то общими данными и точный момент удаления заранее не определён.
EP>>Если просто нужно передать данные и владение в другой поток, то достаточно и unique, и то не факт — может быть хватит обычного перемещения.
dot>Не владеют, а шарят...

А шарят они что по-твоему? Цитата из стандарта: "shared_ptr implements semantics of shared ownership"

dot>Будешь передавать weak_ptr, а значит опять локи.

Что? Причём тут теперь weak_ptr? Уже какая-то каша пошла.

dot>Для перемещения — YG опять же.

Причём тут YG? Перемещать можно даже старые объекты

dot>Последствия обращения к неверным указателям — серьёзнее. Не простой краш, а хз что.

А например OOM — тоже вполне серьёзно

dot>А ещё аллокация из кучи — глобальный лок. В общем, тормоза повсюду.

Специальные аллокаторы и т.п. — вполне распространённая практика.
Значит в случае Java ты готов использовать и специальную VM, и специальный GC, отказываться от классов, а в случае C++ специальные аллокатор ни в коем случае

dot>Короче, может и можно писать low latency на C++, но сложнее на порядок.

Это фантазии, ничем не обоснованные.

EP>>·>который использует lock (mutex?) -
EP>>Обычно в реализациях атомарные inc/dec.
dot>Это где? Вот тут вроде mutex.

И там же atomics. Mutex это лишь fallback для платформ в которых нет подходящих атомарных операций

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

_>>Какие примеры и для чего? ) Ты сформулируй точно тезис, который пытаешься доказать. Желательно с аргументами. Я на него посмотрю и выскажу своё согласие/несогласие. Тоже с аргументами. А пока я не пойму о чём у нас собственно основной спор и для чего ты выкладываешь какие-то куски кода.
S> Я привожу то, что хочу видеть в тех библиотеках, которые как ты считаешь круче EF

"Круче" — это не инженерный термин. Я такого не использовал. Я говорил о том, что sqlpp11 заметно быстрее (вот это уже инженерный термин) EF при одинаковом синтаксисе. Против этого есть какие-то возражения или нет?

_>>Ну вот тогда советую посмотреть (в рамках хобби) на другие решения, чтобы иметь представление о возможных вариантах. Скажем какой-нибудь SQLAlchemy для начала глянуть.
S>Ты взял на себя утверждение, что EF отстой. Тебе и доказывать. Я привожу тебе решения которые есть в EF.

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

_>>ObservableCollection не генерируется компилятором, а лежит в System.dll. И да, в EF создаются всякие там промежуточные классы для работы с БД (на то оно и ORM), но к биндингу с GUI это отношения не имеет.
S> Кончно, оно есть у DBSEt.Local
S>https://msdn.microsoft.com/ru-ru/library/gg696248(v=vs.113).aspx
S>Пространство имен: System.Data.Entity
S>Сборка: EntityFramework (в EntityFramework.dll)

А ещё классы из EF наверняка умеют исключения кидать. И возможно события какие-то. Означает ли это, что исключения и т.п. реализованы в EF? )

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

_>>Лок перед завершение потока никого не беспокоит, т.к. это по сути просто отложенное освобождение ресурсов — никаких данных уже никто не ожидает.
·>Тут ведь как... Поток можно и не завершать, или приступить к обработке следующего действия.

Тогда значит и данные тем более никуда не денутся. )

_>>Ну ОК, раз ты так считаешь, то тогда приведи пример взаимодействия потоков в котором на твой взгляд невозможно обойтись без shared_ptr.
·>Если тебе нужно чтобы не было обращений по невалидным указателям, то ты не можешь делать предположение, что объект по голому указателю ещё жив — надо использовать smart pointers.

С чего это ты взял, что не могу? ) Да, и ты снова привёл не конкретный пример, а абстрактные рассуждения. Давай конкретную задачку и посмотрим могу или нет... )))

_>>·>Да не надо локи. Есть много других механизмов.
_>>Например? )
·>CAS, volatile, happens-before.

Если применять CAS не по делу (исключительно в специально предназначенных для этого алгоритмах), а везде вместо локов, то результат будет только ещё намного хуже чем с локами, т.к. в таком случае всё равно будет нечто типа лока, только при этом с полной загрузкой процессора.

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



_>"Круче" — это не инженерный термин. Я такого не использовал. Я говорил о том, что sqlpp11 заметно быстрее (вот это уже инженерный термин) EF при одинаковом синтаксисе. Против этого есть какие-то возражения или нет?
Заметно быстрее чего? Я могу через t4 используя Linq сгенерировать запросы и классы для заполнения. По скорости будет то же самое.
Проблема в скорости в том, что нет прокси для получения навигационных свойств, дополнительные данные для биндинга итд.
Есть дополнительные расходы. Но функциональность sqlpp11 не в какое сравнение с EF нет и близко.
Еще раз ты ставишь скорость во главу угла. Еще раз напомню про 1С где скорость интерпритатора не в разы, а в сотни и тысячи раз медленнее. Но мало кого это беспокоит. Главное скорость разработки.

Кстати неизвестно насколько твой sqlpp11 генерирует оптимальный SQL код на сложных запросах. Я приводил результирующие SQL на нетривиальных запросах.
В своё время EF был очень далек от оптимальности. Сейчас уже достаточно близко к идеалу. Как и что генерит sqlpp11 неизвестно.

_>>>Ну вот тогда советую посмотреть (в рамках хобби) на другие решения, чтобы иметь представление о возможных вариантах. Скажем какой-нибудь SQLAlchemy для начала глянуть.
S>>Ты взял на себя утверждение, что EF отстой. Тебе и доказывать. Я привожу тебе решения которые есть в EF.

_>Не надо от моего имени высказывать какие-то странные фразы. Я говорил вполне конкретные вещи (см. выше) и их уже вполне доказал. А SQLAlchemy я посоветовал посмотреть уже не в качестве аргумента в данной дискуссии, а просто для расширения кругозора на тему вариантов реализации мощных ORM. А то знать только подобное EF — это как-то печально.
И это говорит человек незнающий 1С и EF. Я тебе кучу примеров и статей на русском. А ты дал просто название, без всяких ссылок. Поверь мне интересны новые подходы.
SQLAlchemy я так понимаю, что это библиотека для питона. Вопрос в чем отличие от 1С?
Посмотрел https://ru.wikibooks.org/wiki/SQLAlchemy. Не увидел ничего нового.

_>>>ObservableCollection не генерируется компилятором, а лежит в System.dll. И да, в EF создаются всякие там промежуточные классы для работы с БД (на то оно и ORM), но к биндингу с GUI это отношения не имеет.
S>> Кончно, оно есть у DBSEt.Local
S>>https://msdn.microsoft.com/ru-ru/library/gg696248(v=vs.113).aspx
S>>Пространство имен: System.Data.Entity
S>>Сборка: EntityFramework (в EntityFramework.dll)

_>А ещё классы из EF наверняка умеют исключения кидать. И возможно события какие-то. Означает ли это, что исключения и т.п. реализованы в EF? )
Это значит, что оболочка на запросом намного более функциональная, чем в sqlpp11. Я в свое время делал объектную модель над DBF. Данные считывались в структуру над которой строились свойства и тд. Все очень быстро с минимумом затрат. И никому это не было нужно не смотря на охринительную скорость.
Просто люди не понимали и пользовались более понятными инструментами.

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

TB>·>Почему никак? В случае java всегда так.
TB>Да, жаба лучше себя ведёт, когда надо нанять 100500 индусов, это её известно преимущество.
Т.е. неиндусы — никогда не ошибаются? Даже дело не в том, что ошибаются или нет — проверить никак нельзя.

TB>·>Если не создаст — повезло с задачей. В low latency — любой lock создаёт проблемы.
TB>Сборка мусора — это тоже лок.
Не всегда, и не везде.

TB>·>Эээ. Давай, сделай. Интересно как можно похакать верифицируемый байт-код.
TB>http://ideone.com/o1h0hR
TB>const_cast ничем не лучше этого кода.
Во-первых, это не "2+2 == 5", а "Integer.valueOf(4) == 5".
Во-вторых, попробуй такой трюк проверни со включенным security manager, запретить const_cast же — невозможно.
В-третьих, вот так в C++ писать уже можно?

volatile ImmutableClass *var = NULL;
...
//thread 1
var = new ImmutableClass();
//thread 2
if(var != NULL)
  Var.doSomething();

Раньше, афаир, нельзя было.

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

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

I>Смартпоинтеры можно например переписать и отказаться от счетчиков ссылок, заюзать любую из сотен возможностей по управлению ресурсами и тд и тд и тд.
I>На худой конец, "писать как на Си"

I>С с GC у тебя будет всегда GC и никуда от этого не денешься. Любое твое телодвижение должно быть согласовано с GC, иначе будут вылазить задержки.
I>Ошибся "здесь" — задержка вылезет черз секунду "там"
gc прощает гораздо больше ошибок. И самое страшное что может случиться — тормоза. Без него — всё что угодно, и тормоза, и порча памяти, и утечки.
А вообще говоря, все эти смартпоинтеры по сути — примитивные алгоритмы gc.

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

dot>>Это не частный случай, а наиболее простая имплементация. Конечно, можно внимательно изучить, установить время жизни каждого объектика, но это сложно контролировать и тестировать, а в случае ошибки — undefined behaviour. В случае же java — самое страшное что будет — это latency spike из-за garbage collection, а не порча данных, как в случае ошибок с указателями.

EP>При использовании Java в таких случаях отказываются и от GC и от классов, и нарезают вручную массивы байт на структуры. Получить порчу данных в таком случае на порядки проще чем на высокоуровневом C++.
EP>Вот конкретный пример (первые минут двадцать)
EP>http://www.youtube.com/watch?v=Q-7y1u9kZV0
Ролик не смотрел, дома посмотрю... Но могу заметить, что эти все нарезки обычно делаются в довольно ограниченной области кода. И все эти порчи данных довольно изолированы (или как минимум изолируемы). Невалидные же указатели могут испортить всё что угодно во всём процессе.

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

_>>"Круче" — это не инженерный термин. Я такого не использовал. Я говорил о том, что sqlpp11 заметно быстрее (вот это уже инженерный термин) EF при одинаковом синтаксисе. Против этого есть какие-то возражения или нет?
S> Заметно быстрее чего?

Вроде бы вполне ясно написано. sqlpp11 заметно быстрее EF (да и вообще любого ORM на базе linq).

S>Я могу через t4 используя Linq сгенерировать запросы и классы для заполнения. По скорости будет то же самое.

Безусловно. А можно даже и без t4 просто голые sql строки вставить и опять же будет отличная скорость. Нюанс в том, что в обоих этих случаях синтаксис станет не как у linq. А вот sqlpp11 сохраняет такой синтаксис без потерь в скорости.

S>Есть дополнительные расходы. Но функциональность sqlpp11 не в какое сравнение с EF нет и близко.

Вроде бы весь набор операций, нужный для работы с sql имеется. Причём в полном соответствие с linq синтаксисом (одним из двух вариантов). А что ещё надо для ORM? )

S> Еще раз ты ставишь скорость во главу угла. Еще раз напомню про 1С где скорость интерпритатора не в разы, а в сотни и тысячи раз медленнее. Но мало кого это беспокоит. Главное скорость разработки.

Что значит я ставлю скорость во главу угла? ) Я пока что всего лишь сделал утверждение о быстродействие двух разных ORM. И я так понимаю по этому поводу нет никаких возражений? ))) Если же начинать говорить о выборе какого-то из них для какой-то конкретной задачи, то это уже глупо будет, т.к. данные ORM реализованы на разных платформах, выбор между которыми для какой-то задачи явно будет определяться не возможностями ORM, а более серьёзными вещами. А соответственно выбрав платформу мы автоматически получим выбор ORM (ну если говорить о выборе между двумя обсуждаемыми вариантами, так то под каждую платформу есть много вариантов).

_>>Не надо от моего имени высказывать какие-то странные фразы. Я говорил вполне конкретные вещи (см. выше) и их уже вполне доказал. А SQLAlchemy я посоветовал посмотреть уже не в качестве аргумента в данной дискуссии, а просто для расширения кругозора на тему вариантов реализации мощных ORM. А то знать только подобное EF — это как-то печально.
S> И это говорит человек незнающий 1С и EF. Я тебе кучу примеров и статей на русском. А ты дал просто название, без всяких ссылок. Поверь мне интересны новые подходы.
S> SQLAlchemy я так понимаю, что это библиотека для питона. Вопрос в чем отличие от 1С?
S>Посмотрел https://ru.wikibooks.org/wiki/SQLAlchemy. Не увидел ничего нового.

Лучше смотреть не в википедии, а на сайте производителя http://www.sqlalchemy.org и там на самом деле весьма много отличий. )))

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

dot>>Да, но gc не обязан это делать всё и сразу, вместо паузы в 100ms он сделает 1500 пауз по 100us. Да, throughput может и меньше, зато latency предсказуемее.
EP>Если ограничивать GC пороговой latency — то можно получить OOM — банально скорость очистки будет меньше необходимой.
EP>При этом учти что полноценный цикл GC линеен от количества N живых объектов — может быть например большое N, при малом потоке изменений reachable/unreachable.
ООМ везде можно получить. Тем более мы говорим о латенси, т.е. затупить большие latency spikes, а не высокий throughput когда шпарит высокая нагрузка постоянно.

dot>>Можно, конечно, такое же соорудить и в C++, но это будет закат солнца вручную.
EP>Почему вручную-то? Если есть такой развесистый граф владения — то и очищай его по частям, автоматически.
По каким частям? Как эти части определить? В каком порядке очищать? Когда ответишь на эти вопросы и многие другие, то переизобретёшь современный gc.

EP>Да и возникают они в Java на порядки чаще чем в C++. Элементарный пример: массив объектов, агрегирующих другие объекты, агрегирующих другие ... — вполне типичная ситуация. На Java будет тот самый развесистый граф, а на C++ может быть просто по сути один вектор освобождающийся за O(1) — так как value semantics.
Сам же написал "GC линеен от количества N живых объектов", т.е. сдохший шмат графа можно освобождать также за примерно O(1).

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

dot>Во-вторых, попробуй такой трюк проверни со включенным security manager, запретить const_cast же — невозможно.

Возможно. Даже если опасаешься false positives/negatives grep'а — то легко написать простейший верификатор на базе Clang AST Matchers.

dot>В-третьих, вот так в C++ писать уже можно?
dot>

dot>volatile ImmutableClass *var = NULL;
dot>...
dot>//thread 1
dot>var = new ImmutableClass();
dot>//thread 2
dot>if(var != NULL)
dot>  Var.doSomething();
dot>

dot>Раньше, афаир, нельзя было.

В Java у volatile семантика другая нежели чем у C++. Для этой же цели используются std/boost::atomic. То есть будет не volatile ImmutableClass *, а atomic<ImmutableClass *>.

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

dot>>>Это не частный случай, а наиболее простая имплементация. Конечно, можно внимательно изучить, установить время жизни каждого объектика, но это сложно контролировать и тестировать, а в случае ошибки — undefined behaviour. В случае же java — самое страшное что будет — это latency spike из-за garbage collection, а не порча данных, как в случае ошибок с указателями.
EP>>При использовании Java в таких случаях отказываются и от GC и от классов, и нарезают вручную массивы байт на структуры. Получить порчу данных в таком случае на порядки проще чем на высокоуровневом C++.
EP>>Вот конкретный пример (первые минут двадцать)
EP>>http://www.youtube.com/watch?v=Q-7y1u9kZV0
dot>Ролик не смотрел, дома посмотрю... Но могу заметить, что эти все нарезки обычно делаются в довольно ограниченной области кода. И все эти порчи данных довольно изолированы (или как минимум изолируемы).

Да, но мы-то обсуждаем именно такой случай, именно эту самую область кода. И эта ручная error-prone нарезка на структуры, отказ от GC и т.п. — по сути выливается в уровень ниже чем C, и в результате приводит к вполне ожидаемым ошибкам: http://rsdn.ru/forum/philosophy/6201205.1

Автор: Evgeny.Panasyuk
Дата: 02.10.15

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

_>>>·>Если надо "100% безопасна", то никуда не денешься.
_>>>Ну ОК, раз ты так считаешь, то тогда приведи пример взаимодействия потоков в котором на твой взгляд невозможно обойтись без shared_ptr.
dot>>Если тебе нужно чтобы не было обращений по невалидным указателям, то ты не можешь делать предположение, что объект по голому указателю ещё жив — надо использовать smart pointers.
EP>Этот use-case формулируется немного по-другому, например: нужно чтобы ресурс освобождался как только завершится последний поток его использующий, и какой из них будет последним — заранее не известно.
EP>Вот так — да, как вариант решения подсчёт ссылок, и то в малом количестве мест. Только решать эту проблему нужно и в C, и сюрприз в Java.
Не завершится, а освободит последнюю ссылку на ресурс. Мало того, тот кому не повезло освобождать ссылку последним — не придётся тратить ВНЕЗАПНО время на освобождение, вызывая непредсказуемые проблемы с latency.

EP>На Java кстати какое решение можешь предложить?
На java память ресурс другого типа. "Освобождать память" там нельзя. А для ресурсов в общем случае — наследники java.lang.ref.Reference.

_>>>·>Да не надо локи. Есть много других механизмов.
_>>>Например? )
dot>>CAS, volatile, happens-before.
EP>На них точно также получаются локи. Чтобы их не было, нужно использовать например lock-free / wait-free схемы.
Ну да... Только, как мне кажется. эти схемы гораздо проще если есть gc.

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

I>>Ошибся "здесь" — задержка вылезет черз секунду "там"
·>gc прощает гораздо больше ошибок. И самое страшное что может случиться — тормоза. Без него — всё что угодно, и тормоза, и порча памяти, и утечки.

Самое страшное — твою софтину для биржи на джаве никто не купит. Отсюда ясно, что часть софта в принципе никто даже не станет пытаться писать на джаве.

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

I>>На худой конец, "писать как на Си"

EP>"писать как на Си (для производительности)" — распространённый миф/байка.

Это факты.

>Отказавшись от C++ в пользу "как на C" — ты не получишь никаких преимуществ относительно производительности, а вот недостатки вполне.

Наоборот, полная и внятная предсказуемость.

EP>И, например, там где нужен ref-counting в C++ — он нужен и в C

Наоборот. Рефкаунтинг нужен только в редких случаях. Что характерно, в таких случаях он нужен и в менеджед средах. В С++ это чуть не везде, как дешовая замена ГЦ, от чего растут жесточайшие проблемы.

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

EP>>Вот так — да, как вариант решения подсчёт ссылок, и то в малом количестве мест. Только решать эту проблему нужно и в C, и сюрприз в Java.
·>Не завершится, а освободит последнюю ссылку на ресурс. Мало того, тот кому не повезло освобождать ссылку последним — не придётся тратить ВНЕЗАПНО время на освобождение, вызывая непредсказуемые проблемы с latency.

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

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

dot>>>Да, но gc не обязан это делать всё и сразу, вместо паузы в 100ms он сделает 1500 пауз по 100us. Да, throughput может и меньше, зато latency предсказуемее.
EP>>Если ограничивать GC пороговой latency — то можно получить OOM — банально скорость очистки будет меньше необходимой.
EP>>При этом учти что полноценный цикл GC линеен от количества N живых объектов — может быть например большое N, при малом потоке изменений reachable/unreachable.
dot>ООМ везде можно получить.

Я описываю конкретный case, который есть при использовании GC, и которого нет при использовании scope-based lifetime.
Не надо оправдываться абстрактными "OOM везде можно получить" — я так тоже умею: "везде можно получить расстрел памяти, даже при использовании Java"

dot>>>Можно, конечно, такое же соорудить и в C++, но это будет закат солнца вручную.
EP>>Почему вручную-то? Если есть такой развесистый граф владения — то и очищай его по частям, автоматически.
dot>По каким частям?

Например очищать фиксированное количество объектов за раз, оставшиеся ставить в очередь.

dot>Как эти части определить?

Как того требует задача. Если нужно ограничить время — то соответственно засекаешь время/тики, или что там удобнее.

dot>В каком порядке очищать?

Например в порядке очереди.

dot>Когда ответишь на эти вопросы и многие другие, то переизобретёшь современный gc.

Нет, это неверно. Задача GC в первую очередь отличить reachable от unreachable объектов. А уж делать reclaim порциями, или за один присест — это уже отдельное свойство, причём ортогональное наличию/отсутствию GC.
И, кстати, для C++ возможен и runtime'овый GC (прям в стандарте есть специальное API), и библиотечный (я даже как-то делал for fun).

EP>>Да и возникают они в Java на порядки чаще чем в C++. Элементарный пример: массив объектов, агрегирующих другие объекты, агрегирующих другие ... — вполне типичная ситуация. На Java будет тот самый развесистый граф, а на C++ может быть просто по сути один вектор освобождающийся за O(1) — так как value semantics.
dot>Сам же написал "GC линеен от количества N живых объектов", т.е. сдохший шмат графа можно освобождать также за примерно O(1).

При этом сделав O(N) обход живых объектов, которого нет в случае с C++

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

·>Т.е. неиндусы — никогда не ошибаются? Даже дело не в том, что ошибаются или нет — проверить никак нельзя.
То есть С++ требовательнее к дисциплине программиста. Это его недостаток. Что не так?

·>Не всегда, и не везде.
Любую схему (по крайней мере, среди тупой императивщины) можно реализовать в С++. Если очень надо. Это иногда намного менее удобно, чем в других языках, ясен пень, ну так С++ и не пихают везде подряд, и серебрянной пулей он не является.

·>запретить const_cast же — невозможно.
Это уныло. Ругать язык за то, что в нём можно сделать диверсию — это уныло, потому что диверсию можно сделать в любом языке, что я и показал. И говорить, что якобы в одном языке обнаружить такую откровенную (как конст_каст) диверсию проще, чем в другом — это тоже уныло.

·>В-третьих, вот так в C++ писать уже можно?
А проблема-то в чём? Расскажи, почему в жабе так можно делать (с локами? без них?), а в С++ нельзя? Что за хрень эти иммутабельные классы? Аааа, я понял, в жабе нету типа "указатель на константу", поэтому "иммутальные классы" преподносятся, как откровение.

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

_>>>>·>Если надо "100% безопасна", то никуда не денешься.
_>>>>Ну ОК, раз ты так считаешь, то тогда приведи пример взаимодействия потоков в котором на твой взгляд невозможно обойтись без shared_ptr.
dot>>>Если тебе нужно чтобы не было обращений по невалидным указателям, то ты не можешь делать предположение, что объект по голому указателю ещё жив — надо использовать smart pointers.
EP>>Этот use-case формулируется немного по-другому, например: нужно чтобы ресурс освобождался как только завершится последний поток его использующий, и какой из них будет последним — заранее не известно.
EP>>Вот так — да, как вариант решения подсчёт ссылок, и то в малом количестве мест. Только решать эту проблему нужно и в C, и сюрприз в Java.
dot>Не завершится, а освободит последнюю ссылку на ресурс.

Верно.

dot>Мало того, тот кому не повезло освобождать ссылку последним — не придётся тратить ВНЕЗАПНО время на освобождение,

Пусть просто поставит в очередь, делов-то

EP>>На Java кстати какое решение можешь предложить?
dot>На java память ресурс другого типа. "Освобождать память" там нельзя.

А я поэтому и сказал конкретно "ресурс", а не просто "объект". Да и память не ресурс только если она не ограниченна — упрёшься в предел, получишь удар по latency, на который постоянно ссылаешься.

dot>А для ресурсов в общем случае — наследники java.lang.ref.Reference.

Каким образом они обеспечат prompt finalization?

_>>>>·>Да не надо локи. Есть много других механизмов.
_>>>>Например? )
dot>>>CAS, volatile, happens-before.
EP>>На них точно также получаются локи. Чтобы их не было, нужно использовать например lock-free / wait-free схемы.
dot>Ну да... Только, как мне кажется. эти схемы гораздо проще если есть gc.

При GC чуть проще реализация lockfree структур данных, за счёт ABA, но при этом сами GC в большинстве своём не lockfree (lockfree GC видел только в статьях) — то есть тут уже большой терминологический вопрос, остаётся ли структура данных lockfree при не non-lockfree GC
Да и такие структуры должны реализовывать профессионалы своего дела, так как это трудная/опасная тема.

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

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

_>>>"Круче" — это не инженерный термин. Я такого не использовал. Я говорил о том, что sqlpp11 заметно быстрее (вот это уже инженерный термин) EF при одинаковом синтаксисе. Против этого есть какие-то возражения или нет?
S>> Заметно быстрее чего?

_>Вроде бы вполне ясно написано. sqlpp11 заметно быстрее EF (да и вообще любого ORM на базе linq).

S>>Я могу через t4 используя Linq сгенерировать запросы и классы для заполнения. По скорости будет то же самое.

_>Безусловно. А можно даже и без t4 просто голые sql строки вставить и опять же будет отличная скорость. Нюанс в том, что в обоих этих случаях синтаксис станет не как у linq. А вот sqlpp11 сохраняет такой синтаксис без потерь в скорости.

S>>Есть дополнительные расходы. Но функциональность sqlpp11 не в какое сравнение с EF нет и близко.

_>Вроде бы весь набор операций, нужный для работы с sql имеется. Причём в полном соответствие с linq синтаксисом (одним из двух вариантов). А что ещё надо для ORM? )
Еще раз нет навигационных свойств. А в них весь смысл. Еще раз нет сравнения эффективности на сложных запросах. Как ты можешь утверждать без тестов. Это уже религия.

S>> Еще раз ты ставишь скорость во главу угла. Еще раз напомню про 1С где скорость интерпритатора не в разы, а в сотни и тысячи раз медленнее. Но мало кого это беспокоит. Главное скорость разработки.

_>Что значит я ставлю скорость во главу угла? ) Я пока что всего лишь сделал утверждение о быстродействие двух разных ORM. И я так понимаю по этому поводу нет никаких возражений? ))) Если же начинать говорить о выборе какого-то из них для какой-то конкретной задачи, то это уже глупо будет, т.к. данные ORM реализованы на разных платформах, выбор между которыми для какой-то задачи явно будет определяться не возможностями ORM, а более серьёзными вещами. А соответственно выбрав платформу мы автоматически получим выбор ORM (ну если говорить о выборе между двумя обсуждаемыми вариантами, так то под каждую платформу есть много вариантов).

Еще раз твои утверждения голословны. Почему ты считаешь, что наколеночная реализация сделает оптимальный реализацию СКул запроса. Где тесты одинаковых запросов?
_>>>Не надо от моего имени высказывать какие-то странные фразы. Я говорил вполне конкретные вещи (см. выше) и их уже вполне доказал. А SQLAlchemy я посоветовал посмотреть уже не в качестве аргумента в данной дискуссии, а просто для расширения кругозора на тему вариантов реализации мощных ORM. А то знать только подобное EF — это как-то печально.
Ничего ты не доказал. Ты только утверждаешь, что генерится запрос на этапе компиляции. Его эффективность ты не доказал. На самом деле бывают очень сложнве запросы, где не всегда эффективно генерится запрос. Кроме того запросы кэширутся и есть куча динамических запросов которые могут различаться как по количеству параметров запроса так и по условиям соединениям итд.
Все твои выкладки голословны. Нет ни одного сравнения.
S>> И это говорит человек незнающий 1С и EF. Я тебе кучу примеров и статей на русском. А ты дал просто название, без всяких ссылок. Поверь мне интересны новые подходы.
S>> SQLAlchemy я так понимаю, что это библиотека для питона. Вопрос в чем отличие от 1С?
S>>Посмотрел https://ru.wikibooks.org/wiki/SQLAlchemy. Не увидел ничего нового.

_>Лучше смотреть не в википедии, а на сайте производителя http://www.sqlalchemy.org и там на самом деле весьма много отличий. )))
Смотрел, там так и не нашел. Так если ты знаток ЕФ расскажи плюсы и минусы. Заметь я тебе кучу примеров привел, что бы е быть голословным

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

I>>>На худой конец, "писать как на Си"
EP>>"писать как на Си (для производительности)" — распространённый миф/байка.
I>Это факты.

Приведи аргументы в поддержку "фактов".

>>Отказавшись от C++ в пользу "как на C" — ты не получишь никаких преимуществ относительно производительности, а вот недостатки вполне.
I>Наоборот, полная и внятная предсказуемость.

Относительно производительности — сплошные недостатки

I>В С++ это чуть не везде, как дешовая замена ГЦ,

Дешёвая замена GC это прежде всего scope-based lifetime management.
Даже если использовать refcounting не только для решения задач в которых есть естественное разделение владения, а и для случаев где можно спокойно обойтись например unique_ptr — таких случаев всё равно на порядки меньше чем "new" в управляемых языках.

I>от чего растут жесточайшие проблемы.

Основные проблемы растут от использования указателей вообще (будь то naked, smart, GC).
Непосредственно ref-counting (в тех случаях где он не нужен по задаче, но нужны указатели) — это где-то на уровне процентов от общих проблем.