Re[2]: Java vs C# vs C++ - Философия программирования

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

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

S>> Это и есть понятие.Из за него в общем то и городится весь огород.
S>>Кстати это говорит о том, что ты не читаешь моих ссылок.
S>> Там куча примеров к доступу к объектам через навигационные свойства.

_>А с чего ты взял, что мне должен быть знаком термин "навигационные свойства"? ) Он не известен ни в мире SQL, ни просто в мире программирования. Так что используя такие специфические термины из какой-то там одной библиотечки одного языка, полагается пояснять их.
Для того, что бы что то хаять нужно ознакомиться с темой?

_>Ладно, так и быть, я не поленился и глянул в гугле что это хрень такая. Оказывается (судя по тому, что я прочитал) это автоматические запросы данных в соседних таблицах в случае нахождения в таблице внешних ключей. Крайне сомнительная возможность, особенно в контексте быстродействия.
Я же тебе давал ссылки, показывал какие генерятся запросы. Ничего сомнительногог, сильно уменьшант количество лишнего кода.

S>> Я могу сразу сказать, что конечно можно самому добавить левые соединения, но это будет значительно больше кода чем как ты тут выразился про ужасные предваритеные компиляции запроса

_>Между прочим это может быть не единственным решением. В определённых ситуациях гораздо более выгодными могут быть отдельные запросы.
Я тебя уверяю, что нет. В 8 ке есть аналогичные запросы .

Опять же выдержка из статьи http://infostart.ru/public/402433/

Кроме того в Linq to EF можно использовать Entity SQL

Например

varstr = @"Select VALUE  p From [Спр_Номенклатура] asp";

           varЗапрос = qr.CreateQuery<Справочник.Номенклатура>(str );

           var res = Запрос.Execute(MergeOption.NoTracking);

 

           foreach (varэлемin res)

            {

                Console.WriteLine("{0}.{1} - {2}", элем.Наименование.TrimEnd(), элем.Артикул, элем.ПолнНаименование.TrimEnd());

            }

Но по большому счету выхлоп от него небольшой

https://msdn.microsoft.com/ru-ru/library/bb738573(v=vs.110).aspx
Отличия Entity SQL и Transact-SQL

Есть очень интересный проект 1С++ там можно строить запросы, но доступ к навигационным свойствам нет. Приходится городить кучу левых соединений.
Это значительно менее читабельно, и большая возможность ошибки. А вообще основной смысл Линк для СкуЛ как раз и есть навигационные свойства.

S>>>>Угу sqlpp11 это доказывает, что ему до EF как среднестатистическому 1С нику до С++ гуру
_>>>Аргументированно. )))
S>> Так а где твои аргументы, сравнивая наколеночную разработку по которой нет ни статей, с минимумом упоминаний в интернете с EF огромным количеством материалов, обсуждений итд.
S>> Еще раз в моей статье больше примеров чем в разработке по твоей ссылке.

_>Да, всё правильно. ) sqlpp11 — это чья-то там мелкая наколенная разработка, а EF — это здоровенный продукт мегакорпорации. И тем забавнее, что эта наколенная штуковина является намного более быстродействующей (просто по построению) при точно таком же синтаксисе (т.е. удобстве).
Да ну. Не говори чушь. Синтаксис убогий, нет поддержки навигационных свойств. Нет поддержки биндинга итд.
Тот же Code First миграция итд.
Еще раз глядя на 1С, то там интерперетатор и плевать хотели на скорость, но при этом количество 1С ников в нашей стране с лихвой перекрывают С++ ников.
Наверное не все так гладко в вашем королевстве.
C#, Java это компромисс между удобством и небольшим замедлением, которое легко восполняется покупкой более производительного оборудования.

Это поделка 10 летней давности уровня типа объект ObjectSpaces http://rsdn.ru/article/dotnet/objectspaces.xml
S>>Кроме того удобство в биндинге и редактировании

S>>http://metanit.com/sharp/entityframework/3.3.php

