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

Цитата AndNot

testp = inport(0x3f8);
outportll(0x3f8, testp | 0x80000000);

на дельфи, подобный "сишный" подход, вида /inb/inw/inl /outb/outw/outl, както порядком поднадоел. Никакого оригинального концепта. скучно, посредственно, сиро, убого. а обьектная переменная, это что-то большее. Тем более что за этим может стоять низкоуровневый функционал. За это мона простить пару и пустяков.

Цитата

Ээээээ........ в смысле?

interrupt[номер] - это был оператор в ТP7. Вот думаю его заиметь, в 32-битном варианте (в хозяйстве, все пригодиться). Думаю несложно (главное перебороть лень ).

Добавлено 10.04.07, 00:41
вотЪ..

Сообщение отредактировано: джастфорфановец - 10.04.07, 00:41

Цитата archimed7592 @ 09.04.07, 20:02

считал лучшим языком в мире... пока не подружился с ++

Для Паскаля твои слова во многом справедливы, но с Дельфи (а именно этот язык является сабжевым) ты по-видимому не знаком

Добавлено 10.04.07, 04:29

Цитата archimed7592 @ 09.04.07, 23:22

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

VCL

VCL успешно портирована на Linux в среде Kylix/FreePascal. Самым нативным образом.

Чисто для сравнения:
Исходник от Flex_Ferrum с небольшой моей модификацией

#include <conio.h>
//----------------------------------------------------------------------
class PortL {
public:
   class PortAccessor {
      short m_Port;
   public:
      PortAccessor(short port) : m_Port(port) { ; }
      PortAccessor& operator << (int val) {
          _outpd(m_Port,val);
          return *this;
      }
      PortAccessor& operator >> (int& val) {
         val = _inpd(m_Port);
         return *this;
      }
   };
   PortAccessor operator[] (short port) {
      return PortAccessor(port);
   }
};
//----------------------------------------------------------------------
int __cdecl main(int argc, char ** argv) {
   PortL port;
 
   port[25] << 0x01 << 0x03 << 0x05;
   int val1, val2, val3;
   port[30] >> val1 >> val2 >> val3;
}

Компилятор MSVC7.1(2003.NET) Результат на ассемблере:

; 23   :    PortL port;
; 24   :
; 25   :    port[25] << 0x01 << 0x03 << 0x05;
 
  00000 b8 01 00 00 00   mov     eax, 1
  00005 e7 19        out     25, eax            ; 00000019H
  00007 b8 03 00 00 00   mov     eax, 3
  0000c e7 19        out     25, eax            ; 00000019H
  0000e b8 05 00 00 00   mov     eax, 5
  00013 e7 19        out     25, eax            ; 00000019H
 
; 26   :    int val1, val2, val3;
; 27   :    port[30] >> val1 >> val2 >> val3;
 
  00015 e5 1e        in  eax, 30            ; 0000001eH
  00017 e5 1e        in  eax, 30            ; 0000001eH
  00019 e5 1e        in  eax, 30            ; 0000001eH
 
; 28   : }

Delphi-поклонникам смотреть и завидовать

Цитата Dantes

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

Цитата Dantes @ 09.04.07, 10:22

class A
{
    struct Nested
    {
        /* ... */
    } nested;
public:
    /* ... */
};
 
class B
{
    struct Nested
    {
        void f(A::Nested *p) { /* ... */ }
        /* ... */
    } nested;
public:
    /* ... */
};

Твои действия?

namespace Private // detail
{
    struct Nested_A
    {
        /* ... */
    };
 
    struct Nested_B
    {
        void f(Nested_A *p) { /* ... */ }
        /* ... */
    };
}
class A
{
Private::Nested_A nested;
public:
    /* ... */
};
 
class B
{
Private::Nested_B nested;
public:
    /* ... */
};

Можно еще pimpl замутить, чтобы пользователя в полном неведении оставить.

Цитата Smike @ 10.04.07, 04:27

