Delphi vs C++ , Часть 1

Цитата impik777 @ 08.04.07, 09:38

имеется транспортная сеть, состоит из узлов, узлы делятся на источники и потребители
источник маркируем числом -1 а потребитель положительным целым означающим потребность
также узлы соединяются между собой путями, каждый путь маркируется сложностью (положительным целым числом)

задача: существует понятие транспортного средства с параметром грузоподъемность
небходимо реализовать
а) быстро и интерактивное построение графа системы (число узлов 5-20000, число ветвей считайте сами )
б) расчет оптимальных путей транспортных средств(их может быть сколь угодно много) по дейкстре
для обеспечения всех потребителей

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

Цитата mo3r @ 08.04.07, 07:08

А в дельфи можно написать коллекцию, сравнимую с C++'ным map? или vector?

Вы что имеете в виду? Шаблоны? Они далеко не необходимы, а всё остальное реализуется легко.

Цитата mo3r @ 08.04.07, 07:08

Это только в простейших случаях так. Например, хэш-таблицу, AVL-дерево, кучу или другие контейнеры просто так не написать...

Возможно, я избалован Java, но что тут сложного, не пойму

Сообщение отредактировано: wind - 08.04.07, 13:46

Цитата wind @ 08.04.07, 13:35

Вы что имеете в виду? Шаблоны? Они далеко не необходимы, а всё остальное реаллизуется легко.

Да как сказать. Шаблоны позволяют делать неинтрузивные коллекции, что является большим плюсом.

Цитата Flex Ferrum @ 08.04.07, 12:29

Ну проассоциировал. А дальше что делать?

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

type
  IObjIntf = interface
    procedure DoWork1; // команда 1 в контекстном меню
    procedure DoWork2; // команда 2 в контекстном меню
    ...
  end;
 
  TSomeClass1 = class(TInterfacedObject, IObjIntf)
    ...
  end;
...

При вызове команды 1 в контекстном меню будет вызван метод DoWork1 каждого конкретного класса. То же самое для других команд.

Если объекты однородные, то можно вообще ограничиться каким-то идентификатором объекта (указателем), проассоциированым с каждым нодом.

Цитата Flex Ferrum @ 08.04.07, 13:44

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

[offtopic]А можно мне расшифровать, что значит "неинтрузивные коллекции"?[/offtopic]

Цитата Smike @ 08.04.07, 13:47

При вызове команды 1 в контекстном меню будет вызван метод DoWork1 каждого конкретного класса. То же самое для других команд.

Как будет выглядеть код метода DoWork?

Добавлено 08.04.07, 13:56

Цитата wind @ 08.04.07, 13:53

[offtopic]А можно мне расшифровать, что значит "неинтрузивные коллекции"?[/offtopic]

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

Цитата Flex Ferrum @ 08.04.07, 13:53

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

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

Цитата wind @ 08.04.07, 14:01

Но ведь и без шаблонов любые коллекции являются "неинтрузивными". Вообще, наличие/отсутствие шаблонов на это совсем не влияет. Или я упустил какой особенный тип коллекций?

Не совсем. В отсутствии шаблонов очень сложно создавать коллекции элементов примитивных типов (приходится простой тип int делать объектом) - это раз. Второе - элементы таких коллекций требуют обязательного приведения от базового интерфейса типа IObject/Object/TObject/CObject (нужное подчеркнуть), что, ИМХО, неудобно - это два.

Цитата Flex Ferrum @ 08.04.07, 14:05

В отсутствии шаблонов очень сложно создавать коллекции элементов примитивных типов (приходится простой тип int делать объектом) - это раз.

Тут да, я действительно избалован Java, в Delphi придётся извращаться.

Кстати не всегда обёрточный код, идет на пользу логики. Допустим, начиная с каких то там игровых примеров, я долго не мог 'втупить' за пресловутые COM-обьекты. Пришлось воспользоваться препроцессором, дабы обнажить суть кода, которая оказалась весьма тривиальна:

struct IDirectDraw
{
long  virtual _stdcall QueryInterface ();
long  virtual _stdcall AddRef ();
long  virtual _stdcall Release ();
    /*** IDirectDraw methods ***/
long  virtual _stdcall Compact ();
//...etc

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

TIDirectDraw = object
 
function    QueryInterface  : integer; virtual; stdcall; abstract;
function    AddRef : integer; virtual; stdcall; abstract;
function    Release : integer; virtual; stdcall; abstract;
    (*** IDirectDraw methods ***)
function    Compact: integer; virtual; stdcall; abstract;
//...etc

По мне - реализация через Object даже куда логичней, чем тот же тип Interface. Уж не буду говорить что твориться в M$-мсишных хидерах, дабы завуалировать истиную суть C++ кода.

Сообщение отредактировано: n0p - 08.04.07, 15:04

Цитата Flex Ferrum @ 08.04.07, 13:53

Как будет выглядеть код метода DoWork?

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

Цитата Flex Ferrum @ 08.04.07, 14:05

В отсутствии шаблонов очень сложно создавать коллекции элементов примитивных типов (приходится простой тип int делать объектом) - это раз. Второе - элементы таких коллекций требуют обязательного приведения от базового интерфейса типа IObject/Object/TObject/CObject (нужное подчеркнуть), что, ИМХО, неудобно - это два.

Мой коллега по дельфийскому цеху, jack128, выкладывал кажется такой универсальный класс-контейнер. Попробую поискать.

А во вторых можно при желании в Дельфи и шаблоны организовать с помощью Include-файлов. В-третьих можно использовать динамические массивы.

Цитата Smike @ 08.04.07, 16:23

А во вторых можно при желании в Дельфи и шаблоны организовать с помощью Include-файлов.

Это не совсем тоже самое, что шаблоны.

Добавлено 08.04.07, 16:39

Цитата Smike @ 08.04.07, 16:23

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

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

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

program hello; uses windows;
 
Type
    TPortL = class
        private
            function ReadPortL(index:word):integer;
            procedure WritePortL(index:word; value:integer);
        public
            property port[index:word]:integer
                            read ReadPortL write WritePortL;default;
    end;
 
function TPortL.ReadPortL(index:word):integer;//register;
asm
    in  eax,dx
end;
procedure TPortL.WritePortL(index:word; value:integer);
asm
    mov eax,ecx
    out dx,eax
end;
 
var data  : integer;  portl :TPortL;
begin
 
      data := portl[$1234];
 
      portl[$1234] := data;
 
 
end.

так что классы очень рулят. Опять же как это замечательно вписываеться в регистры!

этож.. можно и interrupt[xx] обьявить.. и memory[xxxxxxxxx] хм.. зря я недооценивал статические class'ы. Балин придеться драйвера переписывать под новый ООП концептЪ.. А там может и ось до ума доведу..

Цитата n0p @ 08.04.07, 17:28

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

Да ну что ты? Не дольше 5-10 минут. Думаю ты, как любитель низкоуровневого программирования, оценишь такой вариант:

    PortL port;
 
    port[25] << 0x01 << 0x03 << 0x05;
    int val1, val2, val3;
    port[30] >> val1 >> val2 >> val3;

С нулевыми накладными расходами.
Сам класс выглядит так:

class PortL
{
public:
    class PortAccessor
    {
        short m_Port;
    public:
        PortAccessor(short port) : m_Port(port) {;}
        PortAccessor& operator << (int val)
        {
            // Тут нужно заменить на соответствующие ассемблерные вставки
            std::cout << m_Port << " = " << val << std::endl;
            return *this;
        }
        PortAccessor& operator >> (int& val)
        {
            // Тут нужно заменить на соответствующие ассемблерные вставки
            val = m_Port;
            return *this;
        }
    };
    PortAccessor operator[] (short port)
    {
        return PortAccessor(port);
    }
};

Цитата Seri0S

как там в VC++ не знаю, но рискну предположить: extern "C"?

Цитата Flex Ferrum

А непосредственно описанная проблема решается простым extern "C". Никогда не подводило.

С __stdcall-функциями в VC++ не прокатит - декорация изменится, упростится, но всё равно останется.

Цитата Smike

Ты думаешь я о визуальных средствах? Неужели DEF-файл проще, чем:

exports
  // просто перечисляем экспортируемые функции
  MyFuntion1,
  MyFuntion2;

А чем сложнее-то? Тем, что в отдельном файле располагается?

Цитата n0p

Не удивительно что C++ текста с подобными наворотами, зачастую страдают трудноизгоняемыми глюками, а то и непереносимы - тупо заточены под конкретный компиль, а на другом могут скомпилиться но не запахать. Про #pragma's лучше вобще умолчать, и что оно делает - тайна покрытая мраком, ибо сие есть колдовское заклятие отдельно взятого компиля.

Когда Делфийных компиляторов будет хотя бы на порядок меньше, чем C++-сных - тогда и поприводи такие доводы.

Цитата mo3r

Извини, но тот, кто это делал, просто не осилил... export "C", но тогда надо забыть про перегрузку...
PS: что-то я у себя не видел ни одного DEF-файла, и даже не знаю, что это такое... Кто-нибудь скажет, что это за файлы и с чем их едят? И какое отношение они имеют к C++?

Ну, и DLL тоже не имеют отношение к C++, так ведь? Так что речь изначально не об абстракциях, а о конкретных операционках и компиляторах.

Цитата n0p

Единственый незачет (как и у С++) - использование линкера в последней стадии обработки.

Про "Link Time Code Generation" ты не слышал, я так понимаю...