_>Это опять же уже не имеет никакого отношения к ORM — это уже возможности GUI библиотеки. Причём в любом языке (в C# это тоже относится не к EF, а к WinForms). И в C++ естественно тоже полно решений на эту тему, но это уже совершенно другие библиотеки.
Это относится и к WPF. И здесь продумано все в одном без лишних телодвижений с поддержкой Студии.

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

·>Если нужна передача данных между тредами — нужен shared pointer, который использует lock (mutex?) — источник непредсказуемых жутких тормозов — для low latency не годится.

shared pointer нужен в случае параллельного доступа к данным из разных потоков с неизвестным заранее временем жизни. Это совсем не частный случай даже в системах с подобным параллельным доступом. А если использовать более продуманные архитектуры (типа той же модели акторов), то подобные вопросы не встают в принципе. Тем более, что при использование семантики перемещения модель акторов становится такой же эффективной, как и просто общая память (в варианте без блокировок).

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

_>Ну да, помимо наличие компилятора языка, требуется ещё наличие соответствующей квалификации. Нюанс в том, что даже самый крутой эксперт по C# не сможет написать одновременно красивый и быстрый код

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

> — ему обязательно понадобиться лезть в какие-то рукопашные вещи типа unsafe игр или ручного sql кода.

1. Быстрый код всегда и везде это результат работы головой, а у тебя красной нитью через все собщения "быстрый код это только С++ хы хы"

2. ручной sql код как раз встречается именно в С++. Нормальных OR/M там нет и наверное никогда не будет. Тамошние люди зачастую пишут классный код по конкатенации запросов, что бы выполнить какой нибудь мусор, который будет выполняться чуть не минутами.

3. Вообще, красота и дизайн вещи сильно противоположные. Красота == эстетическое. Дизайн == утилитарное. Пудозреваю, для тебя это одно и то же. Отсюда ясно, что неюзабельные уродцы для тебя эталон красоты

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

_>>А с чего ты взял, что мне должен быть знаком термин "навигационные свойства"? ) Он не известен ни в мире SQL, ни просто в мире программирования. Так что используя такие специфические термины из какой-то там одной библиотечки одного языка, полагается пояснять их.
S> Для того, что бы что то хаять нужно ознакомиться с темой?

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

_>>Ладно, так и быть, я не поленился и глянул в гугле что это хрень такая. Оказывается (судя по тому, что я прочитал) это автоматические запросы данных в соседних таблицах в случае нахождения в таблице внешних ключей. Крайне сомнительная возможность, особенно в контексте быстродействия.
S> Я же тебе давал ссылки, показывал какие генерятся запросы. Ничего сомнительногог, сильно уменьшант количество лишнего кода.

Подобная функциональность очевидно тривиально (в несколько строк) добавляется практически в любую ORM. Только вот я что-то не помню такого ни в одной, из тех, что я видел (причём речь далекое не только про C++). Интересно почему... )))

_>>Между прочим это может быть не единственным решением. В определённых ситуациях гораздо более выгодными могут быть отдельные запросы.
S> Я тебя уверяю, что нет. В 8 ке есть аналогичные запросы .
S>...
S> Есть очень интересный проект 1С++ там можно строить запросы, но доступ к навигационным свойствам нет. Приходится городить кучу левых соединений.
S>Это значительно менее читабельно, и большая возможность ошибки. А вообще основной смысл Линк для СкуЛ как раз и есть навигационные свойства.

Я же сказал, отдельные запросы, а не ручные join'ы. Т.е. допустим мы получаем полный список объектов (как раз в виде внешних ключей) из одной таблице, а потом получаем уже сами объекты из другой таблице. По одной штуке за раз и только в тот момент, когда пользователь их запросил (допустим выделил в списке).

_>>Да, всё правильно. ) sqlpp11 — это чья-то там мелкая наколенная разработка, а EF — это здоровенный продукт мегакорпорации. И тем забавнее, что эта наколенная штуковина является намного более быстродействующей (просто по построению) при точно таком же синтаксисе (т.е. удобстве).
S> Да ну. Не говори чушь. Синтаксис убогий, нет поддержки навигационных свойств. Нет поддержки биндинга итд.

