Выделить память под структуру (указатели)

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

Код (Text):

1. type
2.  PMyCoord = ^TMyCoord;
3.  TMyCoord = record
4.   x, y: integer;
5.  end;
6.  
7.  TMas = array of PMyCoord;
8.  PMas = ^TMas;
9.  
10. procedure InitArray;
11. var
12.  mas:pmas;
13. begin
14.  mas := pointer(GlobalAlloc(GPTR,(5 * sizeof(TMyCoord) * sizeof(TMas))));
15.  mas^[0]^.x := 123; // <----  здесь exception
16. end;

 

подвязывай с делфимя ;3

 

а по моему так mas[0].x:=123;

 

но мне кажется вам это мало поможет. ибо указатель mas[0] никуда не ведет

 

ты прав.

 

разобрался)

 

ptr
кстати. а ничего, что 5*4*8=160. не многовато ли. мне казалось надо всего лишь 60.

 

а еще лучше - 20.

 

ибо если возникают такие вопросы, то с 60 не разберется

 

n0name
Если выделит 20, то еще надо будет 5 раз по 8 выделять. Те же 60, но порезанные.

 

если человек плохо представляет себе устройство указателей, то нагляднее это выделение 5 раз по 8.

 

ptr
"array of что-то" -- это так называемый динамический массив, с ним надо работать абсолютно не так, как с обычными динамическими переменными, а примерно так:

Код (Text):

1. var
2.   A : array of Integer;
3.  
4. begin
5.   SetLength(A, 10);   // Устанавливаем размерность массива A: он будет содержать 10 элементов
6.   A[0]:= 10;
7.   A[1]:= 20;
8. .....
9.   A[9]:= 9999;
10. end;

В любой момент можно с помощью SetLength изменить длину массива. Если в нём больше элементов, чем надо, лишние будут "убиты". Если элементы -- указатели (ну или сложные типы данных, включающие в себя указатели) на что-то, надо обеспечить предварительное освобождение памяти, занимаемой объектами, на которые указывают эти уничтожаемые указатели. Если же элементы не являются указателями, никаких особых действий предпринимать не требуется.

 

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

 

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

 

Ах да, GlobalAlloc возвращает даже не указатель, а хэндл, к которому нужно ещё приложить GlobalLock, чтобы это стало похоже на указатель. И вроде бы эти функции последним декретом от Микрософта объявлены вселенским злом и исчадием ада и не рекомендованы к использованию.

 

SII
array of что-то это просто [size][element]...[element] причем адресация ведется с первого элемента, а size проверяется только если установлен контроль за переполнением.

 

Rockphorr

Если хочет забанить за обсуждение работы с динамическими переменными в Дельфях -- пускай банит, его право. Ну а неприятность эту мы переживём.

CyberManiac

Насчёт моветона не соглашусь: немало задач, где именно указатели и нужны. Более того, лично меня раздражает, что технически переменные-классы являются на самом деле указателями, а не экземплярами классов -- я б предпочёл, чтобы указатели и структуры, на которые они указывают, всё ж не смешивались (т.е. чтобы была возможность создавать статические экземпляры классов, а не только чисто динамические).

Ну а в смысле GetMem и GlobalAlloc Вы абсолютно правы. Вызывать функции АПИ надо в весьма специфических случаях и очень хорошо понимая, что ты делаешь. В общем, код от ptr некорректен сразу с нескольких точек зрения.

 

max7C4

"array of что-то" -- это не просто то, что Вы указали, а именно динамический массив, память под который распределяется процедурами дельфозной RTL. Адресация элементов динамического массива ведётся с элемента с нулевым индексом. Поле длины в явном виде недоступно, хотя проверка, естественно, выполняется только в том случае, если включен контроль диапазона (а не переполнения -- range check и overflow check являются разными вещами).

 

SII

Ага. В частности - все, где используется WinAPI или где приходится разбирать двоичные данные из буфера. Хотя в последние годы даже буфер у меня всё чаще становится типа AnsiString Видимо, потому что в нём поиск при помощи PosEx хорошо работает. И ещё в одном очень специальном случае, когда я из-за своих домашних тараканов не захотел подключать модуль Classes и иже с ним. Но в более традиционных задачах я практически везде позаменял указатели либо на динамические массивы, либо на TList с сородичами. А в Delphi 2009 ещё и женерики добавили. Я их ни в один серьёзный проект пока напихать не успел, но уже чувствую, что обязательно это сделаю.

Да может оно и к лучшему, что такое всё-таки не реализовали. Единственная прямая выгода, которую я от этого вижу - возможность инициализировать внутренности статического экземпляра класс некими нетривиальными значениями в момент его объявления.

 

CyberManiac

В 2009-м с генериками есть глюк в компиляторе, из-за чего мне пришлось дико извращаться. В 2010 его исправили. Сейчас у меня есть несколько собственных генериков -- упрощённых версий контейнеров из C++ STL. Собсно, именно там (точней, в двоичных деревьях -- классы TMap<>, TSet<>, TMultiMap<> и TMultiSet<> -- и пришлось извращаться). Жаль, правда, что эти генерики не являются полнофункциональным аналогом шаблонов из Си++, а, вероятно, содраны с Си-шарпа (я его никак не знаю, поэтому и не уверен).

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

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