Delphi vs C#

Всем привет.
Я уже давно люблю покодить на делфи(7) и вот решил попробовать на с#.
Тема глупая и затасканная, но все же какие преимущества я получу(и недостатки) с точки зрения любителя.

0

Сообщение от Shamil1 А зачем мне точный тип?

К примеру в процессе использования он пришел в состояние когда его дальнейшее существование невозможно. Объект != пассивный буфер. Это активная сущность возможность дальнейшего существования которого зависит только от его внутреннего состояния а не от его нужности кому то. Пример - если коннекция отпала ну она должна быть удалена без разницы что она кому то нужна. Т.е. нужность его кому то никак не влияет на возможность продолжения существования.

Добавлено через 2 минуты

Сообщение от Shamil1 Объе́ктно-ориенти́рованное программи́рование (ООП) — методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определённого класса, а классы образуют иерархию наследования.

Нам бы двойку за такое определение поставили на экзамене. Даже все остальное слушать не стали бы. Оно абсолютно не отражает сути методологии проектирования. При этом абсолютно упускается из виду что основной этап разработки - постановка задачи, т.е. описание предметной области при помощи сущностей и взаимосвязей между ними. Википедия не более чем мурзилка для посторонних.

Добавлено через 1 минуту

Сообщение от Shamil1 Для иммутабельного вектора есть такая же функция, но она не меняет исходный вектор, а возвращает новый.

Т.е. она возвращает то вроде пары ренджей старого вектора и одного нового элемента?

0

Сообщение от Fulcrum_013 Т.е. она возвращает то вроде пары ренджей старого вектора и одного нового элемента?

Нет. Она возвращает новый вектор.
Напомню, иммутабельный вектор реализован по-другому (не через массив, как мутабельный).

Добавлено через 8 минут
Не важно, как этот вектор внутри реализован. Важно время операций. Для копирования О(1). Для добавления в конец О(1). Для доступа по индексу, изменения, вставки, удаления - О(log₃₂) - практически О(1), так как размер векторов редко больше 1млн, часто меньше 1 тысячи.

Добавлено через 2 минуты

Сообщение от Fulcrum_013 Нам бы двойку за такое определение поставили на экзамене.

Лекторы они такие разные бывают, и определения могут разные давать.

Добавлено через 1 минуту

Сообщение от korvin_ Ага, но есть нюанс, термины «объект» и «класс» не имеют однозначных определений.

Термин "ООП" тоже не имеет однозначного определения.

Добавлено через 4 минуты

Сообщение от Fulcrum_013 Пример - если коннекция отпала ну она должна быть удалена без разницы что она кому то нужна.

Зачем? Если объект самоудаляется, то мне перед каждым использованием придётся проверять, не самоудалился ли он. Лучше иметь объект в неисправном состоянии. Тогда я по крайней мере смогу узнать, что именно в нём сломалось. А вместо проверок - обернуть в try-catch/

0

Shamil1, Ну и как этот вектор реализован под капотом? Как понимаю ссылка на старый + список изменений и инкапсулированный в operator [] восстановление конкретного элемента по списку изменений.

Сообщение от Shamil1 Для доступа по индексу, изменения, вставки, удаления - О(log32) - практически О(1), так как размер векторов редко больше 1млн, часто меньше 1 тысячи.

Вот о чем и речь - под капотом [] перерываются предки. При этом при последовательном доступе абсолютная потеря когерентности кеша, что для мелких элементов типа инта и т.п. выльется в потерю производительности порядка 50x. При этом с какого то момента элементов исходного состояни в результирующем состоянии не останется вообще. т.е. состояния из массива интов превратится в связанный список указателей, который и гораздо больше и доступ к элементу гораздо дольше.
Но в принципе для некоторых применений, когда размер самого состояния (позиции) очень велик,и состояния хешируются для сравнения, (т.е. подавляющее большинство сравнений происходит без сравнения элементов) это может давать очень хороший результат.
Только при чем тут мутабельность/иммутабельность данных? В данном случае верх дерева изменять все равно не надо, все изменения происходят внизу.
Т.е. с мутабельными данными изменяют их тоже не кто попало и не когда попало. Их могут изменять только определенные части алгоритма (приватное состояние класса изменяют только его методы к примеру и далеко не все части алгоритма имеют право эти методы вызывать), и очень часто только в определенных стадиях. К примеру для подсистемы просчета траектории траектория изменяема. А для системы предсказания коллизий, траектория уже неизменяема. Т.е. опять же в случае как и с управлением временем жизни объекта имеем более строгое описание предметной области, которое разруливает все вопросы и снимает проблемы с актуализацией данных для других подсистем/ частей алгоритма, свойственные полной иммутабельности.

