У меня перестала запускаться моя программа, и я ищу ошибки в старом дерьмокоде, написанном 20 лет назад. Видно что общей ошибкой было частое использование указателей и всяких new, dispose, getmem, freemem, вместо использования классов. Другая ошибка заключалась в том, что вместо assign-ов использовалось копирование указателей на сложные структуры. Предположим, у вас есть сложный иерархический массив с разными вложенными элементами, а в другой модуле сопряжённый с ним другой массив (например первый массив хранит данные для логики программы, а второй для их визуального отображения на формах). Так вот надо при присвоении вторым массивом первого прописывать процедуру assign, а у меня раньше могло быть копирование указателей на структуру (тогда, если сделать присвоение а потом первый массив очистить, то второй перестанет нормально работать).
Мне показалось, у многих Delphi-программистов встречается ещё большая дичь – обычное присвоение для переменных с типом стандартные динамические массивы. Вот тут показано к чему это может привести:

	Скрытый текст
	program test; var x, y: array of integer; procedure show(a: array of integer; n: string); var i: Integer; begin write(n, ':'); for i := Low(a) to High(a) do write(' ', a[i]); writeln; end; begin SetLength(x, 3); x[0] := 1; x[1] := 2; x[2] := 3; y := x; show(x, 'x в начале'); show(y, 'y в начале нацелено на x'); y[2] := 10; show(x, 'поэтому изменение y изменяет и x'); SetLength(x, 4); x[2] := 20; x[3] := 30; show(x, 'x теперь другой массив'); show(y, 'y от него уже отцепился'); end.

Не знаю, есть ли похожие штуки в C.
Данные переменной длины обычно лучше хранить в виде классов. Если к классу добавляется новое поле переменной длины (класс, динамический массив, строка), надо поправить код в трёх местах: инициализация в конструкторе, освобождение в деструкторе и ассигн в ассигне. Для простых данных можно использовать рекорды (кажется в C они называются статическими классами), у них преимущества два – скорость и не нужно каждый раз вызывать конструктор/деструктор.
Как я уже написал, обычно надо прописывать ассигны для присвоений сложных переменных. Но если важна скорость, может всё-таки лучше быть не полное присвоение, а копирование указателя. У меня есть такой случай. Нужно нарисовать молекулу в виде множества сфер (атомов). Чтобы рисовалось быстрее, имеет смысл для каждого атома нарисовать его картинку заранее, и потом копировать нарисованное на экран. При этом обычно все атомы одинаковы, поэтому для всех, например, атомов углерода достаточно нарисовать одну картинку. С другой стороны, иногда атомы могут содержать трехмерные надписи, и тогда необходимо для каждого атома в молекуле нарисовать отдельную картинку. Ассигнить эти картинки неправильно, потому что в молекуле может быть тысяча атомов одинакового типа, тут надо не ассигнить а нарисовать один раз и присваивать указатели. Но нужно тщательно следить за ошибками, чтобы не начать рисовать на невыделенной памяти, и освобождать вовремя память, чтобы не было утечек. Подскажите, для этого годятся умные указатели? Напомните, что это такое.

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

K> Мне показалось, у многих Delphi-программистов встречается ещё большая дичь – обычное присвоение для переменных с типом стандартные динамические массивы. Вот тут показано к чему это может привести:

Клево доку не читать — каждый день открытия!

K>Другая ошибка заключалась в том, что вместо assign-ов использовалось копирование указателей на сложные структуры. Предположим, у вас есть сложный иерархический массив с разными вложенными элементами, а в другой модуле сопряжённый с ним другой массив (например первый массив хранит данные для логики программы, а второй для их визуального отображения на формах). Так вот надо при присвоении вторым массивом первого прописывать процедуру assign, а у меня раньше могло быть копирование указателей на структуру (тогда, если сделать присвоение а потом первый массив очистить, то второй перестанет нормально работать).

Приведите пример верного и неверного кода, пжл.

P.S. Ваш вопрос про умные указатели теряется среди рассуждений про атомы и молекулы.

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

K>У меня перестала запускаться моя программа, и я ищу ошибки в старом дерьмокоде, написанном 20 лет назад.


Выкини это гавно

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