Синтаксис в точности как у Linq. ) "Навигационные свойства" на мой взгляд не нужны. Но если вдруг кому-то очень понадобятся, то очевидно элементарно (т.к. уже есть полноценно работающие join"ы) добавляются в библиотеку. Биндингов нет и в EF. )))

_>>Это опять же уже не имеет никакого отношения к ORM — это уже возможности GUI библиотеки. Причём в любом языке (в C# это тоже относится не к EF, а к WinForms). И в C++ естественно тоже полно решений на эту тему, но это уже совершенно другие библиотеки.
S> Это относится и к ВПФ. И здесь продумано все в одном без лишних телодвижений с поддержкой Студии.

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

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

_>>Ну да, помимо наличие компилятора языка, требуется ещё наличие соответствующей квалификации. Нюанс в том, что даже самый крутой эксперт по C# не сможет написать одновременно красивый и быстрый код
I>Это следствие из того, что менеджед плтформа требует определенные издержки.
I>Не надо приплетать сюда крутость, язык, квалификацию и тд и тд.

Я вообще то именно это и говорю всё время. Что ограничения платформы не позволяют развернуться даже профи. )

>> — ему обязательно понадобиться лезть в какие-то рукопашные вещи типа unsafe игр или ручного sql кода.
I>1. Быстрый код всегда и везде это результат работы головой, а у тебя красной нитью через все собщения "быстрый код это только С++ хы хы"

Нет, главный тезис не в этом. А в том, что даже хорошо работая головой, у тебя не получится нужный результат на C#. ))) Т.е. это не C++ такой хороший, а JVM/CLR такие плохие.

Что же касается C/C++, то это банально единственный нативный мейнстрим язык, вот и всё. Скажем если бы тот же Rust или D были бы мейнстримом (имели бы компиляторы (причём с мощными оптимизаторами) под все возможные платформы и архитектуры, имели бы полноценную поддержку во всех главные IDE, имели бы тысячи готовых библиотек и т.д. и т.п.), то очевидно что разговоров про "только C++" не было бы. )))

I>2. ручной sql код как раз встречается именно в С++. Нормальных OR/M там нет и наверное никогда не будет. Тамошние люди зачастую пишут классный код по конкатенации запросов, что бы выполнить какой нибудь мусор, который будет выполняться чуть не минутами.

Помнится мы разок уже обсуждали что-то подобное и ты тогда слился из дискуссии, когда не смог привести аналог на C# простейшего C++ кода работы с ORM. Причём тогда это была не sqlpp11, а другая, более простая ORM. )))

I>3. Вообще, красота и дизайн вещи сильно противоположные. Красота == эстетическое. Дизайн — утилитарное. Пудозреваю, для тебя это одно и то же. Отсюда не ясно, что неюзабельные уродцы для тебя эталон красоты

Мне в этом смысле нравится точка зрения Туполева: http://www.aphorisme.ru/by-authors/tupolev/?q=5451

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

_>Синтаксис в точности как у Linq. ) "Навигационные свойства" на мой взгляд не нужны. Но если вдруг кому-то очень понадобятся, то очевидно элементарно (т.к. уже есть полноценно работающие join"ы) добавляются в библиотеку. Биндингов нет и в EF. )))
Есть. Сразу видно, что мало используешь SQL. Заметь твою библиотечку мало кто использует. Проще использовать конструкторы запросов, а вот с использованием навигационных свойств сразу и запросы и линки становятся намного привлекательнее.
Не хай, то о чем имеешь очень поверхностное понятие.

Синтаксис в точности как у Linq. ) "Навигационные свойства" на мой взгляд не нужны. Но если вдруг кому-то очень понадобятся, то очевидно элементарно (т.к. уже есть полноценно работающие join"ы) добавляются в библиотеку. Биндингов нет и в EF. )))

По поводу биндинга

 dataGridView1.DataSource = db.Players.Local.ToBindingList();

https://msdn.microsoft.com/ru-ru/library/gg696248(v=vs.113).aspx

DbSet<TEntity>.Local — свойство

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

Это свойство может использоваться для привязки данных путем заполнения набора данными, например путем вызова метода расширения Load и последующей привязки к локальным данным через это свойство. Для WPF выполняйте привязку к этому свойству напрямую. При использовании Windows Forms осуществляйте привязку к результату вызова метода ToBindingList для этого свойства.

http://professorweb.ru/my/entity-framework/6/level3/3_3.php

У линка 2 синтаксиса. Мне больше нравится Sql подобный. Он более читабельный. Часто совмещаю их где какой удобнее.

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

I>>Не надо приплетать сюда крутость, язык, квалификацию и тд и тд.

_>Я вообще то именно это и говорю всё время. Что ограничения платформы не позволяют развернуться даже профи. )

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