Добавлено через 6 минут

Сообщение от Shamil1 Если объект самоудаляется, то мне перед каждым использованием придётся проверять, не самоудалился ли он.

ну это и делает weak_ptr. А полностью двунаправленная система оповещения позволяет обрабатывать это более гибко сразу в момент отвала. К примеру отключить ту часть которая запрашивает данные (хотя в таких системах обычно используется пуш-схема когда коннекция отправляет ивенты о приходе данных потребителям и просто получается уведомление что данных больше не будет), или запустить пересоздание коннекции/активировать альтернативный канал связи.
Точно так же потребитель должен уведомить коннекцию, о том что он отключился чтобы коннекция не слала ему данные (потребителей то может быть и несколько, при этом отсутсвие потребителей данных в текущий момент тоже далеко не всегда служит причиной закрытия коннекции). А по каким причинам и кто грохнул потребителя и грохнул ли вообще или он просто на другой канал переключился или декативировался на время - ну какое до этого дело коннекции?

Добавлено через 19 минут

Сообщение от Shamil1 Лекторы они такие разные бывают, и определения могут разные давать.

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

0

Не ругайтесь, все равно basic лучше всех

0

Сообщение от WH Не ругайтесь, все равно basic лучше всех

Ага УК-НЦ басик вооще язык всех времен и народов

0

Сообщение от Fulcrum_013 на кафедре прикладной математики и вычислительной техники,

Ага. Вот именно на этих кафедрах в разных ВУЗах дают разные определения ООП. И даже в одном ВУЗе разные преподаватели могут давать разные определения.

Сообщение от Fulcrum_013 ну это и делает weak_ptr

И что мне это даст?
Я вызываю функцию, внутри которой используется некий объект. Если он в невалидном состоянии, то я получу исключение с детальным описанием проблемы и её причины. И это как раз то, что нужно. Функция должна выполнять свою задачу, а обработкой ошибок должна заниматься одна из функций вверх по стеку вызовов, которая знает, как нужно обрабатывать ошибки.
А что мне даст использование weak_ptr? Исключение "опаньки! что-то пошло не так"?

Сообщение от Fulcrum_013 состояния из массива интов превратится в связанный список указателей

Неправильно. Вектор не может превратиться в связанный список. Если интересно, можете найти реализацию вектора и посмотреть.

0

Сообщение от Shamil1 Я вызываю функцию, внутри которой используется некий объект.

Вы вообще ничего не вызываете. При поступлении данных объект вызывает вас.

Сообщение от Shamil1 Если он в невалидном состоянии,

То вы сразу же получите уведомление о том что он стал невалидным с любыми там причинами и т.д. ежели это надо.

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

Процедурщина почила в бозе в 80-х. А для ООП характерно событийное управление которое гораздо эффективней и продуктивней. В большинстве случаев объект занесен в какой то список взаимодействия и просто из него автоматически убирается, и его взаимодействие со стороны остальных объектов прекращается да и все. Если кому то от этого поплохело может либо как то на это отреагировать либо самоудалится при получении оповещения. Ну как бы наличие/отсутсвие связи такое же состояние как и остальные, и на еe установку/разрыв точно так же можно реагировать как на любое другое.

Добавлено через 20 минут

Сообщение от Shamil1 А что мне даст использование weak_ptr?

А weak_ptr работает совсем по другому. Там самоудаление в общем то не поддерживается. Он просто не препятствует удалению при достижении счетчиком жестких ссылок 0. Вместе с shared_ptr это просто костыль, эмулирующий GC, но при этом корректно обрабатывающий ресурсы и слабые ссылки, предназначенный для тех кому моск в школе изнасиловали явой.
Пока яву не преподавали в школах он нафиг не нужен был.