R>Клево доку не читать — каждый день открытия!

Ты чё? Все доки оплачены рептилоидами! Как им можно доверять?

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

M>Приведите пример верного и неверного кода, пжл.

По-моему удобнее словами это объяснять, ну ладно:

	Скрытый текст
	Type TFragmentAtomInfo=record typ:tatomtype; pos:tvect; end; TFragmentBondInfo=record typ:tbondtype; atom1,atom2:integer; end; TFragmentData=record FirstBondType:tbondtypenum; atoms:array of TFragmentAtomInfo; bonds:array of TFragmentBondInfo; procedure Clear; end; PFragmentData=^tfragmentdata; TFragmentNode=class private function GetSubItem(index:integer):tfragmentnode; public fWithData:boolean; fname:string; fdata:pfragmentdata; fsubitems:tlist;//В каждом - другой tfragmentnode … procedure Tfrageditform.MakeTree(withfirst: boolean); function MakeItem(show:boolean; parentnode:ttreenode; fragnode:tfragmentnode):ttreenode; var q:integer; begin siStringToString(fragnode.fname)) if show then result:=fragmentstree.Items.AddChild(parentnode,fragnode.fname) else begin result:=nil; {exit;} end; if fragnode.fWithData then begin result.Data:=fragnode.fdata;//Это неправильно result.ImageIndex:=0; result.SelectedIndex:=0; end else begin for q:=0 to fragnode.SubItemsCount-1 do makeitem(true,result,fragnode.SubItems[q]); if assigned(result) then begin result.ImageIndex:=1; result.SelectedIndex:=1; end; end; end; begin fragmentstree.Items.Clear; ffirstnode:=makeitem(withfirst,nil,fragments); if withfirst then ffirstnode.Expand(false); end;

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


M>P.S. Ваш вопрос про умные указатели теряется среди рассуждений про атомы и молекулы.

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

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

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

K>> Мне показалось, у многих Delphi-программистов встречается ещё большая дичь – обычное присвоение для переменных с типом стандартные динамические массивы. Вот тут показано к чему это может привести:

R>Клево доку не читать — каждый день открытия!

Зашибись ссылаться на документацию, но в книжках по Delphi я не встречал подробного разбора вопроса, который тут ставится.
Максимум что написано — одной фразой , что динамический массив передается по ссылке.
Что понятно только достаточно опытному программисту, а новичок нужных выводов о поведении копии не сделает.
Все это нарабытывается только годами и шишками.
Также понятие о том сто такое deepcopy в delphi отсутствует.
Если бы было, можно было бы раздумывать, в чем же разница.
Ну и дальше тонкости — например чтобы "отцепить" копию от оригинала, можно вызвать SetLength.

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

K>>У меня перестала запускаться моя программа, и я ищу ошибки в старом дерьмокоде, написанном 20 лет назад.

П>Выкини это гавно

Эх, парень!
Мне приходилось сопровождать код, в котором встречались строки типа:
# ifdef VAX_VMS

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

K>Данные переменной длины обычно лучше хранить в виде классов. Если к классу добавляется новое поле переменной длины (класс, динамический массив, строка), надо поправить код в трёх местах: инициализация в конструкторе, освобождение в деструкторе и ассигн в ассигне. Для простых данных можно использовать рекорды (кажется в C они называются статическими классами), у них преимущества два – скорость и не нужно каждый раз вызывать конструктор/деструктор.
K>Как я уже написал, обычно надо прописывать ассигны для присвоений сложных переменных. Но если важна скорость, может всё-таки лучше быть не полное присвоение, а копирование указателя. У меня есть такой случай. Нужно нарисовать молекулу в виде множества сфер (атомов). Чтобы рисовалось быстрее, имеет смысл для каждого атома нарисовать его картинку заранее, и потом копировать нарисованное на экран. При этом обычно все атомы одинаковы, поэтому для всех, например, атомов углерода достаточно нарисовать одну картинку. С другой стороны, иногда атомы могут содержать трехмерные надписи, и тогда необходимо для каждого атома в молекуле нарисовать отдельную картинку. Ассигнить эти картинки неправильно, потому что в молекуле может быть тысяча атомов одинакового типа, тут надо не ассигнить а нарисовать один раз и присваивать указатели. Но нужно тщательно следить за ошибками, чтобы не начать рисовать на невыделенной памяти, и освобождать вовремя память, чтобы не было утечек. Подскажите, для этого годятся умные указатели? Напомните, что это такое.

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