>>> — ему обязательно понадобиться лезть в какие-то рукопашные вещи типа unsafe игр или ручного sql кода.
I>>1. Быстрый код всегда и везде это результат работы головой, а у тебя красной нитью через все собщения "быстрый код это только С++ хы хы"

_>Нет, главный тезис не в этом. А в том, что даже хорошо работая головой, у тебя не получится нужный результат на C#. ))) Т.е. это не C++ такой хороший, а JVM/CLR такие плохие.

А холодильник — говно, потому что в него машину нельзя поставить.

I>>2. ручной sql код как раз встречается именно в С++. Нормальных OR/M там нет и наверное никогда не будет. Тамошние люди зачастую пишут классный код по конкатенации запросов, что бы выполнить какой нибудь мусор, который будет выполняться чуть не минутами.

_>Помнится мы разок уже обсуждали что-то подобное и ты тогда слился из дискуссии, когда не смог привести аналог на C# простейшего C++ кода работы с ORM. Причём тогда это была не sqlpp11, а другая, более простая ORM. )))

Ты наверное попутал, в дотнете есть вагон и маленькая тележка самых разных средств для работы с базой. Скорее на С++ ты вспотеешь повторять аналог, потому как полу-ОРМ не сумеет внятно оптимизировать запросы, например по причине отсутствия внятных Expression Tree. А это значит, вместо работы над оптимизитором люди будут изобретать эти самые Expression Tree и решать проблемы унификации, долго и мучительно рожать АПИ и тд и тд и тд.

I>>3. Вообще, красота и дизайн вещи сильно противоположные. Красота == эстетическое. Дизайн — утилитарное. Пудозреваю, для тебя это одно и то же. Отсюда не ясно, что неюзабельные уродцы для тебя эталон красоты

_>Мне в этом смысле нравится точка зрения Туполева: http://www.aphorisme.ru/by-authors/tupolev/?q=5451

Это слишком древняя фраза, что бы пользоваться её без оглядки.

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

_>Да, всё правильно. ) sqlpp11 — это чья-то там мелкая наколенная разработка, а EF — это здоровенный продукт мегакорпорации. И тем забавнее, что эта наколенная штуковина является намного более быстродействующей (просто по построению) при точно таком же синтаксисе (т.е. удобстве).

Ага, Жыгули быстре чем БелАз !!!!111расрас

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

·>Под умными указателями понимается всё что угодно. Unique да, просто языковая конструкция, но он и не потокобезопасный.
·>Если нужна передача данных между тредами — нужен shared pointer, который использует lock (mutex?) — источник непредсказуемых жутких тормозов — для low latency не годится.

А может передавать сырой указатель? А хозяином будет главный поток, независимый от тех, которым нужны данные, и который ждёт сигнала от всех потоков?

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

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

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

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

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

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

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

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

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

Испокон веков писали на С++, даже ОС реального времени наклепали десятками для таких случаев.

В джаве писать легче, но нет гарантии, что GC отработает точно в срок. Отсюда ясно, что рантайм надо сециально готовить — использовать специальный GC, всякие off-heap техники, что бы GC не лез когда не надо.

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

_>>Синтаксис в точности как у Linq. ) "Навигационные свойства" на мой взгляд не нужны. Но если вдруг кому-то очень понадобятся, то очевидно элементарно (т.к. уже есть полноценно работающие join"ы) добавляются в библиотеку. Биндингов нет и в EF. )))
S> Есть. Сразу видно, что мало используешь SQL. Заметь твою библиотечку мало кто использует.

Эту библиотеку мало используют, потому что она только недавно появилась на свет. Если тебя интересуют популярные и проверенные временем ORM решения на C++ то смотри:
1. ODB — довольно жирный фреймворк на эту тему.
2. SOCI — лёгкая библиотечка (мой выбор до появления sqlpp11, т.к. я не люблю жирные фреймворки).

S> Проще использовать конструкторы запросов, а вот с использованием навигационных свойств сразу и запросы и линки становятся намного привлекательнее.
S> Не хай, то о чем имеешь очень поверхностное понятие.

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

S>По поводу биндинга
S>

S> dataGridView1.DataSource = db.Players.Local.ToBindingList();
S>

S>https://msdn.microsoft.com/ru-ru/library/gg696248(v=vs.113).aspx
S>

S>DbSet<TEntity>.Local — свойство
S>Возвращает объект ObservableCollection<T>, содержащий локальное представление всех добавленных, неизменившихся и измененных сущностей в наборе. Это локальное представление остается синхронизированным по мере добавления или удаления сущностей из контекста. Аналогичным образом добавляемые или удаляемые из этого локального представления сущности автоматически добавляются в контекст или удаляются из контекста.

Ну так всё в точности как я и говорил. ObservableCollection, реализующая биндинг, не имеет никакого отношения к EF. Или может тебе показалось, что я говорил что биндинга нет во всём .net? )))

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