Добавлено через 7 минут

Сообщение от Shamil1 Неправильно. Вектор не может превратиться в связанный список. Если интересно, можете найти реализацию вектора и посмотреть.

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

0

Сообщение от Fulcrum_013 Вы вообще ничего не вызываете. При поступлении данных объект вызывает вас.

Звучит как бред.
Пользователь нажимает кнопку. Для выполнения действия вызывается функция (можете называть её методом).

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

Тоже бред.
Пользователь нажимает кнопку. Для выполнения действия вызывается функция.

Сообщение от Fulcrum_013 А weak_ptr работает совсем по другому. Там самоудаление в общем то не поддерживается.

Ну и зачем мне тогда самоудаляющиеся объекты?

Сообщение от Fulcrum_013 Их много. Какую именно вы имеете в виду? Но в любом случае одно из двух - либо вы его полностью копируете, либо пишите лог его изменений, являющийся связным списком

Опять бред.
Посмотрите реализацию иммутабельного вектора. Например, в Clojure.

0

Сообщение от Shamil1 Пользователь нажимает кнопку.

Кнопка отправляет оповещение программе и вот в этом оповещение а действие производится как реакция на это оповещение.
К примеру пользователь нажимает кнопку "слушать музик". Необходимо во первых проверить наличие существующей коннекции. Если ее нету создать коннекцию. На ивенте "готов к работе" пришедшем от созданной коннекции, отправить запрос, и получать опять же на ивенте от коннекции входящий поток. При обрыве связи получить от коннекции соответсвующий ивент и
попытаться пересоздать поток. НУ как бы вот именно так тот же WebSocket работает. Если обрыв присылает уведомление и удаляется.

Сообщение от Shamil1 Пользователь нажимает кнопку. Для выполнения действия вызывается функция.

К примеру кнопку удаления какого либо объекта из документа. Другой взаимосвязанный объект при этом может стать бессмысленным и тоже должен быть удален. Как будете это решать? Т.е. пример очень часто встречающийся приводил - редактор взаимосвязей. Объекты элементы и объекты взаимосвязь между элементами. При удалении элемента проведенные к нему взаимосвязи должны быть удалены. Как будете решать вопрос?
И вот потому что именно этот вопрос в языках с GC решается только ручным перебором мусора, и при этом резко удорожает перебор живых, в WinForms и нет визуального биндинга и т.д. и порезано подавляющее большинство функций визуальной разработки, а не потому что хуман ридабле быстрее или удобнее.

Сообщение от Shamil1 Ну и зачем мне тогда самоудаляющиеся объекты?

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

Сообщение от Shamil1 Опять бред. Посмотрите реализацию иммутабельного вектора. Например, в Clojure.

Бред это про изменение любого элемента. Можно дописать в конец за амортизированное O(1) и назвать это другим вектором. Но это не другое состояние а ведение лога изменений. Иначе может быть только ссылка на исходный вектор и значение измененного элемента с его номером. Вот эта последовательность изменений и превращается в конечном итоге в связный список.
Пример. Шахматная доска. Она может отображать только одну позицию одновременно. Для отображения двух позиций нужно или две доски или имплиментировать на одной лог изменений вперед-назад и третьего не дано.

Добавлено через 37 минут
Shamil1, При этом на ленте имплементация лога изменений имеет меньшую потребную перемотку ленты чем поиск копии. Особенно это касается перфоленты где запись однократна. Отсюда и все эти трюкачества с неизменяемыми данными. Они действительно были очень актуальны во времена создания ЛИСПа - тогда данные были физически однократно записываемыми. Но память давно научилась быть с многократной перезаписью и произвольным доступом.

0

Сообщение от Fulcrum_013 Можно дописать в конец за амортизированное O(1) и назвать это другим вектором.

В реализации вектора не так. Более того, в реализации вектора объект не хранит никакой информации о том, как он был создан. Никакого лога изменений не ведётся.

