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

Цитата Hryak @ 09.04.07, 09:03

Общность решаемой задачи - может быть, но не зависимость реализаций шаблона друг от друга.

Если имеется попытка обращения к закрытой части, то такая зависимость очевидна.

Цитата Hryak @ 09.04.07, 09:03

То, что по умолчанию члены класса являются приватными - тебя не смущает, например?

Смущает Во-первых, пользователя в первую очередь должен интересовать открытый интерфейс, а не закрытые члены. Это делает поиск интересущих его членов неудобным, поэтому сразу после { я пишу public (делая по сути лишнее действие) и описываю открытые члены. Во-вторых, лично мне гораздо чаще приходилось применять открытое наследование, нежели закрытое, и было бы гораздо удобней не указывать public в большинстве случаев.

Цитата Hryak @ 09.04.07, 09:03

Основная идея - минимизация прав. Если кому-то что-то нужно - это явно дается.

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

Цитата Dantes @ 09.04.07, 09:37

Польза от таких жёстких ограничений сомнительна, зато неудобства налицо.

Ну какие же это жесткие ограничения? Строчку не написать?

Цитата Hryak @ 09.04.07, 09:42

Ну какие же это жесткие ограничения? Строчку не написать?

Иногда строчек надо больше, например, две

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

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

Сообщение отредактировано: Dantes - 09.04.07, 10:39

Цитата linuxdan

В Pascal'е Borland изначально поступил по-другому: они не стали делать include, они изобрели свой формат модулей, которые компилируются и компонуются (кстати, в BP был некислый оптимизатор: он выбрасывал из exe файла все неиспользуемые процедуры и функции)

Высокоскоростные традиции TP&BP продолжают жить и здраствовать и в новых релизах дельфи (думаю появяться и под x86_64). Кстати, тут из за этих class'ов, столкнулся, со старыми граблями в виде внутрених инициализаций этой структуры, напиханых в обьектник..

Цитата

@TObject
@TObject@SafeCallException
@TObject@AfterConstruction
@TObject@BeforeDestruction
@TObject@Dispatch
@TObject@DefaultHandler
@TObject@NewInstance
@TObject@FreeInstance
@TObject@$bdtr

Но, по счастью, новые стандарты Delphi (BDS2006), допускают подобные конструкции и в записях

Type
 TPortL = record // class
   private
     function  ReadPortL(index:integer):integer;
     procedure WritePortL(index:integer; value:integer);
   public
     property port[index:integer]:integer
         read ReadPortL write WritePortL;default;
end;
 
function  TPortL.ReadPortL(index:integer):integer;
          asm  in eax,dx end;
procedure TPortL.WritePortL(index:integer; value:integer);
          asm mov eax,ecx; out dx,eax end;

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

Конкретно работающий код,

Procedure SetupPCIDevice (Enabled:boolean);
var data : integer;
begin
// PCI шина 0, устройство 7, функция 5
     data := $80000000 or (7 shl 11)  or (5 shl 8 ) or $40;
     portl [PciCfgAddr] := data;
     data := portl[PciCfgData];
     data := data or $00010100;

несмотря, на некоторые накладные расходы, выглядит весьма-и весьма
замечательно:

00401958: ED              in         eax,dx
00401959: C3              retn
 
0040195C: 89C8            mov        eax,ecx
0040195E: EF              out        dx,eax
0040195F: C3              retn
 
00401983: B8403D0080      mov        eax,080003D40
00401988: BA78464000      mov        edx,000404678
0040198D: 8BC8            mov        ecx,eax
0040198F: B8F80C0000      mov        eax,000000CF8
00401994: 92              xchg       edx,eax
00401995: E8C2FFFFFF      call       00040195C
 
0040199A: B878464000      mov        eax,000404678
0040199F: BAFC0C0000      mov        edx,000000CFC
004019A4: E8AFFFFFFF      call       000401958
004019A9: 0D00010100      or         eax,000010100

И нафик asm, когда ЯВУ компилер, нормально работу свою делает? Хотя, следить за этим тоже надо

Заценил, полученый аsm-листинг С++ кода (by Flex Ferrum )... Ну что сказать, выглядит пока не в лучшую сторону, впрочем, думаю-с разобраться (как нибудь, на досуге) с опциями по оптимизации кода на BCC5.5/VC.NET2003/INTEL C++, а то я не вьехал в каком месте стека, там даные брать/ложить, и вообще fastcall задействоать, а то мну данные детали пока не вдохновляют, использовать это в критических процедурах.. (опять же сколько с ними мороки... )

Сообщение отредактировано: n0p - 09.04.07, 11:14

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

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

Переделать архитектуру. Из внутреннего класса одного класса обращаться к внутреннему классу другого класса с friend-доступом...

Цитата n0p @ 09.04.07, 11:11

Заценил, полученый аsm-листинг С++ кода (by Flex Ferrum )... Ну что сказать, выглядит пока не в лучшую сторону, впрочем, думаю-с разобраться (как нибудь, на досуге) с опциями по оптимизации кода на BCC5.5/VC.NET2003/INTEL C++, а то я не вьехал в каком месте стека, там даные брать/ложить, и вообще fastcall задействоать, а то мну данные детали пока не вдохновляют, использовать это в критических процедурах.. (опять же сколько с ними мороки... )

Сообщение отредактиро

Зачем там вообще fastcall? Ты чего? Все прекрасно должно раскрываться в inline. Приведи ассемблерный листинг, который тебя смущает.

Цитата Hryak @ 09.04.07, 15:39

Переделать архитектуру.

Ага, и только из-за проблем с доступностью Просто замечательно

Цитата Hryak @ 09.04.07, 15:39

Из внутреннего класса одного класса обращаться к внутреннему классу другого класса с friend-доступом...

Как? Я вижу только один вариант, но, может, ты предложишь что-то лучше?

Цитата Dantes @ 09.04.07, 18:14

Ага, и только из-за проблем с доступностью Просто замечательно

скорее из-за ошибки проектирования

Добавлено 09.04.07, 18:20

Цитата Dantes @ 09.04.07, 18:14

Как? Я вижу только один вариант, но, может, ты предложишь что-то лучше?

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

Цитата Dantes @ 09.04.07, 18:14

Цитата Hryak @ 09.04.07, 15:39

Переделать архитектуру.

Ага, и только из-за проблем с доступностью Просто замечательно

Я говорил про другое - ты перепутал причину и следствие.

Цитата

Цитата Hryak @ 09.04.07, 15:39

Из внутреннего класса одного класса обращаться к внутреннему классу другого класса с friend-доступом...

Как?

Опять не поняли друг друга (ты смайлика не заметил, что ли?). Я не про то, как сделать такой доступ, а про сам факт требования этого.

Сообщение отредактировано: Hryak - 09.04.07, 19:01

Цитата n0p @ 09.04.07, 11:11

выглядит весьма-и весьма
замечательно:

Ты это серьезно? А имхо отвратительно. Один вызов ReadPort весит в три раза больше чем сама подпрограмма Я уж не говорю о совершенно бесполезной манипуляции регистрами перед вызовом подпрограммы Да и WritePort чего стоит Них..фига дельфи так и не научился параметры через регистры передавать. То ли дело в Watcom C++, можно явно указать, через какие регистры поступят параметры, и делать ли подпрограмму или инлайн

Цитата impik777 @ 09.04.07, 18:19

скорее из-за ошибки проектирования

Если считать ошибкой проектирования то, что в силу корявостей языка приводит к серьёзным затруднениям, то, возможно, ты прав

Цитата impik777 @ 09.04.07, 18:19

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

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

Добавлено 09.04.07, 19:04

Цитата Hryak @ 09.04.07, 18:59

Я говорил про другое - ты перепутал причину и следствие.

Так объясни, чтоб было понятно

AndNot- ну на вкус и цвет, как говориться.. хотя по мне - получше, чем, например у ф-кции WRITE_PORT_ULONG, из HAL.DLL, через которую все драйвера обращаються.

80017E7C: 8B542404 mov  edx,[esp][04]
80017E80: 8B442408 mov  eax,[esp][08]
80017E84: 66EF     out  dx,ax
80017E86: C20800   retn 00008

Цитата AndNot

Один вызов ReadPort весит в три раза больше чем сама подпрограмма

дык

    for i:=0 to 4000 do;

работает быстрее чем

    out dx, eax

так что, пеши хоть в машкоде, никакая экономия тут не поможет

Цитата AndNot

дельфи так и не научился параметры через регистры передавать

Три регистра - (_eax,_ecx,_edx), наше всё. Кстати можно код в студию насчет Watcom'a? А то вон ICC6 крякать пришлось, чтоб он и в формате Borland fastcall, данные запуливал (пришлось жертвовать __сdecl'ом). А то у него M$явочной -Gr, два регистра (eax/ecx), да стек. Не густо..