Умные указатели к этой задаче отношения не имеют.

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

K>У меня перестала запускаться моя программа, и я ищу ошибки в старом дерьмокоде, написанном 20 лет назад. Видно что общей ошибкой было частое использование указателей и всяких new, dispose, getmem, freemem, вместо использования классов. Другая ошибка заключалась в том, что вместо assign-ов использовалось копирование указателей на сложные структуры. Предположим, у вас есть сложный иерархический массив с разными вложенными элементами, а в другой модуле сопряжённый с ним другой массив (например первый массив хранит данные для логики программы, а второй для их визуального отображения на формах). Так вот надо при присвоении вторым массивом первого прописывать процедуру assign, а у меня раньше могло быть копирование указателей на структуру (тогда, если сделать присвоение а потом первый массив очистить, то второй перестанет нормально работать).

Ну, вообще-то у тебя "большие и сложные данные" (не массивы, а данные!!!).
Чтобы держать всё это в голове, я рекомендую создать одну большую структуру "все данные", где хранить всё.
Только эта структура (класс) может создавать, хранить и удалять данные, все остальные — не могут.

А все остальные структуры данных работают с этой структурой в режиме "только чтение".
И вот они содержат ссылки на структуру "Все данные", но никогда не могут ни удалить, ни изменить что-то.
Таким образом ты можешь избавиться от дублирования данных.

Но в такой системе при изменении структуры "все данные" ссылки могут потерять актуальность и привести к SegFault.
Поэтому я храню не ссылки, а индексы в массиве. Индекс можно хотя бы проверить перед использованием.

В идеале у тебя не должно быть никаких данных кроме объекта "все данные".
Этот обьект сам отвечает за свою консистентность.
И любой объект в твоей программе — это просто часть объекта "все данные".
Кроме этого Объекта в программе могут быть только индексы и итераторы.

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

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

Твои проблемы.

s> Максимум что написано — одной фразой , что динамический массив передается по ссылке.
s> Что понятно только достаточно опытному программисту, а новичок нужных выводов о поведении копии не сделает.

В книге Delphi 4 (издательство Питер, серия "Для профессионалов"), от Марко Кэнту, страница 82. Динамические массивы. Все это описано. Простым и понятным языком. Читай правильные книжки, кто тебе доктор?

s> Ну и дальше тонкости — например чтобы "отцепить" копию от оригинала, можно вызвать SetLength.

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

...
r> В книге Delphi 4 (издательство Питер, серия "Для профессионалов"), от Марко Кэнту, страница 82. Динамические массивы. Все это описано. Простым и понятным языком.

Заглянул еще в книгу Borland Delphi 4. Руководство разработчика. Стив Тейксейра и Ксавье Пачеко. Издательство Вильямс. И там тоже все это есть (стр. 55).

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

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

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

R>Твои проблемы.

s>> Максимум что написано — одной фразой , что динамический массив передается по ссылке.
s>> Что понятно только достаточно опытному программисту, а новичок нужных выводов о поведении копии не сделает.

Скриншот что ли приложи. А то меня теперь тоже выставляют дураком за то у меня нет конкретного издания книжки.
Ксавье пачеко у меня были от 2 или 3 Delphi.

R>В книге Delphi 4 (издательство Питер, серия "Для профессионалов"), от Марко Кэнту, страница 82. Динамические массивы. Все это описано. Простым и понятным языком. Читай правильные книжки, кто тебе доктор?

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

s>> Ну и дальше тонкости — например чтобы "отцепить" копию от оригинала, можно вызвать SetLength.

R>Чтобы отцепить копию от оригинала нужно вызывать Copy. Это правильно с точки зрения семантики.

ВОт есть у тебя многоярусная структура где динамический массив внутри рекорда, там внутри опять рекорды, в рекордах опять динамические массивы и т.п.
Copy сделает полную копию всех данных? Сдается мне что только первый уровень скопирует, а внизу ссылки на те же структуры останутся.

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

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