Пусть у нас есть вектор, содержащий 1000 элементов. Упрощённо он состоит из корня, содержащего длину вектора и ссылку на массив из 32 ссылок на массивы из 32 элементов (на самом деле вектор устроен чуть сложнее).
Если мы заменяем какой-то элемент, то нам надо заменить корень, 1 массив ссылок и 1 массив элементов. Остальные 31 массивов элементов используются в новом векторе без изменений и также продолжают использоваться в старом векторе.
Если бы мы меняли вектор, состоящий из 30_000 элементов, то нам пришлось бы заменить корень, 2 массива ссылок и 1 массив элементов. Остальные (примерно) 1000 массивов элементов и 30 массивов ссылок используются совместно старой и новой версией.

Добавлено через 19 минут

Сообщение от Fulcrum_013 Кнопка отправляет оповещение программе и вот в этом оповещение а действие производится как реакция на это оповещение.

Это всё детали реализации, не имеющие отношения к обсуждаемому вопросу. В конечном итоге есть некая функция, которая выполняет работу. Что должна делать эта функция, если пока она работает, некий используемый ею объект вдруг самоудалился?

Сообщение от Fulcrum_013 К примеру пользователь нажимает кнопку "слушать музик". Необходимо во первых проверить наличие существующей коннекции. Если ее нету создать коннекцию. На ивенте "готов к работе" пришедшем от созданной коннекции, отправить запрос, и получать опять же на ивенте от коннекции входящий поток. При обрыве связи получить от коннекции соответсвующий ивент и попытаться пересоздать поток.

И в какой момент тут требуются самоудаляющиеся объекты?

Добавлено через 13 минут

Сообщение от Fulcrum_013 Нам бы двойку за такое определение поставили на экзамене.

Объектно-ориентированное программирование сосредоточено на проектировании, реализации и использовании иерархий классов.
Ключевое слово class в C++ предназначено также для поддержки процедурного стиля программирования.

То есть, использование class в коде не обязательно делает программу объектно-ориентированной. А Страуструп недовольно морщится, когда кто-то говорит, что С++ - это объектно-ориентированный язык программирования.

0

Сообщение от Shamil1 Это всё детали реализации, не имеющие отношения к обсуждаемому вопросу. В конечном итоге есть некая функция, которая выполняет работу. Что должна делать эта функция, если пока она работает, некий используемый ею объект вдруг самоудалился?

А в том то и дело что функции как таковой нет. Есть смена состояний и реакция на переход из состояния в состояние. Т.е. работу выполняет сеть взаимосвязанных объектов, каждый из которых принимает решения в рамках известных ему данных а не прцедуры/функции.

Добавлено через 1 минуту

Сообщение от Shamil1 В реализации вектора не так. Более того, в реализации вектора объект не хранит никакой информации о том, как он был создан. Никакого лога изменений не ведётся.

Ну это сегментированный (кластеризированный) массив. И это оптимизация копирования а не что либо другое. Кстати именно для этой оптимизации и потребовалось изобрести перфокарту.

Добавлено через 3 минуты

Сообщение от Shamil1 И в какой момент тут требуются самоудаляющиеся объекты?

Коннекция оборвалась самоудалилась оповестила плейер что приплыли суши весла удаляй буфер. По ходу может и кнопки оповестить чтобы стоп дезактивировался а плей активировался. По ходу фактически подвязываем UI на фактическое состояние коннекции, а плейер выполняет действия аки реакцию на смену состояний коннекции и поступление от нее данных.

Добавлено через 3 минуты

Сообщение от Shamil1 Что должна делать эта функция, если пока она работает, некий используемый ею объект вдруг самоудалился?

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

Добавлено через 10 минут
Shamil1, При этом еще раз для тех кто в ФП/процедурщине - объект это не пассивный буфер а активная абстрактная сущность и с чем ее есть ни одна функция точно не знает. Знает только он сам. А соответсвенно работа функций сводится к отдаче списку объектов команды делай раз. Если кто то по ходу из списка исчезнет самой функции от этого не холодно не жарко. Так же как и другой функции которая по другому списку командует делай два.