Добавлено 09.04.07, 19:37

Цитата Flex Ferrum

Приведи ассемблерный листинг, который тебя смущает

ой.. пока воюю с

Цитата

// Тут нужно заменить на соответствующие ассемблерные вставки

Добавлено 09.04.07, 19:50

Цитата AndNot

Я уж не говорю о совершенно бесполезной манипуляции регистрами перед вызовом подпрограммы

в eax-e указатель на конкретный record/object/class (что иногда бывает нужно), а в обьектную переменную interrupt[xx] (как в старом добром ТурбоПаскале, ток в 32-битном варианте), думаю заюзать IDT, получив указатель, через SIDT. Или может вы, сэр знаете как это нарисовать проще?

Для низкоуровневого программирования есть си + вынесенные в отдельный модуль\хедер асм-вставки (для удобства портирования, не нужно забывать про этот фактор)... и как бы вы не холиварились, любителей поизвращаться с опаскалем в этой области всегда будет мало. я уж молчу про разного рода костыли из разряда "неотключаемый модуль System" и ему подобные. замечу, что в си\си++ можно отказаться от сборки со стандартными библиотеками ввода\вывода и\или прикрутить "свои" (stlport, к примеру).

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

• есть удобная stl, которую можно заменить, или вовсе отказаться от неё
• есть мощный boost, который решает все проблемы, которые ещё не решил Стандарт
• есть незаменимые qt и gtk(gtkmm), которые не менее кроссплатформенны и намного более удобны (чего стоят HBox\VBox, которые освобождают от необходимости вычислять координаты руками...а ещё, фиг знает, какое растояние между кнопочками должно быть, чтобы выглядело "как везде")
• новый Стандарт включит в себя pcre, posix-like потоки, атомарные операции, static_assert и многое другое...другими словами язык постояно усовершенствуется и всё меньше беспокоит проблема портирования...а какими темпами развивается opascal?
• для с++ есть туева хуча библиотек, которые живут, развиваются, усовершенствуются и, что самое главное, многие из них кроссплатформенны, что, опять же, огромный плюс
• как язык, с++ намного более гибкий, прозрачный и удобный(ну это на вкус и цвет)...примеров этого было уже приведено туева хуча (целых 9 страниц)