Для Паскаля твои слова во многом справедливы, но с Дельфи (а именно этот язык является сабжевым) ты по-видимому не знаком

нет, я говорю об опаскале.... делфи не язык... делфи - RAD...

Цитата Smike @ 10.04.07, 04:27

VCL успешно портирована на Linux в среде Kylix/FreePascal. Самым нативным образом.

хочешь сказать, возьми я сейчас исходники любого компонента, перекомпилирую их в kylix и получаю рабочий компонент под linux? для qt\gtk - без проблем.

Цитата archimed7592 @ 10.04.07, 08:20

делфи не язык...

Если почитаешь справку по Делфи 7 или выше, увидишь обратное утверждение

2 Hryak

Имитация закрытости - что может выглядеть более жалко? Мой вариант был такой

class A
{
    struct Nested
    {
        /* ... */
    } nested;
    friend class B;
public:
    /* ... */
};
 
class B
{
    typedef A::Nested A_Nested;
    struct Nested;
    friend struct B::Nested;
    
    struct Nested
    {
        void f(A_Nested *p) { /* ... */ }
        /* ... */
    } nested;
public:
    /* ... */
};

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

Сообщение отредактировано: Dantes - 10.04.07, 08:51

Цитата Nich @ 10.04.07, 08:22

Если почитаешь справку по Делфи 7 или выше, увидишь обратное утверждение

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

Цитата archimed7592 @ 10.04.07, 08:20

нет, я говорю об опаскале.... делфи не язык... делфи - RAD...

Delphi как раз таки язык.

Цитата archimed7592 @ 10.04.07, 08:20

хочешь сказать, возьми я сейчас исходники любого компонента, перекомпилирую их в kylix и получаю рабочий компонент под linux?

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

А можно в кратце, чем оно от паскаля с обьектами отличается?

ЗЫ: Kylix может без вайновых либ жить?

Сообщение отредактировано: Alex Forth - 10.04.07, 08:47

Цитата Alex Forth @ 10.04.07, 08:46

ЗЫ: Kylix может без вайновых либ жить?

Kylix — нет, а скомпилированные им приложения — да.

Цитата trainer

Чисто для сравнения:
Исходник от Flex_Ferrum с небольшой моей модификацией

гм... да уж.. даже MSVC5 (1997г), оформило мне это в виде

_TEXT   SEGMENT
_main   PROC NEAR                   ; COMDAT
; File hello.cpp
; Line 20
    mov eax, 1
    out 25, eax                 ; 00000019H
    mov eax, 3
    out 25, eax                 ; 00000019H
    mov eax, 5
    out 25, eax                 ; 00000019H
; Line 22
    in  eax, 30                 ; 0000001eH
    in  eax, 30                 ; 0000001eH
    in  eax, 30                 ; 0000001eH
; Line 23
    ret 0
_main   ENDP
_TEXT   ENDS
END

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

Цитата

inpd inpw lrotl lrotr outp outpd outpw rotl rotr setjmp

и на попытку подставить вместо ф-кции, вставку вида:

// val = _inpd(m_Port);
__asm {
mov eax, m_Port //[m_Port]
}
это старьё отправило меня курить бамбук, с сообщением:

Цитата

hello.cpp(13) : error C2420: 'm_Port' : illegal symbol in second operand

ну никакого, бугага!

Добавлено 10.04.07, 10:38
оформив, ф-кцию в виде

Цитата

int _inpd (int val)
{ __asm {
mov edx, val
in eax, dx
}
}