Добавлено через 9 минут
Shamil1, Т.е. суть как раз в том чтобы функции не требовалось заморачиваться вопросом нужен ей этот объект или нет. Вместо этого объект заморачивается о том нужна ли ему команда делай раз делай два или делай три. Т.е. в каких списках обработке ему присутствовать/в каких действиях участвовать/на какие команды реагировать. В результате получается самоуправляемая иерархия взаимосвязанных объектов.

Добавлено через 18 минут

Сообщение от Shamil1 А Страуструп недовольно морщится, когда кто-то говорит, что С++ - это объектно-ориентированный язык программирования.

Ну объектно-ориентированный на западе вызывает ассоциации с тем как принято программировать в яве (а у Страуструпа - на симуле). От такой ассоциации кто угодно поморщится. Хотя к ООП то что делают в яве относится постольку поскольку.

Добавлено через 3 минуты

Сообщение от Shamil1 То есть, использование class в коде не обязательно делает программу объектно-ориентированной.

Так же как и использование наследования. Объектно-ориентированной делает моделирование программой поведения, взаимосвязей и взаимодействия сущностей предметной области, представленных в программе объектами, выполняющими актуальные действия по оному моделированию.

0

Сообщение от Fulcrum_013 А в том то и дело что функции как таковой нет.

Если есть код, который выполняет работу, то есть и функция, которая содержит этот код.
А вся байда с состояниями и их изменением относится к интерфейсу пользователя.

Сообщение от Fulcrum_013 Ну это сегментированный (кластеризированный) массив. И это оптимизация копирования а не что либо другое.

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

Сообщение от Fulcrum_013 Коннекция оборвалась самоудалилась оповестила плейер что приплыли суши весла удаляй буфер.

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

Сообщение от Fulcrum_013 Вдруг не бывает. Либо по аппаратному прерыванию, и такие объекты по любому нужно проверять, либо в результате изменения его состояния явно или косвенно иницированным самой этой функцией.

Вдруг - бывает. Всё проверять - бессмысленно.
Например, я выполняю запросы к БД, используя Соединение. Зачем мне перед каждым запросом делать кучу проверок? Если Соединение придёт в негодное состояние, то я получу Исключение - и это то, что надо (потому что я не знаю, как это исключение обрабатывать).

Сообщение от Fulcrum_013 В результате получается самоуправляемая иерархия взаимосвязанных объектов.

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

Сообщение от Fulcrum_013 Ну объектно-ориентированный на западе вызывает ассоциации с тем как принято программировать в яве (а у Страуструпа - на симуле). От такой ассоциации кто угодно поморщится.

Страуструп морщится по другой причине. Он создавал С++ не для того, чтобы на нём писали в ООП стиле. По его мнению для того, чтобы код был выразительным и эффективным, нужно использовать комбинацию стилей, а не какой-то один.

Сообщение от Fulcrum_013 А соответсвенно работа функций сводится к отдаче списку объектов команды делай раз.

И для исполнения команд объект вызывает функции. Любой метод является функцией.

0

Сообщение от Shamil1 Страуструп морщится по другой причине. Он создавал С++ не для того, чтобы на нём писали в ООП стиле. По его мнению для того, чтобы код был выразительным и эффективным, нужно использовать комбинацию стилей, а не какой-то один.

Ну скажем я не знаю что там остальное стили или не стили а ООП это методология проектирования а смесь методологий до добра как известно еще никогда не доводила. При этом по поводу лямбд и соответсвенно ФП в рантайме Страуструп тоже очень скептически настроен.
компайлтаймовый же ФП/декларативный подход шаблонов - ну это реально моща, которая сводит практически к нулю код обслуживания мелких нужд ООП, типа автоматики слежения за взаимосвязями и т.д. Поэтому называть С++ ООП языком - ну это все равно что сказать что других ООП языков не существует. А это не так потому что в той же дельфе яве шарпе реализована полная симуловская модель объектов, хотя и нет средств автоматики взаимосвязей.

Сообщение от Shamil1 И для исполнения команд объект вызывает функции. Любой метод является функцией.