_>>Помнится мы разок уже обсуждали что-то подобное и ты тогда слился из дискуссии, когда не смог привести аналог на C# простейшего C++ кода работы с ORM. Причём тогда это была не sqlpp11, а другая, более простая ORM. )))
I>Ты наверное попутал, в дотнете есть вагон и маленькая тележка самых разных средств для работы с базой. Скорее на С++ ты вспотеешь повторять аналог, потому как полу-ОРМ не сумеет внятно оптимизировать запросы, например по причине отсутствия внятных Expression Tree. А это значит, вместо работы над оптимизитором люди будут изобретать эти самые Expression Tree и решать проблемы унификации, долго и мучительно рожать АПИ и тд и тд и тд.

http://rsdn.ru/forum/philosophy/5372076?tree=tree ну конечно попутал... )))

I>>>3. Вообще, красота и дизайн вещи сильно противоположные. Красота == эстетическое. Дизайн — утилитарное. Пудозреваю, для тебя это одно и то же. Отсюда не ясно, что неюзабельные уродцы для тебя эталон красоты

_>>Мне в этом смысле нравится точка зрения Туполева: http://www.aphorisme.ru/by-authors/tupolev/?q=5451
I>Это слишком древняя фраза, что бы пользоваться её без оглядки.

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

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

I>>Ты наверное попутал, в дотнете есть вагон и маленькая тележка самых разных средств для работы с базой. Скорее на С++ ты вспотеешь повторять аналог, потому как полу-ОРМ не сумеет внятно оптимизировать запросы, например по причине отсутствия внятных Expression Tree. А это значит, вместо работы над оптимизитором люди будут изобретать эти самые Expression Tree и решать проблемы унификации, долго и мучительно рожать АПИ и тд и тд и тд.

_>http://rsdn.ru/forum/philosophy/5372076?tree=tree ну конечно попутал... )))

Ага, понял, ты нашел доказательство, что дотнетных OR/M нет вещей, которые должны быть в OR/M искаропки ?

Есть целый форум на данном сайте, посвящен таким вот вопросам. Сходи туда, если ты хотел выяснить вопрос.

I>>Это слишком древняя фраза, что бы пользоваться её без оглядки.
_>Я думаю она справедлива для всего инженерного дела, одним из подвидов которого и является программирование.

И это чушь. Красота, как эстетическое, сильно субъективна, фактически — мода. Сегодня самолёты красивы, а завтра скажут, что это тупорылые огурцы. Из этого не следует, что самолеты должны задним числом перестать летать.

Так и в программировании, когда ты сидел носом в С++, естетсвенно, тебе ничего кроме с++ не покажется красивым.

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

_>·>Если нужна передача данных между тредами — нужен shared pointer, который использует lock (mutex?) — источник непредсказуемых жутких тормозов — для low latency не годится.

_>shared pointer нужен в случае параллельного доступа к данным из разных потоков с неизвестным заранее временем жизни. Это совсем не частный случай даже в системах с подобным параллельным доступом. А если использовать более продуманные архитектуры (типа той же модели акторов), то подобные вопросы не встают в принципе. Тем более, что при использование семантики перемещения модель акторов становится такой же эффективной, как и просто общая память (в варианте без блокировок).
Это не частный случай, а наиболее простая имплементация. Конечно, можно внимательно изучить, установить время жизни каждого объектика, но это сложно контролировать и тестировать, а в случае ошибки — undefined behaviour. В случае же java — самое страшное что будет — это latency spike из-за garbage collection, а не порча данных, как в случае ошибок с указателями.
Модель акторов — в первую очередь для упрощения параллелизма, а не low latency.

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