асм листинг, уже не выглядел даким сверх-оптимизированым.. =(((

Цитата джастфорфанушка @ 10.04.07, 10:18

обнаружил в нём таблицу 'грязных хаков' в виде

Эта "таблица грязных хаков" называется встроенные(intrinsic) функции. Кстати, а fastcall-вызов в Delphi грязным хаком не является?

Цитата джастфорфанушка @ 10.04.07, 10:18

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

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

Цитата archimed7592 @ 09.04.07, 23:22

Цитата (AndNot @ Сегодня, 02:07)
Может, почему же нет?
эээ...конструктивно... зачОт

Можно и поконкретней

Цитата archimed7592 @ 09.04.07, 20:02

Для низкоуровневого программирования есть си + вынесенные в отдельный модуль\хедер асм-вставки

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

Цитата archimed7592 @ 09.04.07, 20:02

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

На дельфях писать на системном уровне ни чуть не сложнее чем на Си, скорее даже приятнее.

Цитата archimed7592 @ 09.04.07, 20:02

я уж молчу про разного рода костыли из разряда "неотключаемый модуль System" и ему подобные

Во первых, модуль System можно "отключить". А во вторых, какие еще "ему подобные", что то я не в курсе Может просветишь?

Цитата archimed7592 @ 09.04.07, 20:02

си\си++ можно отказаться от сборки со стандартными библиотеками ввода\вывода и\или прикрутить "свои" (stlport, к примеру

Никто не мешает сделать то же самое на дельфях

Цитата archimed7592 @ 09.04.07, 20:02

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

Чтобы сишник стал нормальным кодером, ему нужна практика, лет эдак 3-5. Да и то вопрос спорный, сумеет ли он за это время выучить (а тем более уметь применять) все возможности плюсов. Язык должен быть лаконичным и гибким. Последнего плюСям не занимать, а вот с первым просто катастрофа.

Цитата archimed7592 @ 09.04.07, 20:02

есть мощный boost, который решает все проблемы, которые ещё не решил Стандарт

Цитата archimed7592 @ 09.04.07, 20:02

есть незаменимые qt и gtk(gtkmm)

Либы? НезачОт

Цитата archimed7592 @ 09.04.07, 20:02

другими словами язык постояно усовершенствуется и всё меньше беспокоит проблема портирования

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

Цитата archimed7592 @ 09.04.07, 20:02

а какими темпами развивается opascal?

Полегоньку. Но в отличии от С++ ОПаскаль развивается в более разумном направлении, в сторону синтаксиса. Пример джастфорфанушка приводил.

Цитата archimed7592 @ 09.04.07, 20:02

как язык, с++ намного более гибкий, прозрачный и удобный

Обоснуй пожалуйста. Не совсем понял мысль

Цитата archimed7592 @ 09.04.07, 20:02

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

Была бы голова, остальное будет

Цитата джастфорфанушка @ 09.04.07, 23:54

на дельфи, подобный "сишный" подход, вида /inb/inw/inl /outb/outw/outl, както порядком поднадоел

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

Цитата джастфорфанушка @ 09.04.07, 23:54

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

Лишняя трата ресурсов, лишняя писанина (сравни сорсы), и как следствие впустую потраченное время.

Цитата trainer @ 10.04.07, 04:29

Delphi-поклонникам смотреть и завидовать

Чему завидовать? Мой любимый ватком выдал совершенную лажу

    testp = inpd(0x3f8);
 0040  b8 f8 03 00 00                    mov     eax,000003f8H
 0045  e8 00 00 00 00                    call    inpd_
 004a  a3 00 00 00 00                    mov     _testp,eax
 
    outpd(0x3f8, testp | 0x80000000);
 004f  89 c2                             mov     edx,eax
 0051  b8 f8 03 00 00                    mov     eax,000003f8H
 0056  81 ca 00 00 00 80                 or      edx,80000000H
 005c  e8 00 00 00 00                    call    outpd_

и никакая оптимизация не помогла.

Цитата джастфорфанушка @ 10.04.07, 10:18

Посмотрев в бинарник, front-end драйвера, компилера я обнаружил в нём таблицу 'грязных хаков' в виде

Цитата archimed7592 @ 09.04.07, 20:02

я уж молчу про разного рода костыли из разряда "неотключаемый модуль System"

Цитата AndNot @ 10.04.07, 11:46

Язык должен быть лаконичным и гибким. Последнего плюСям не занимать, а вот с первым просто катастрофа.

Ну насчет лаконичности вы бы с вашими begin/end молчали бы...