Re[21]: поддержка компонентной разработки
От: Erop Россия  
Дата: 29.05.05 22:11
Оценка:
Здравствуйте, Sinclair, Вы писали:

E>>Всё-таки хотелось бы понять что же нужно от языка для "действительно хорошей GUI библиотеке" такого, чего нет в C++.

S>Поддержки компонентной разработки. Я не буду расшифровывать — все это уже обсасывалось, и в том числе в этом форуме.

Можно понятнее?

Поиск вот так что-то ничего кроме как COM не дал. Но COM -- зело таки порождение C++

А если я правильно понимаю, кто такая "поддержка компонентной разработки", то это в основном требования к среде, а не к языку.
Если говорить о C++ и построении GUI, то смотрим на PowerPlant, например. Я не знаю насколько это супер библиотека, но она бесшовно интегрирована в среду (CodeWarrior) и в неё можно так же бесщовно интегрировать свои контролы, довольно произвольной степени сложности. При это они будут поддерживаться встроенными в среду средствами наровне со стандартной библиотекой.

Таки я не понимаю, что же не так в C++ именно с компонентной разоработкой, равно и то, зачем она нужна для хорошей GUI библиотеки
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[22]: поддержка компонентной разработки
От: Sinclair Россия https://github.com/evilguest/
Дата: 30.05.05 03:52
Оценка: +2
Здравствуйте, Erop, Вы писали:

E>А если я правильно понимаю, кто такая "поддержка компонентной разработки", то это в основном требования к среде, а не к языку.

Нет, это в основном требования к языку. В язык встроены:
— паттерн Factory в виде комбинации указатель на класс/виртуальный конструктор.
— паттерн Observer в виде замыканий, или event handler в терминологии Delphi
— генерация метаданных, пригодных для подсистемы сериализации
Таким образом, язык помогает разрабатывать компоненты, поддерживаемые средой. Я в курсе, что аналоги можно построить на С++. Правда, они будут более многословны.
E>Таки я не понимаю, что же не так в C++ именно с компонентной разоработкой
Ну, я тебе сочувствую. Мне лень пересказывать все эти флеймы. В С++ отсутствуют метаданные, нет встроенных средств динамической линковки, шаблоны только-только начинают уметь существовать в бинарном виде... А ты все не понимаешь, что же там не так. Для понимания достаточно посмотреть на стоимость реализации IDispatch на С++. А это как раз та самая компонентная разработка без поддержки со стороны языка. Даже самые суперрешения все равно требуют многословных описаний, применения макросов и прочих малоприятных приемов.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Почему настоящие программисты избегают C++
От: Mr. None Россия http://mrnone.blogspot.com
Дата: 30.05.05 04:11
Оценка:
Здравствуйте, EcliptoR, Вы писали:

ER>Здравствуйте, d Bratik, Вы писали:


ER>Ну не нравится не пиши на С++, че флейм то разжигать.

ER>Ксати, а есть что нибудь лучше С++, с таким же коммерческим успехом.

DB>>1.Отсутствие модулей. Имитация понятия модуль в виде пары h-файл – cpp-файл приводит к многочасовым компиляциям системы.


ER>Можно все в хэдере писать. Никто не запрещает.


НЕЕЕТ!!!!!! НЕ НАДО!!!!!!!!!!!!!!!!!!!! Эта ветка уже задолбала!!!!! Пусть она спокойно умрёт, не начинайте этот флейм с начала!!!!!!!!!!!!! Всё что вы тут сказали уже было сказано и пересказано на 3 раза!!!!!!!!! Пошлите лучше
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[20]: А всё-так чем же pascal дгчше для GUI библиотек-то?
От: Kh_Oleg  
Дата: 30.05.05 07:27
Оценка:
Здравствуйте, Владик, Вы писали:

K_O>>finalization код выполняется в деструкторе объекта, а в С++ исключение в деструкторе — это undefined behaviour.


В>В С++ исключение в деструкторе — это вполне себе defined behaviour. Хотя и плохой тон. Проблемы начинаются в случае, когда деструктор вызывается уже как реакция на возбуждение исключения.


Так я ж про это и говорю — читайте внимательнее.
Re[21]: SEH и C++ синонимы или нет?
От: Erop Россия  
Дата: 31.05.05 07:49
Оценка:
Здравствуйте, Kh_Oleg, Вы писали:

AE>>Что насчет __try... __finally в с++ ? Хотя это и MS-specific но все же...

K_O>Все эти изменения в языке или макросы в библиотеках — все это заплатки, свидетельствующие о кривизне языка С++.

Собственно SEH -- это часть WIN32. Интерфейс этой части требует поддержки со стороны компилятора (требуется формировать специфический фрейм), так что менять компилятор, для поддержки SEH всё равно надо. От чего бы не добавить для этого специальные операторы в язык? Это конечно не по C++ному, но зато по SEHовски

Так что пи чём тут C++ вообще не понятно
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[22]: Я тоже не люблю гибкость :)
От: Kh_Oleg  
Дата: 31.05.05 08:21
Оценка:
Здравствуйте, Erop, Вы писали:

K_O>>Все эти изменения в языке или макросы в библиотеках — все это заплатки, свидетельствующие о кривизне языка С++.


E>Забавно, а вот приверженцы C++, обычно, возможность вводить в язык новые синтаксические кончтрукции при помощи макросов и хитрых шаблонов и перегруженных операторов, называют гибкостью и считают одним из огромных достоинств языка


Они просто не отлаживали и не сопросвождали свои "хитрые синтаксические конструкции".

Однако, я имел ввиду не макросы вообще, а RUNTIME_CLASS конкретно. А недостаток в том, что он доступен только при использовании MFC.

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


E>Но я всё равно не понял при чём тут GUI


Вообще, изначально ветка была именно про С++ и почему он плох при создании больших систем с GUI.
Re[22]: SEH и C++ синонимы или нет?
От: Kh_Oleg  
Дата: 31.05.05 08:22
Оценка:
Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Kh_Oleg, Вы писали:


AE>>>Что насчет __try... __finally в с++ ? Хотя это и MS-specific но все же...

K_O>>Все эти изменения в языке или макросы в библиотеках — все это заплатки, свидетельствующие о кривизне языка С++.

E>Собственно SEH -- это часть WIN32. Интерфейс этой части требует поддержки со стороны компилятора (требуется формировать специфический фрейм), так что менять компилятор, для поддержки SEH всё равно надо. От чего бы не добавить для этого специальные операторы в язык? Это конечно не по C++ному, но зато по SEHовски


E>Так что пи чём тут C++ вообще не понятно


Речь идет именно о языке, который предетдует на роль универсального языка для кроссплатформенной разработки. И приведены аргументы, почему он на эту роль не подходит.
Re[23]: SEH и C++ синонимы или нет?
От: Владик Россия  
Дата: 31.05.05 09:12
Оценка: +3
Здравствуйте, Kh_Oleg, Вы писали:

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


И тем не менее, по факту он им является Как раз потому, что не заточен под всякие SEH и т.п. platform-specific. Тебе уже популярно объяснили, что finally в C++ нужен не более, чем goto (если еще не понял — воспользуйся поиском по сайту, эта тема неоднократно обсуждалась). Разница только в том, что goto в языке официально есть (пресловутая совметимость с С этому не последняя причина), а finally — нет. Но это не мешает большинсву программистов всячески избегать применения goto или принципиально обходится без него (при этом не напрягаясь). Код, не загроможденный лестницами try/finally, выглядит намного понятнее, а на тот единичный случай, когда совсем влом писать отдельный и очень специфичный guard для выполнения какого-либо финализирующего действия — можно воспользоваться обобщенным guard'ом с функтором.
Как все запущенно...
Re[12]: Почему настоящие программисты избегают C++
От: johny5 Новая Зеландия
Дата: 31.05.05 09:21
Оценка:
A>.NET же, отвечая на вопрос "почему"... Во-первых, вряд ли прародителем была именно Дельфа.

Ходят слухи, что microsoft при написания .Net выкрала у borland главного проектировщика VCL (фамилию я как всегда не помню, кто знает может кинет.. ).

Лично мне переход Builder -> .Net дался жутко легко, чуствуешь себя как дома — те же properties, синтаксис методов.. Правда пришлось столкнуться с managed c++ но это другое.

