Search
Write a publication
Pull to refresh
14
0.6

Инженегр АСУТП

Send message
Как глупо породивший этот весь флейм в упомянутом топике таки спрошу — чем не устраивает полный и развернутый ответ в книге Мейерса?

Кстати, std::string в случае SSO (small string optimization), не относится к объектам с дешевым перемещением.
Не очень понял, какой тип, если это статическая типизация, выведет Кристалл для test
play.crystal-lang.org/#/r/7a17 — ошибка выведения типа,
если же test += 1 — то тоже ошибка…
Ну в D и так неплохо с лайфтаймами, так что доработки вряд ли будут большими.
Не неадекватно, но неэффективно. См чуть выше

Посмотрел. У «известного автора», выпустившегося 5 лет назад, целый 1(один) репозиторий на С++.
Впрочем молодые революционеры такие и есть — им плевать на индустриальный опыт поколений. Я уж молчу про очередную попытку рассказать, что везде все плохо, только в Расте [будет] хорошо…
Как показала последовавшая дискуссия, действительно, знает только KanuTaH =)

Полный правильный ответ находится в учебнике Мейерса «Эффективный и современный С++» Глава 8.1

Другое дело, что предложенный автором вариант, как указано у того же Мейерса, не всегда плохой.
И задача ТС стояла в другом — показать [надуманную] проблему со списками инициализации, а не эффективный код. Так что, вероятно, я немного перегнул — приношу извинения…
предлагаю почитать учебник про std::move. зачем и почему
Пример, приведенный для С++, укуренный неверный бред
class person {
  person(std::string first_name, std::string last_name)
    : first_name(std::move(first_name))
    , last_name(std::move(last_name))

Здесь должны быть универсальные ссылки, чтобы это работало адекватно.

Собственно, уровень знаний аффвтора, аналогичен и в остальном.

P.S.Дочитал. Автор не знает С++ совсем. Пусть хотя бы quiz сдаст.
Чтобы навязать новые псевдошифрованные средства, нужно скомпрометировать репутацию надежных старых.
В этом смысл статьи.
И пожалейте майора, ему же неудобно…
Для программиста это выглядит как бред необразованного юзера.

Прямой вызов, пусть даже неэффективной функции, против слоя виртуализации…

Скорее политические мотивы.
Виртуалка не нужна. У WSL1 еще был шанс.

О, да в этой «отличной» статье даже не сказано, что WSL2 это HyperV и конфликтует с остальными средствами виртуализации…
А если прикрепить такой файл в мейл.ру и запросить просмотр файла в почте?
По существу ООСУБД прошли долгий практический путь и сначала стоит изучить, что и как там сделано.
А на Ваш хелловорлд в две таблички с очевидными выводами смотреть неинтересно — здесь не с чем спорить.

Я бы развернул Ваш вопрос ровно наоборот — почему ООСУБД не используются повсеместно, если такие удобные?
Как выше уже заметил lair, демагогия в определениях как раз идет от Вас. Стандартный SQL — уже декларативный [почти] функциональный язык. У Вас же просто объектное (причем простейшее, без вложенных объектов) расширение над RDBMS с попыткой изобрести велосипед новый язык запросов.

По поводу конкретных реализаций — я же написал — смотреть в английской версии Вики (слева в меню кнопочка English).

Еще можно посмотреть по популярности тут.
Это не функциональная СУБД, а объектно-ориентированная СУБД. Лучше читать в англоязычной вики. Тема очень старая.
Первые публикации об объектно-ориентированных базах данных появились в середине 80-х годов.

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

Если не ошибаюсь поверхностным взглядом, это обычная (хорошо, еще если — потому что я не заметил в роликах нормальной реализации переходов FSA) реализация ru.wikipedia.org/wiki/IEC_61131-3 SFC

Впрочем, за приоритет можно поспорить, но я сталкивался с реализацией от Сименса лет 15-20 назад.
Active Oberon выглядит неплохо, но компилятор единственный под свою частную песочницу. Существенных проблем (кроме того что рантайм песочницы WinAOS/LinAOS имеет качество некоммерческого студенческого проекта) там отсутствие проверок переполнения/качества вычислений и контроль ошибок только кодами возврата. Принципиальной выгоды перед промышленным стандартом IEC 61131-3 ST я не вижу никакой, скорее наоборот.

Говорить, что исключаем опенсорсный! компилятор АДЫ из рассмотрения по вышеуказанной причине, имея для АО еще худшую ситуацию — это прямой и явный зашквар (заинтересованное участие в «тендере» выбора решений).
Ну про С++98 это перебор — на нем очень неудобно писать с STL (а без нее опять сырые указатели итп), а вот с++11/14 +линтер уже вполне безопасен и удобен по сравнению с другими условно безопасными языками.

Единственный слаборешенный вопрос был с глобальной оптимизацией при наличии исключений, который привел в итоге к noexcept.

Ну еще спорная производительность ARC, которая впрочем обходится минимизацией использования кучи.

Впрочем последние две темы настолько тонкие, что в большинстве языков до обсуждения такого дело и не доходит — есть проблемы покрупнее =)
Сейчас проекты экспортируются в текстовый/Иксмл формат и могут сравниваться.
В принципе, я читаю например Роквелловские или Сименса текстовые диффы для релейки.

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

Information

Rating
3,306-th
Location
Россия
Registered
Activity