в итоге: на с++ можно быстро писать хорошо спроектированные приложения, которые будут кроссплатформенны(либо переносимы без особой крови), которые будет легко поддерживать, части которых можно будет использовать в других подобных(и не очень ) проектах. да, основную роль здесь играет проетирование, но, думаю бейсику никакое проетирование не поможет...почти тоже самое можно сказать и о опаскале.

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

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

Цитата джастфорфановец @ 09.04.07, 19:26

хотя по мне - получше, чем, например у ф-кции WRITE_PORT_ULONG, из HAL.DLL, через которую все драйвера обращаються

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

Цитата джастфорфановец @ 09.04.07, 19:26

дык

for i:=0 to 4000 do;


работает быстрее чем

out dx, eax


так что, пеши хоть в машкоде, никакая экономия тут не поможет

Я вообще то размер имел в виду Вместо одного байта (in), у тебя получается шесть!

Цитата джастфорфановец @ 09.04.07, 19:26

Кстати можно код в студию насчет Watcom'a?

Пожалуйста, почти то же как и у тебя:

#include <stdio.h>
 
int testp;
 
int inport(int portnum);
#pragma aux inport = " in  eax,dx " parm [dx] modify [eax dx];
 
void outportll(int portnum, int value);
#pragma aux outportll = " out  dx,eax " parm [dx] [eax] modify [eax dx];
 
main()
{
    testp = inport(0x3f8);
    outportll(0x3f8, testp | 0x80000000);
    printf( "Hello world\n" );
}

Вот листинг:

    testp = inport(0x3f8);
0046E014        mov     edx, 000003F8
0046E019        in      eax, dx
0046E01A        mov     edx, 000003F8
0046E01F        mov     [0047236C], eax                 testp = 00000000
    outportll(0x3f8, testp | 0x80000000);
0046E024        or      eax, 80000000
0046E029        out     dx, eax
............................... cut ............................

вот это и называется почти хорошей оптимизацией (разве что EDX повторно перезаписывается, но больно уж компилятор старый:)
Кстати подобной фичи с параметрами очень сильно нехватает современным языкам, ну разве что C-- превосходно под это заточен

Цитата джастфорфановец @ 09.04.07, 19:26

думаю заюзать IDT, получив указатель, через SIDT. Или может вы, сэр знаете как это нарисовать проще?

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

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

может ли опаскаль похвастаться хотя бы частью этих преимуществ? буду рад послушать

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

Цитата AndNot @ 09.04.07, 23:07

А насчет кроссплатформенности просто смешно звучит.

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

Добавлено 09.04.07, 23:24

Цитата AndNot @ 09.04.07, 23:07

Может, почему же нет?

эээ...конструктивно... зачОт