Delphi. Двухмерный массив разных типов данных. #665706

Нужно в один двухмерный массив запихнуть числа и даты. В одном измерении только числа, в другом - только даты. Можно, конечно, сделать его весь Variant, но, имхо, некошерно. Как поэлегантнее ?

Нужно в один двухмерный массив запихнуть числа и даты. В одном измерении только числа, в другом - только даты. Можно, конечно, сделать его весь Variant, но, имхо, некошерно. Как поэлегантнее ?

>>В одном измерении только числа, в другом - только даты это как?

Че там? Дата - скока байт? 8 вроде? Ну и делай Cardinal (Integer) себе на здоровье.

Пфффф. Пацаны в Дельфи в поле Tag указатель засовывали и ниче.

КтоСлужилТотПоймет.

не понял... двумерный массив - это же матрица. что значит "в одном измерении"?

{{1, 01.04.2010}, {46, 23.12.1998}, {2, 02.02.2013}}

не выпендривайся, скажи по делу

тебе предлагают преобразовать дату к числу

Делай массив типа Cardinal var data:array [1..100,1..2] of Cardinal; ИВперед.

можно структуру забабахать

и ее уже в массиво

Есть в паскале такое ключевое слово record.

автор неграмотный. объяснить чо ему надо не в состоянии. ему нужен одномерный массив из записей типа record end;

Точно, совсем вылетело!

Массив TList можно

TMyRec = record p1 : integer; p2 : double; end; TMyArray = array of TMyRec;

type X=Record   i:integer;     d:TDateTime; end; var Y:array [1..100] of X;

Или так. Полезно для освобождения от "рамок" типизации var data:array [1..100,1..2] of Cardinal; NowDate1,NowDate2:TDateTime; begin NowDate1:=Now; CopyMemory(@Data[1,1],@NowDate1,8); CopyMemory(@NowDate2,@Data[1,1],8); ShowMessage(DateTimeToStr(NowDate2));

ну я тоже это и имел ввиду :))

Всём спасибо. Воспользуюсь Record

Тупой компилятор отказался от гнусности типа Data[1,1]:=Cardinal(NowTime1);

классика, куча

В Дельфи нет вашей C++ матершины.

Какое отношение куча имеет к этой задаче?!

всё там есть

сначала подумал, в ячейках нужно хранить неизвестно что

потомя что TDate это Double

Блин, чо так воняет?!!! - заглядывая за гараж. классика, куча.

Умники, Variant просили не предлагать?

Буду краток: делфи - не нужен

Ну и? Хочу взять 8 байт и представить их как Cardinal, чебынет?

lf

стоп. Cardinal - 4 байта. Признаю вину, 1С съело мозг.

Питон круче дельфи

чем? чем делфи, да?

Где у тебя там variant? У тебя четко - одно поле числовое, второе дата. Никаких вариантов.

- а C# круче Питона!

Это точно, особенно быстродействие у него крутое.

это где? у меня указатель и признак типа

быстродействие для одинесников не важно

+ а на потери при выделении памяти в классике все забивали)

У тебя - это в условии задачи.

задача не моя...

Если ты её пытаешься решить - то уже твоя. Либо расскажи что за задачу ты решаешь в этой ветке.

Variant - частный случай объединения, которое, как мне показалось, нужно автору.

это у него лечится. могу рассказать как.

расскажи

в критических по скорости местах расставляются типы и всё собирается cython-ом в *.pyd

автору нужен record из двух полей, просто автор не владеет языком

Это у него не лечится. В принципе. Многократно обсуждалось на том-же codeforces

от надо так в 1с сделать. а то бывает надо чтобы быстро, а оно не может.

Не лечится только то, что ограничено gil. Второй вопрос: структуры в си, дающие аналогичную гибкость, будут работать с какой скоростью?

прочел, получается байт-код, но он же вроде медленнее машинного?

нет, там трансляция python - c++ - машинный код

+ type Element = record       Value:integer;       DataTime:<Тип не помню((>      end var Tabl: array of Element;

это можно делать уже сейчас

это как?

на инфостарте статью вывалю

вываливай тут

+ если это мне

в доках цитона всё описано

шо ещё за ацетон?

он же уже про 1С

так.. мою ВК скачали?

пардон для

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

Новый/старый.. Лишь бы работал. По производительности, предполагаю, не хуже чем у дельфи на llvm.

странный вопрос, я даже не знаю о ее существовании

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

-тут

Учитывая что Делфи/fpc имеет примерно такое-же быстродействие как С/С++ компиляторы, то конечно-же cython медленней.

денег нет

cython с типами - это с/с++

Код страшный, но оптимизатор должен разгрызть.

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

спасибо на добром слове, но это не ко мне, а к Ним)

Если мы пишем питонный код, но с типизацией - то это не си. И быстродействие не как у си. Если писать сишный код, то какое отношение это имеет к питону?

Ним пофиг. Надо самим что-то делать.

Согласен, но приближенно по скорости. Если очень нужно, можно прямо си и вставлять.

TRec = packed record  case Boolean of    True: ( I: Integer; );    False: ( D: Double; );  end;  IsInteger:Bool; end

- лолшто?

народ уже на мисту заходит просто клавиатуру проверить

Лол то что написано. Несмотря что некоторые не в теме, быстродействие откомпилированного gcc/fpc/delphi кода примерно одинаково по быстродействию.

- лолшто? и это самая плохая реализация компилятора C++ А теперь сравним с Visual C++. Зы. то, что 90% системного и прикладного ПО написано на C++, а не на Паскале как бэ намекает, да

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

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

меня всегда удивляла "аргументация" "любителей" паскаля. Вот ведь все вокруг меня идиоты собрались - на С++ программируют, на Паскале, который гораздо лучше и такой же по быстрдействию - никто. Миллионы мух ошибаются ведь, да.

При чем тут сервер БД? С/С++ намного более популярны, и имеют намного больше готовых библиотек. И пишется всё в основном на С/С++. Но речь то шла не о популярности, и не библиотеках, а о быстродействии. А быстродействие у них почти одинаково. Жава - да, действительно медленней. Если не учитывать совсем медленный ввод/вывод, то разница в скорости достигает 2 раз. А Паскаль - примерно так-же как и Си. Именно поэтому очень многие олимпиадные программисты писали на Паскале - скорость кода та-же, и в TL впихнуть так-же просто как и на Си. А популярность паскаля начала падать только после того как его стали убирать из списка доступных языков.

Бред не неси. Я пишу и на С/С++, и на Паскале, и на Java. Мне пофик на чем писать.

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

- на олимпиаднах используется паскаль, потому что перподы не хотят учить C/C++. Среди школоты и студентоты паскаЛь все еще популярен, пока не будет уволено старое поколение преподов. К быстродействию программ выбор ЯП на олимпиадах не имеет никакого отдношения. >При чем тут сервер БД? Потому что серверы БД - это "реальные приложения". 1С: Предприятие между прочим сам по себе тоже "реальное приложение". Но у меня такое ощущение, что у тебя под "реальностью" понимается форма с 2 EditBox-ами и 3-мя кнопками.

Какое отношение преподы имеют к спортивным программистам? Которые пишут естественно на всех языках.

Тебе объяснили почему серверы БД не пишут на паскале. Быстродействие тут не при чем.

Я работал в конторе, написавшей свою СУБД на дельфи. Со скорострельностью проблем не было.

СУБД?

- сервер баз данных. Даже Firebird, популярный среди паскалистов, написан на C++ Угадайте почему?

Свои индексы, управление памятью, и.т.д.?

По той-же причине почему мат. пакеты пишут на фортране. При чем тут быстродействие?