K>>У меня перестала запускаться моя программа, и я ищу ошибки в старом дерьмокоде, написанном 20 лет назад. Видно что общей ошибкой было частое использование указателей и всяких new, dispose, getmem, freemem, вместо использования классов. Другая ошибка заключалась в том, что вместо assign-ов использовалось копирование указателей на сложные структуры. Предположим, у вас есть сложный иерархический массив с разными вложенными элементами, а в другой модуле сопряжённый с ним другой массив (например первый массив хранит данные для логики программы, а второй для их визуального отображения на формах). Так вот надо при присвоении вторым массивом первого прописывать процедуру assign, а у меня раньше могло быть копирование указателей на структуру (тогда, если сделать присвоение а потом первый массив очистить, то второй перестанет нормально работать).

A>Ну, вообще-то у тебя "большие и сложные данные" (не массивы, а данные!!!).
A>Чтобы держать всё это в голове, я рекомендую создать одну большую структуру "все данные", где хранить всё.
A>Только эта структура (класс) может создавать, хранить и удалять данные, все остальные — не могут.

A>А все остальные структуры данных работают с этой структурой в режиме "только чтение".
A>И вот они содержат ссылки на структуру "Все данные", но никогда не могут ни удалить, ни изменить что-то.
A>Таким образом ты можешь избавиться от дублирования данных.

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

A>Но в такой системе при изменении структуры "все данные" ссылки могут потерять актуальность и привести к SegFault.
A>Поэтому я храню не ссылки, а индексы в массиве. Индекс можно хотя бы проверить перед использованием.

Для исключения ссылок на сдестроенные объекты я регистрирую объекты в коллекции TDictionary<int64, TObject>
Объяетам назначаются идентификаторы int64, при создание объекта он регистрирует себя в коллекции, при дестрое удаляется оттуда.
в ссылках между объектами хранятся не указатели, а эти идентификаторы.
Массив не годится там где объекты постоянно создаются — удаляются

A>В идеале у тебя не должно быть никаких данных кроме объекта "все данные".
A>Этот обьект сам отвечает за свою консистентность.
A>И любой объект в твоей программе — это просто часть объекта "все данные".
A>Кроме этого Объекта в программе могут быть только индексы и итераторы.

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

S>ВОт есть у тебя многоярусная структура где динамический массив внутри рекорда, там внутри опять рекорды, в рекордах опять динамические массивы и т.п.
S>Copy сделает полную копию всех данных? Сдается мне что только первый уровень скопирует, а внизу ссылки на те же структуры останутся.

Вот-вот, а ещё кроме рекордов могут быть классы. Тут ассигны и только ассигны.

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

s> Скриншот что ли приложи. А то меня теперь тоже выставляют дураком за то у меня нет конкретного издания книжки.

А у меня нет желания "скриншотить" страницы бумажной книги.

s> Ксавье пачеко у меня были от 2 или 3 Delphi.

Отлично. Только динамические массивы появились в Delphi 4. Вот ссылка на Пачеко. Переходишь на 95 страницу и читаешь.

s> R>В книге Delphi 4 (издательство Питер, серия "Для профессионалов"), от Марко Кэнту, страница 82. Динамические массивы. Все это описано. Простым и понятным языком. Читай правильные книжки, кто тебе доктор?

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

Русское издание вышло в 99, оригинал (Mastering Delphi 4) в 98, как и сама Delphi 4 (в которой дин. массивы только и появились). Круто, когда знаешь о "подобных вещах". Еще до их появления.

s> R>Чтобы отцепить копию от оригинала нужно вызывать Copy. Это правильно с точки зрения семантики.

s> ВОт есть у тебя многоярусная структура где динамический массив внутри рекорда, там внутри опять рекорды, в рекордах опять динамические массивы и т.п.
s> Copy сделает полную копию всех данных?

Нет, Copy не сделает полную копию всех данных. Copy сделает говнокод чуточку более читаемым.

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

(уйма текста, попробую догадаться о сути вопроса и ответить наобум!)