p.s.: например в VB существовало понятие Tag у объектов?
... << RSDN@Home 1.1.4 beta 6a rev. 443>>
Re: Почему настоящие программисты избегают C++
От: nataniel  
Дата: 31.05.05 09:23
Оценка:
черт, даже не знаю, в юмор это записать или сюда...
приведу кусок кода, в который я залез час назад. Цель программы — получение информации о сетевых адапторах
int MibII::MIB_GetIPAddress(DWORD *MIB_Array,int max_addresses, 
    BOOL bShowLoopbackAddress)
{

    UINT OID_ipAdEntAddr[] = { 1, 3, 6, 1, 2, 1, 4 , 20, 1 ,1 };
    AsnObjectIdentifier MIB_ipAdEntAddr = 
    { sizeof(OID_ipAdEntAddr)/sizeof(UINT), OID_ipAdEntAddr };
    RFC1157VarBindList  varBindList;
    RFC1157VarBind      varBind[1];
    AsnInteger          errorStatus;
    AsnInteger          errorIndex;
    AsnObjectIdentifier MIB_NULL = {0,0};
    BOOL                Exit;
    int                 ret;
    int                 IpCount=0;
    DWORD               dtmp;
    BYTE                a1,a2,a3,a4;
    
    varBindList.list = varBind;
    varBindList.len  = 1;
    varBind[0].name  = MIB_NULL;
    SNMP_oidcpy(&varBind[0].name,&MIB_ipAdEntAddr);
    Exit = FALSE;
    
    IpCount=0;

    while(!Exit){
        ret = Query(ASN_RFC1157_GETNEXTREQUEST,&varBindList,
            &errorStatus,&errorIndex);
        
        if(!ret)
            Exit=TRUE;
        else{
            ret = SNMP_oidncmp(&varBind[0].name,&MIB_ipAdEntAddr,
                MIB_ipAdEntAddr.idLength);
            if(ret!=0){
                Exit=TRUE;
            }
            else
            {
                dtmp = *((DWORD *)varBind[0].value.asnValue.address.stream);
                if (dtmp!=0)
                {
                    // Octets in returned IP addresses are in reverse order
                    a1=(BYTE)((dtmp>>24) & 0xFF);
                    a2=(BYTE)((dtmp>>16) & 0xFF);
                    a3=(BYTE)((dtmp>>8) & 0xFF);
                    a4=(BYTE)(dtmp & 0xFF);

                    if ((a4!=127) && (a4!=0))
                    {
                        *MIB_Array = (a4<<24) + (a3<<16) + (a2<<8) + a1;
                        *MIB_Array++;
                        IpCount++;
                    }
                    else
                    {
                        if (bShowLoopbackAddress)
                        {
                            *MIB_Array = (a4<<24) + (a3<<16) + (a2<<8) + a1;
                            *MIB_Array++;
                            IpCount++;
                        };
                    };
                };

                if(IpCount>=max_addresses)
                    Exit = TRUE;
            }
        }
    }

    SNMP_FreeVarBind(&varBind[0]);

    return IpCount;
}

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

MIB_Array — это временный статический массив; когда функция завершается, из него копируются данные в другой, такой же массив
max_addresses — отдефайненая константа
... да что это я, смотрите сами:

int CSysInfo::MIBRefreshAddresses()
{
    int i,nAddresses=0; BOOL bDiff=FALSE;

    for(i=0;i<MAX_IPADDRESSES;i++)
        { m_dwMIBIPArray_tmp[i]=0; };

    nAddresses=m_mib.MIB_GetIPAddress(&m_dwMIBIPArray_tmp[0],
        MAX_IPADDRESSES,m_bMIBShowLoopback);

    if (m_nMIBAddresses!=nAddresses)
    {
        bDiff=TRUE;
    }
    else
    {
        for (i=0;i<nAddresses;i++)
        {
            if (m_dwMIBIPArray[i]!=m_dwMIBIPArray_tmp[i])
            {
                bDiff=TRUE;
                break;
            };
        };
    };

    if (bDiff)
    {
        for(i=0;i<nAddresses;i++)
        {
            m_dwMIBIPArray[i]=m_dwMIBIPArray_tmp[i];
        };
        m_nMIBAddresses=nAddresses;
    };

    return m_nMIBAddresses;
}


Я, может, ошибаюсь, но этот человек не с Делфи пришел не так давно?
Скажите, это Делфи заставляет так писать или это его личная инициатива?
Re[24]: SEH и C++ синонимы или нет?
От: Kh_Oleg  
Дата: 31.05.05 09:42
Оценка: -1
Здравствуйте, Владик, Вы писали:

В>Здравствуйте, Kh_Oleg, Вы писали:


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


В>И тем не менее, по факту он им является Как раз потому, что не заточен под всякие SEH и т.п. platform-specific. Тебе уже популярно объяснили, что finally в C++ нужен не более, чем goto (если еще не понял — воспользуйся поиском по сайту, эта тема неоднократно обсуждалась). Разница только в том, что goto в языке официально есть (пресловутая совметимость с С этому не последняя причина), а finally — нет. Но это не мешает большинсву программистов всячески избегать применения goto или принципиально обходится без него (при этом не напрягаясь). Код, не загроможденный лестницами try/finally, выглядит намного понятнее, а на тот единичный случай, когда совсем влом писать отдельный и очень специфичный guard для выполнения какого-либо финализирующего действия — можно воспользоваться обобщенным guard'ом с функтором.


Не знаю, что такое guard с функтором, но если он работает также, как и обычные guards — т.е. если finalization код вызывается в деструкторе некоторого объекта, но такой подход неприменим при создании exception-safe приложений.
Re[2]: Почему настоящие программисты избегают C++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 31.05.05 09:43
Оценка:
Здравствуйте, nataniel, Вы писали:

N>
N>int CSysInfo::MIBRefreshAddresses()
N>{
...
N>    if (m_nMIBAddresses!=nAddresses)
N>    {
N>        bDiff=TRUE;
N>    }
N>    else
N>    {
N>        for (i=0;i<nAddresses;i++)
N>        {
N>            if (m_dwMIBIPArray[i]!=m_dwMIBIPArray_tmp[i])
N>            {
N>                bDiff=TRUE;
N>                break;
N>            };
N>        };
N>    };
...
N>}
N>


N>Я, может, ошибаюсь, но этот человек не с Делфи пришел не так давно?

N>Скажите, это Делфи заставляет так писать или это его личная инициатива?

Особенно умиляют точки с запятой после закрывающих фигурных скобок. Интересно, автор с ними на такие грабли никогда не наступал:
if( a )
    if( a > 10 )
        {
            std::cout << "a > 10" << std::endl;
        };
    else
        std::cout << "a <= 10" << std::endl;

?

... << RSDN@Home 1.1.4 beta 7 rev. 447>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[25]: SEH и C++ синонимы или нет?
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 31.05.05 09:48
Оценка:
Здравствуйте, Kh_Oleg, Вы писали:

В>>И тем не менее, по факту он им является Как раз потому, что не заточен под всякие SEH и т.п. platform-specific. Тебе уже популярно объяснили, что finally в C++ нужен не более, чем goto (если еще не понял — воспользуйся поиском по сайту, эта тема неоднократно обсуждалась). Разница только в том, что goto в языке официально есть (пресловутая совметимость с С этому не последняя причина), а finally — нет. Но это не мешает большинсву программистов всячески избегать применения goto или принципиально обходится без него (при этом не напрягаясь). Код, не загроможденный лестницами try/finally, выглядит намного понятнее, а на тот единичный случай, когда совсем влом писать отдельный и очень специфичный guard для выполнения какого-либо финализирующего действия — можно воспользоваться обобщенным guard'ом с функтором.


K_O>Не знаю, что такое guard с функтором, но если он работает также, как и обычные guards — т.е. если finalization код вызывается в деструкторе некоторого объекта, но такой подход неприменим при создании exception-safe приложений.




О как! А мужики-то и не знают!
... << RSDN@Home 1.1.4 beta 7 rev. 447>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[3]: Почему настоящие программисты избегают C++
От: nataniel  
Дата: 31.05.05 10:10
Оценка:
Здравствуйте, eao197, Вы писали:

E>?


E>


я не понимаю, почему после while () {} точка с запятой не стоит...
Re[25]: SEH и C++ синонимы или нет?
От: Владик Россия  
Дата: 01.06.05 13:00
Оценка: 1 (1) +3
Здравствуйте, Kh_Oleg, Вы писали:

K_O>Не знаю, что такое guard с функтором, но если он работает также, как и обычные guards — т.е. если finalization код вызывается в деструкторе некоторого объекта, но такой подход неприменим при создании exception-safe приложений.


