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

[--Ins--]

Цитата

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

Скорее всего да. Потому что по всей видимости:
1. Так сложилось исторически
2. В Borland не придумали как это реализовать в компиляторе. Как это реализовать в языке - очевидно.
3. На это есть некие объективные причины, о которых мне неизвестно.
Да и в любом случае, это не такая уж серьезная проблема

Цитата

К примеру, на С++ у меня на это ушло бы 15-20 мин.

А у меня на Delphi 15-20 минут бы занял полиморфный код сериализации объектов. Ну, универсальный код, который позволяет сохранить/восстановить состояние любого объекта, который бы ты ему не подсунул. Причем в классах этих объектов не нужно было бы писать какой-либо специальный код А смог бы ты это сделать на C++? Я это к тому, что может не стОит меряться таким способом, у слона все равно длиннее.

[Flex Ferrum]

А с введением нового стандарта из него исчезнет ряд заморочек, и ты вполне можешь написать так:

void foo()
{
   auto some_var = Something.GetAnotherSomething(); // тип some_var будет определен автоматически компилятором
 
   // ... что-то еще делаем
}

[AndNot]

Цитата archimed7592 @ 11.03.08, 09:13

Так, поднимаешь взор на заголовок браузера и видишь

Вообще то разговор защел о char, а не о типе плюсов string, являющегося всего лишь надстройкой А с char ты можеш работать только через всякие strXXX.

Цитата archimed7592 @ 11.03.08, 12:39

На примере с С++: есть Стандарт(Его Величество), а есть куча разных компиляторов - т.н. conforming implementation. Но не все из них conforming - скажем, Borland C++ Builder 6 сильно далёк от стандарта(из-за своей древности). Т.о. если ты будешь критиковать конкретно BCB, то я скажу тебе выкинь BCB и обрати взор на Стандарт - там то-то и то-то можно делать так-то и так-то.

Особенно умиляют попытки компиляции проектов разными компиляторами, постоянно появляются какие то мистические глюки. Не так давно просматривал тему, об эмуляции BGI-графики. Меня до слез прошибала "совместимость" различных компиляторов, а порой и вообще мистические требования, вроде тех, что бы последняя строка в сорсах обязательно заканчивалась <CR>, или просьбой убрать определенные конструкции, хоть и в соответствии со стандартом, но вносящие определенные проблемы в разных компиляторах И это компиляторы, поддерживающие стандарт Да ладно бы не компилилось, а то ведь и скушает компилятор, а прога не пашет, хотя другой компилер выдал рабочий код И это нормально? Главное причина то на поверхности - слишком объемный стандарт, на изучение которого нужна уйма времени, отсюда и ошибки растут. Что нет? А как тогда объяснить нарушение принципа блочной структуры программ, это когда операторы, которые должны принадлежать к одному блоку программы(тот же switch...case), можно смело разнести в разные блоки? И компилятор обязан это проглотить, поскольку этот баг обнаружили слишком поздно, вот и внесли в стандарт, для совместимости Вообще это неправильно как то. Если утверждается, что плюсы новый язык, то зачем было вводить в него поддержку Си? Наверное просто побоялись, что новый язык не приживется, вот и кинули косточку Сишникам, для безболезненного перехода

Цитата --Ins-- @ 11.03.08, 13:08

И я думаю - это правильно. Так как если введение стандарта будет иметь смысл - уверен, это будет сделано.

Вот здесь не соглашусь. Это приводит к тому, что всякие Free Pascal просто не успевают за Дельфи, совместимость с которым они бы рады обеспечить. Самый удачный стандарт встречал у Форта. Там есть минимальный список правил, а так же рекомендуемый, но не обязательный. И это позволяет писать компиляторы заточенные под разные задачи, с базовой совместимостью.