TB>·>Под умными указателями понимается всё что угодно. Unique да, просто языковая конструкция, но он и не потокобезопасный.
TB>·>Если нужна передача данных между тредами — нужен shared pointer, который использует lock (mutex?) — источник непредсказуемых жутких тормозов — для low latency не годится.
TB>А может передавать сырой указатель? А хозяином будет главный поток, независимый от тех, которым нужны данные, и который ждёт сигнала от всех потоков?
Сырой указатель — опасно. И опять же — какие сигналы? Опять локи?

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

·>Сырой указатель — опасно.

Если ты знаешь, что хозяин дохнет позже пользователей, то нет.

·> И опять же — какие сигналы? Опять локи?

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

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

I>·>Короче, может и можно писать low latency на C++, но сложнее на порядок.
I>Испокон веков писали на С++, даже ОС реального времени наклепали десятками для таких случаев.
Испоконнее — pure C или даже ассемблер. Но традиция — не аргумент.

I>В джаве писать легче, но нет гарантии, что GC отработает точно в срок. Отсюда ясно, что рантайм надо сециально готовить — использовать специальный GC, всякие off-heap техники, что бы GC не лез когда не надо.
Нет гарантии и в случае с умными указателями, что освобождение заковыристого графа не нарвётся на lock или тупо будет работать долго, например, удаление одного объекта вызвало разрушение целой толпы других, gc же может съесть слона по кусочкам. А вообще есть Zing JVM и прочие RT GC. Задежка GC более 10ms — репортим баг.

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

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

_>>>Синтаксис в точности как у Linq. ) "Навигационные свойства" на мой взгляд не нужны. Но если вдруг кому-то очень понадобятся, то очевидно элементарно (т.к. уже есть полноценно работающие join"ы) добавляются в библиотеку. Биндингов нет и в EF. )))
S>> Есть. Сразу видно, что мало используешь SQL. Заметь твою библиотечку мало кто использует.

_>Эту библиотеку мало используют, потому что она только недавно появилась на свет. Если тебя интересуют популярные и проверенные временем ORM решения на C++ то смотри:
_>1. ODB — довольно жирный фреймворк на эту тему.
_>2. SOCI — лёгкая библиотечка (мой выбор до появления sqlpp11, т.к. я не люблю жирные фреймворки).
Так и приводи примеры из них. Я тебе кучу ссылок и примеров привожу. Просто понятно, что ты ими не пользуешься.

S>> Проще использовать конструкторы запросов, а вот с использованием навигационных свойств сразу и запросы и линки становятся намного привлекательнее.
S>> Не хай, то о чем имеешь очень поверхностное понятие.

_>Это похоже как раз ты имел дело исключительно с EF и меряешь по нему весь остальной мир. ))) Я же имел дело с ORM в разных языках, в том числе и в динамических (где с этим всё гораздо проще и сильнее). И там популярны совсем другие практики (хотя очевидно, что сделать аналогичное решение тривиально).
Я исключительно имею дело с 1С. EF это хобби. И я вижу огромные плюсы.

S>>По поводу биндинга
S>>

S>> dataGridView1.DataSource = db.Players.Local.ToBindingList();
S>>

S>>https://msdn.microsoft.com/ru-ru/library/gg696248(v=vs.113).aspx
S>>

S>>DbSet<TEntity>.Local — свойство
S>>Возвращает объект ObservableCollection<T>, содержащий локальное представление всех добавленных, неизменившихся и измененных сущностей в наборе. Это локальное представление остается синхронизированным по мере добавления или удаления сущностей из контекста. Аналогичным образом добавляемые или удаляемые из этого локального представления сущности автоматически добавляются в контекст или удаляются из контекста.

_>Ну так всё в точности как я и говорил. ObservableCollection, реализующая биндинг, не имеет никакого отношения к EF. Или может тебе показалось, что я говорил что биндинга нет во всём .net? )))
Ну вообще то это есть реализация классов и прокси которая реализуется компилятором и которые являются сущностями EF.

	От:	Evgeny.Panasyuk
	Дата:	07.10.15 01:53
	Оценка:

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	07.10.15 06:18
Оценка:

	От:	alex_public
	Дата:	07.10.15 06:44
	Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	07.10.15 07:15
Оценка:	+1 -1

	От:	alex_public
	Дата:	07.10.15 07:25
	Оценка:	+1