Ты неправильно трактуешь саму концепцию finalization кода. Такой код по определению не может кидать исключений, которые можно осмысленно обработать — или это уже не finalization код. Например, классическая ошибка — пытаться в finalization коде делать commit транзакции, застартованной в initialization. commit должен вызываться в основном коде явно и явно обрабатываться его ошибки, а вот rollback — можно и в finalization (если транзакция не была успешно завершена). При этом если rollback кидает исключение, то значит все совсем плохо, и тут уж сделать что-то более осмысленное, чем запись в лог — вряд ли можно.

P.S. Что касается С++ c guard с функтором — никто не мешает тебе в деструкторе guard сделать try/catch на случай непредвиденного (rollback кидает исключение). В случае, если этого не сделать, насколько я знаю, будет вызван terminate() (а вовсе не undefined behavior). С terminate() тоже можно еще чего-то придумать (сам по себе вызов не означает завершение программы). Хотя на моей практике до такого не доходило. Так же как и особых проблем с исключениями в деструкторе я не припомню.
Как все запущенно...
Re[29]: Почему настоящие программисты избегают C++
От: Erop Россия  
Дата: 01.06.05 22:10
Оценка: +1 -1
Здравствуйте, AVC, Вы писали:

AVC>Вот мнение астрономов, авторов книги "Астрономия на персональном компьютере":

Здесь надо сказать, что по сравнению с другими языками C++ имеет много недостатков, которые затрудняют разработку сложных научных программ. В частности, у него слабая поддержка одномерных и многомерных массивов, нет локальных процедур, неудачная концепция модуля, не поддерживается проверка индексов массивов, а также выполняется неконтролируемое преобразование типов.


Ну я согласен, что у C++ много недостатков. Главный из них -- программирование на нём требует изучения как это делать. Так что он плохо подходит для физиков или биологов. Но я, как выч. матьематик, сообщу, что программирование для людей этих специальностей обычно по многим причинам мало подходит

А если делать большой проект на C++, то есть некоторая уверенность, что удастся разрешить все проблемы, потому что у тебя есть все силы и средства для этого. От того так эту самую преславутую гибкость в купе с мощью и любят. Хотя это и влечёт за собой то, что разработка на C++ требует наличия инструкции
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[25]: Почему настоящие программисты избегают C++
От: Erop Россия  
Дата: 01.06.05 22:15
Оценка:
Здравствуйте, AVC, Вы писали:

AVC>Вот ссылка:

AVC>http://www.inr.ac.ru/~info21/info/koltashev.jpg

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

Интересно, они хоть какую-то современную среду разработки видали?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[21]: Почему настоящие программисты избегают C++
От: Erop Россия  
Дата: 01.06.05 22:18
Оценка:
Здравствуйте, The Lex, Вы писали:

TL>Т.е. вы хотите сказать, что ежели дочернее окно и родительское окно будут иметь разные потоки, то возникнут проблемы? Хм... Можно огласить весь код? Можно в новую тему...


Очень легко получить дедлок, так как есть много неконтролируемых синхронизаций.

В смысле сама винда конечно нифига дедлок не сделает, но если в программе будет ещё и какая-то логика взаимодействия нитей помимо окон, то без проблем
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[9]: Почему настоящие программисты избегают C++
От: Erop Россия  
Дата: 01.06.05 22:22
Оценка:
Здравствуйте, d Bratik, Вы писали:

DB>Есть алгоритмическая сложность, а есть архитектурная. С первым видом сложности справиться намного проще, чем со вторым.


DB>GUI (framework) — это огромная архитектурная сложность.


В принципе я соглдасен, что если GUI -- это огромнгая арх. сложность, то навернео лучше не на C++. МОжно много наколбасить

Всё-таки бывают ещё задачи, где архитектура очень сильно сложнее GUI. Всё-таки GUI обычно устроен не так чтобы очень сложно.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[9]: Почему настоящие программисты избегают C++
От: Erop Россия  
Дата: 01.06.05 22:24
Оценка:
Здравствуйте, AndrewJD, Вы писали:

AJD>Можешь описать, хотя бы в двух словах, как портировали под Мак?


А в чём проблемы? Он же писал, что гуй абстрагирован был от внутренней логики

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