И любая функция либо пинает те взаимосвязи которые существуют либо что то там себе тихонечко пересчитывает не трогая окружающих либо устанавливает взаимосвязь/создает объекты. Временные объекты живущие в пределах одного метода при этом нонсенс. Имеются в виду объекты в понимании ООП а не пассивные буфера для временных данных типа строк и т.д. Т.е. нужность если и есть то объекта объекту а не функции функции. Т.е. объекту нужен хозяин чтобы не быть удаленным но не объект хозяину.

Добавлено через 1 час 15 минут

Сообщение от Shamil1 По описанию похоже на глючную систему, которую практически невозможно отладить.

По описанию похоже на то что под капотом к примеру у VCL WinForms и еще много много чего. А отладки как таковой практически нет при грамотном проектировании. Все решается за счет четкости распределения зон ответственности между объектами и сокрытии механизмов взаимодействия/установки разрыва взаимосвязей на уровне абстрактных предков. А при наличии плюсовой автоматики которая позволяет управление взаимосвязями сделать полностью декларативным - отлаживай математику и вообще не парься о работе взаимосвязей.

Добавлено через 3 минуты

Сообщение от Shamil1 Если Соединение придёт в негодное состояние,

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

Добавлено через 10 минут

Сообщение от Shamil1 Вдруг - бывает. Всё проверять - бессмысленно.

Вдруг бывает только по манавению аппаратных прерываний. И оно в любом случае вдруг. А все остальное так или иначе иницируется самим методом.

Добавлено через 2 минуты

Сообщение от Shamil1 И что будет, если она самоудалится в тот момент, когда плеер будет работать?

Выключится плеер по оповещению. Кнопка старт активируетс кнопка стоп деактивируется тоже по оповещению. Он все равно не может работать с мертвой коннекцией. А так это все разруливается в практически 100% декларативной форме.

Добавлено через 17 минут

Сообщение от Shamil1 Нет. Это не оптимизация чего-либо, а некая структура данных, обладающая желаемыми свойствами.

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

Добавлено через 5 минут
Кстати так думал о применении подобной структуры для замены COW строк/стринглистов для ускорения копирования. При неравенстве длин и необходимости в подстроках получается полный 3,14здец, когда строка в 2 байта может держать мегабайтный текст используя из него 1 байт.

0

Сообщение от Fulcrum_013 Ну скажем я не знаю что там остальное стили или не стили а ООП это методология проектирования а смесь методологий до добра как известно еще никогда не доводила.

Почитайте Страуструпа. И он, кстати, настаивает на "смешивании" (синтезе) разных методологий проектирования. А ещё он настаивает на том, что на разных языках нужно по разному писать в ООП стиле.

Сообщение от Fulcrum_013 Выключится плеер по оповещению. Кнопка старт активируетс кнопка стоп деактивируется тоже по оповещению.

Опять Вы про интерфейс пользователя. Это же скучно.
Во-первых, ИП - это меньшая и наиболее простая часть любой системы. На разработку экселя ушли, наверное, тысячи человеко-лет. А написать ИП к нему один человек может за несколько месяцев.
Во-вторых, все ИП более-менее похожи друг на друга. Что эксель, что какая-нибудь система учёта - те же окошки, те же кнопки.
В-третьих, ИП бывают разные и не все содержат кнопки. В том же экселе можно работать через веб или с командной строки или через апи.

Сообщение от Fulcrum_013 Это оптимизация копирования.

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

Сообщение от Fulcrum_013 Кстати так думал о применении подобной структуры для замены COW строк/стринглистов для ускорения копирования. При неравенстве длин и необходимости в подстроках получается полный 3,14здец, когда строка в 2 байта может держать мегабайтный текст используя из него 1 байт.

Ваше неудачное сравнение подтверждает, что Вы не поняли даже как устроен вектор. Могу привести пример попроще. Для добавление элемента в голову связанного списка достаточно создать пару "элемент, ссылка на хвост". Если список иммутабельный, то, добавив к нему 10 разных элементов, я получу 10 разных новых списков, и все они будут ссылаться на один и тот же хвост. И это не оптимизация чего-то, а одно из свойств этой структуры данных.

0