1) Общие ресурсы и разделяемое владение (одна и та же картинка) — это предмет для умных указателей.
В языках без управляемой памяти (всяких там явы/шарпа/питона... где все указатели уже умные) это делается, например, подсчётом ссылок.
Т.е. у объекта (картинки) есть счётчик владельцев. Он может быть интрузивным — принадлежать непосредственно объекту, а может быть оторванным, лежать рядом с объектом (и объект про него не знает — зато знают указатели).
В C++ это делается на std::shared_ptr, а в дельфи, видимо, придётся колхозить. Пусть лучше об этом дельфеводы расскажут, я не в курсе свежих фич.

2) Уникальность по необходимости (некоторые картинки имеют доп.текст)
Делается двумя способами
— каскад свойств
— copy on write

Каскад свойств — это когда объект не монолитный, а как бы состоит из слоёв. И при обращении к какому-то свойству (например, извлечь картинку) оно собирается из этих слоёв (например, есть слой общей картинки атома, слой выведенного текста и т.п.)
Каждый слой, естественно, может быть объектом с разделяемым владением.

Copy on write — это когда ты хочешь изменить объект только у себя, не затрагивая всех остальных владельцев (дорисовать к своей картинке текст).
И вот тут подсчёт ссылок решает!
Если счётчик = 1, то ты — монополист, делаешь что хочешь.
Если > 1, то сперва копируешь объект к себе, забываешь старый экземпляр (естественно, с уменьшением счётчика у того экземпляра), вуаля, у твоего нового объекта счётчик 1, свели задачу к предыдущей.

Естественно, с иерерхически устроенными объектами, с теми же каскадами свойств, это работает точно так же.
Захотел поменять — удостоверился, что твой объект монопольно владеет под-объектом (если нет, то попытался клонировать под-объект и изменить основной объект, а для этого убедился, что ты монопольно владеешь основным объектом...)
Ну в общем, понятно.

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

К>1) Общие ресурсы и разделяемое владение (одна и та же картинка) — это предмет для умных указателей.
К>В языках без управляемой памяти (всяких там явы/шарпа/питона... где все указатели уже умные) это делается, например, подсчётом ссылок.
К>Т.е. у объекта (картинки) есть счётчик владельцев. Он может быть интрузивным — принадлежать непосредственно объекту, а может быть оторванным, лежать рядом с объектом (и объект про него не знает — зато знают указатели).
К>В C++ это делается на std::shared_ptr, а в дельфи, видимо, придётся колхозить. Пусть лучше об этом дельфеводы расскажут, я не в курсе свежих фич.

С умными указателями я ещё не освоился. Колхозить мне проще, чем изучать чьи-то готовые решения.
Повторяю вопрос который неявно сформулировал: правильно ли я понимаю, что основная цель умных указателей — экономия ресурсов? Т.е. если ресурсов хватает, можно всё просто копировать.

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

K> Повторяю вопрос который неявно сформулировал: правильно ли я понимаю, что основная цель умных указателей — экономия ресурсов?

Ты принципиально ничего не читаешь, или как?

Умные указатели:

Как правило, основной целью задействования умных указателей является инкапсуляция работы с динамической памятью таким образом, чтобы свойства и поведение умных указателей имитировали свойства и поведение обычных указателей. При этом на них возлагается обязанность своевременного и аккуратного высвобождения выделенных ресурсов, что упрощает разработку кода и процесс отладки, исключая утечки памяти и возникновение висячих ссылок[2].

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

K>> Повторяю вопрос который неявно сформулировал: правильно ли я понимаю, что основная цель умных указателей — экономия ресурсов?

R>Ты принципиально ничего не читаешь, или как?

R>Умные указатели:
R>

Как правило, основной целью задействования умных указателей является инкапсуляция работы с динамической памятью таким образом, чтобы свойства и поведение умных указателей имитировали свойства и поведение обычных указателей. При этом на них возлагается обязанность своевременного и аккуратного высвобождения выделенных ресурсов, что упрощает разработку кода и процесс отладки, исключая утечки памяти и возникновение висячих ссылок[2].

Утечки памяти — это понятно. Сейчас я отловил все утечки в своей программе, работаю с включенным ReportMemoryLeaksOnShutdown, поэтому такой проблему у меня нет. А что такое висячие ссылки?