Сообщение от Shamil1 Для добавление элемента в голову связанного списка достаточно создать пару "элемент, ссылка на хвост". Если список иммутабельный, то, добавив к нему 10 разных элементов, я получу 10 разных новых списков, и все они будут ссылаться на один и тот же хвост.

Ну вот так получается лог изменений а не копия. при этом голова/хвост тут значения не имеет.

Добавлено через 58 секунд

Сообщение от Shamil1 90% решения большинства расчётных задач заключается в выборе подходящих структур данных.

Есть такое дело. И для 99% задач иммутабельные структуры не пригодны от слова совсем. Но с тем то есть задачи архивирования и т.д. где иммутабельность данных суть задачи тоже никто как бы не спорит.

Добавлено через 42 секунды

Сообщение от Shamil1 Опять Вы про интерфейс пользователя. Это же скучно.

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

Добавлено через 16 минут

Сообщение от Shamil1 На разработку экселя ушли, наверное, тысячи человеко-лет. А написать ИП к нему один человек может за несколько месяцев.

И чем он принципиально отличается от электронных таблиц досовской эпохи типа SuperCalc? Только UI и возможностью раскрашивания табличек.

0

Сообщение от Fulcrum_013 Ну вот так получается лог изменений а не копия

Если бы это был лог изменений, то, заглянув внутрь вектора, можно было бы понять, какой элемент изменился последним. Что это за "лог изменений" такой, если он не содержит никакой информации об изменениях?

Сообщение от Fulcrum_013 И для 99% задач иммутабельные структуры не пригодны от слова совсем.

Не нравятся иммутабельные структуры? Вы просто не умеете их готовить.

Сообщение от Fulcrum_013 Я про завязку внутренностей системы на интерфейс.

Завязка зависит от интерфейса. И от его удалённости от "внутренностей системы".
Для командной строки и АПИ нет никакого состояния, поэтому нечего активировать/деактивировать.
Для веб-интерфейса, если он написан без javascript, тоже нет никакого состояния. А если он написан с использованием javascript, то состояние есть в javascript, а на сервере всё равно нет состояния.
Состояние есть у дестокпных приложений. Когда я последний раз писал десктопное приложение, я все заявки задал декларативно в хамле (код соответствующих классов был пустым)

0

Сообщение от Shamil1 Когда я последний раз писал десктопное приложение, я все заявки задал декларативно в хамле (код соответствующих классов был пустым)

ну вот для того чтобы это декларативно работало и должна быть такая самоуправляемая иерархия взаимосвязанных объектов. Декларативно вы можете только взаимосвязи/настройки уже существующих компонентов указывать и не более того. Т.е. только финальную сборку.
И если для UI и особенно CURD учетной направленности такие наборы компонент для декларативного конструирования имеют высокую степень универсальности, и соответственно развиты настолько что код нужен очень редко, то для остальных 75% задач индустрии это далеко не так.

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

Добавлено через 7 минут
Работоспособность того же HTML к примеру обеспечивает подобная самоуправляемая иерархия объектов. А сам HTML - это по сути схема сборки иерархии - т.е. список компонентов с их настройками и взаимосвязями.

Добавлено через 5 часов 28 минут

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

Это не лог измений вектора. Это лог изменений какого то состояния хранимый в этом векторе. Вообще такая структура пользовалась для эмуляции стека для памяти с физически однократной записью. При перезаписываемой же памяти ее актуальность равна нулюб так как после подъема по стеку при последующем спуске можно переписывать высвободившиеся при прдьеме элементы. При этом отпадает и необходимость в компрессии стека (длина то ленты имеет физические ограничения), которая по сути была предшественником GC.

0

Сообщение от Fulcrum_013 И для 99% задач иммутабельные структуры не пригодны от слова совсем.

Да ладно. И это число, конечно же, взято от балды как и все остальные ваши заявления?

0

Типы int, double и complex являются примерами иммутабельных структур в С++.


Есть переменные и есть значения переменных. Если значение нельзя изменить, а только заменить целиком, то тип является иммутабельным.

0

Сообщение от Shamil1 Типы int, double и

Прекрасно меняются по частям при помощи побитовых операторов юнионов и т.д. При этом операция к примеру ++ заменяет инт или изменяет?

0