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

_O_>Вы не сталкивались просто с разработкой под DSP, RTOS-ы и Embedded платформы.

И что там такого особенного?
для ARM aDSP133 очсень корявый компилятор С++, но это не мешает его использовать....

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

WH>Ну ты эта зайди в форум по С++ и спроси почему нельзя использовать void*...

То есть вопрос класса "goto или без goto"?

WH>ТИПИЗАРОВАНОСТЬ такое слово знаешь? А можешь мне сказать какая структура данных лежат в основе TList?

Знаем. В основе — массив указателей. Для хранения списка чего угодно. Потому что поддержка вариантов пришла позже. Да и в связи сс динамическими массивами поддерживать вариантный TList (а он-то будет типизированным/автопреобразующимся) неактуально. А вот для списка объектов Борланд быстро допёр сделать TObjectList. Я такую штуку в D3 или D4 сам писал, т.к. не было её.

В TOjectList храним потомков TObject, список может выступать Owner для этих потомков с вытекающими. При необходимости хранить одинаковых потомков можно заместить свойство Items[].

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

Понимаю как полиморфизм и инкапсуляцию.

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

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

WH>Слабо на дельфях написить такого помошника?

Может и нет, если постановку задачи сделать словами, или хотя бы на C#. А то слова вроде знакомые, а вместе — чехарда в голове. Только надо ли?

WH>Ой не надо на дельфе начинается try finaly hell.

Ну, ну. Я вот тоже не понимал, зачем не просматривается иерархии в блоках try и catch в C#. В обоих случаях эти блоки просты, и их понимание и правильное использование приходит с опытом.

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

WH>Вот на вы переходить не надо выглядит так что драться собрался
S>>то что Delphi уступает в своем развитии C++ Вам уже много раз говорили.

(Достал упорством...)

WH>Я бы сказал безнадежно уступает.

Я бы нет. А почему, ответил в нашей беседе.

WH>И чтоже его может спасти? Добавят шаблоны, множественное наследование, приведут в порядок систему типов,...?

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

WH> И чем он тогда будет от С++ отличатся кроме небольшого различия в синтаксисе?

Давай кривую аналогию? На что похож компилятор с C++, пытающийся увеличить скорость компиляции...

Ещё одна. Почему французы упорно говорят на французском, немцы — на немецком, а мы на русском? Хотя, конечно, есть исключения...

WH>С++ это язык для создания других языков. Причем при наличии определенных знаний и воображения это делается очень легко.

Я тоже могу написать библиотеку для создания других языков по тому или иному принципу. Даже писал в своё время. Даже в Сети найти можно и не одну. Так что нет тут монополии у C++, плюс смотри выше.

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

WH>Во первых я сказал грубо.

А ты не груби, , будь объективнее.

WH> Во вторых куда это ты ее приложить собрался? Уж не к задаче ли где 90% ГУИ?


Dll и Exe. То, что получается на выходе Дельфи. Этим многое сказано. И кроме того, уж не поклонник ли ты "лаконизму командной строки"? Не думаю, что надо объяснять, чего мы достигли в ПО и компьютерах благодаря G.U.I.

Так что это просто близость к человеку, удобному восприятию информации, удобной постановке задачи и получению результатов. Что такое "прикладная программа", думаю, понимаешь.

WH> И всеравно против шарпа не тянет. Ну ни как.

Не так. И вот почему. В существующих ОС (ну может Win2003 server исключение) нет встроенной поддержки .NET. Ну нет её. Надо качать да ставить фреймворк. Подавляемое большинство людей лениво и ничего качать не будет. Более того, скажет, что делать надо всё на существующей базе, потому как это вопрос денег, дополнительных денег. И, может быть, они и согласятся, как это круто — .NET, но ленивы и опять же деньги. "И что, скажут, вы без этого новомодного веяния не можете? Так мы к другим пойдём!..".

Так что сейчас C# сдерживается очень сильно. Вот пройдёт время, MS сделает ротацию своих линеек ОС... Тогда можно будет говорить о прогрессе C#. А так пока, как он ни хорош, другие средства разработки ничего не потеряли.

WH>>>А на поле нативных высокопроизводительных ресурсожрущих приложений дельфя против С++ ой не смешите мои тапочки.

Ну а кто сейчас заботится об оптимизации? Студия 2003 стартует быстро, но открывает проект (Янус) ого-го как долго. Дельфи 7 стардует долго, зато проект (сравнимый по) открывает быстро. Уж не знаю, кт оиз них там всё перебирает, кто только открытые мною 8 окон. Это при том, что Студия для показа форм (design) подшуршовывает, а Дельфи нет.

WH>...В ОП от этого шаблоны не появится.

На Королевстве Дельфи читал, как с помощью include (используя простую type-подмену типов) можно достичь того же эффекта. Но это так, добавление. Ни сколько не пытаюсь аргументированно спорить по вопросу полезности шаблонов.

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



A>Как я с тобой согласен! И в C# подобная дребедень. using немного спасает ситуацию, но только в самых простых случаях. Особенно меня прикалывает тот факт, что IDispose.Dispose() может выбросить исключение. После этого я не могу понять как на C# можно писать надежные программы.

Вот-вот. Тут народ что-то рассказывает про отсутствие в C# шаблонов, перегрузки некоторых операторов и прочей лабудени. В то время как (на мой взгляд) самый реальный шаг назад — отсутствие надёжного механизма детерминированного освобождения ресурсов. using нифига ситуацию не спасает, т. к.:
1) Каждый раз при создании объекта надо проверять поддержку IDisposable = лезть в MSDN. (Все классы не запомнишь.)
2) Попытки систематически использовать using приводят к конструкциям вида:
using(....) {
using(...) {
using(...) {
.
.
.
3) Dispose() может выбрасывать исключения
4) Рекомендательный характер вызова Dispose(). Поубивал бы за это . Dispose() в половине случаев оставляется самой FCL на попечение Finalize, который, разумеется, вызывается, когда мало памяти, а не того ресурса, которого не хватает.

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

WH>ТИПИЗАРОВАНОСТЬ такое слово знаешь? А можешь мне сказать какая структура данных лежат в основе TList?
Это для С++ программеров такое слово в новинку, а для пишущих на OP это само собой разумеется. Строгая типизация была в языке с самого начала.

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

S>> Время рассудит, но Delphi найдет свою нишу в Net да и у Delphi с C# намного больше общего чем у C# с С++, да и M$ помоему не особо горит желанием развивать Native компиляторы.
WH>Скорее C# окончательно добьет дельфю, а на счет нативных компиляторов это ты зря VC++7.1 практически полностью держит стандарт и оптимизитор у него весьма крутой.
C# и Delphi — это близнецы братья (или сестры?)

WH>>>Вот только пока далеко не все лучшие идеи используются в шарпе.
S>> Например???? Шаблоны будут, что еще???
WH>Ну на эти шаблоны еще посмотреть надо. Еще надо подключение реализации. Короче я жду .NET 2 там будет видно.
WH>А сейчас все очень убого. Почти на уровне дельфи.
Какое самомнение! Ну почти господь бог. Истина в последней инстанции. А хотя бы задумался с чего бы это в Java уже почти 8 лет нет шаблонов. Разговоры идут, планы ввода есть. А реализаций нет. И в C# тож самое. Видно не все так просто с надежностью. А ведь для разработки именно НАДЕЖНЫХ приложений создавались эти среды.
А вот интересно! После ввода шаблонов в С# куда они будут отнесены: к безопасному программированию или нет?

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

A>Dll и Exe. То, что получается на выходе Дельфи. Этим многое сказано. И кроме того, уж не поклонник ли ты "лаконизму командной строки"? Не думаю, что надо объяснять, чего мы достигли в ПО и компьютерах благодаря G.U.I.
Я недовно видел прогу написаную на WTL дельфи отдыхает.

WH>> И всеравно против шарпа не тянет. Ну ни как.
A>Не так. И вот почему. В существующих ОС (ну может Win2003 server исключение) нет встроенной поддержки .NET. Ну нет её. Надо качать да ставить фреймворк. Подавляемое большинство людей лениво и ничего качать не будет. Более того, скажет, что делать надо всё на существующей базе, потому как это вопрос денег, дополнительных денег. И, может быть, они и согласятся, как это круто — .NET, но ленивы и опять же деньги. "И что, скажут, вы без этого новомодного веяния не можете? Так мы к другим пойдём!..".
Ты еще скажи что дельфевый рантайм входит в поставку винды статическая линковка не хило утяжеляет ехешник что при частом обновлении софта выдет бОльшим траффиком.

A>Так что сейчас C# сдерживается очень сильно. Вот пройдёт время, MS сделает ротацию своих линеек ОС... Тогда можно будет говорить о прогрессе C#. А так пока, как он ни хорош, другие средства разработки ничего не потеряли.
Не гони. Выкачать один раз фреймворк если прога ДЕЙСТВИТЕЛЬНО нужна не проблема. А если надо разрабатывать с нуля прогу из дельфевой ниши то на шарпе дешевле и сильно.

WH>>>>А на поле нативных высокопроизводительных ресурсожрущих приложений дельфя против С++ ой не смешите мои тапочки.
A>Ну а кто сейчас заботится об оптимизации?
Я.
A>Студия 2003 стартует быстро, но открывает проект (Янус) ого-го как долго. Дельфи 7 стардует долго, зато проект (сравнимый по) открывает быстро. Уж не знаю, кт оиз них там всё перебирает, кто только открытые мною 8 окон. Это при том, что Студия для показа форм (design) подшуршовывает, а Дельфи нет.
А это все к чему?

WH>>...В ОП от этого шаблоны не появится.
A> На Королевстве Дельфи читал, как с помощью include (используя простую type-подмену типов) можно достичь того же эффекта. Но это так, добавление. Ни сколько не пытаюсь аргументированно спорить по вопросу полезности шаблонов.
Ну видел. А ты их применял? А я вот видел примерчик К томуже это даже до С++ного препроцессора не дотягивает, а ты шаблоны...

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

WH>>Ну ты эта зайди в форум по С++ и спроси почему нельзя использовать void*...
A>То есть вопрос класса "goto или без goto"?
Да. Только я скажу по другому. Класса прямые руки или кривые.

WH>>ТИПИЗАРОВАНОСТЬ такое слово знаешь? А можешь мне сказать какая структура данных лежат в основе TList?
A>Знаем. В основе — массив указателей.
Как гибко А если критична произвольная вставка/удаление? А если поиск? А если вставка/удаление с конца/начала?
A>Для хранения списка чего угодно.
Вот тут и начинаются проблемы.
A>Потому что поддержка вариантов пришла позже.
А вот это совсем изврат
A>Да и в связи сс динамическими массивами поддерживать вариантный TList (а он-то будет типизированным/автопреобразующимся) неактуально.
A>А вот для списка объектов Борланд быстро допёр сделать TObjectList. Я такую штуку в D3 или D4 сам писал, т.к. не было её.
A>В TOjectList храним потомков TObject, список может выступать Owner для этих потомков с вытекающими. При необходимости хранить одинаковых потомков можно заместить свойство Items[].
И как можно добится автоматического уничтожкния при удалении из списка? А если объект надо хранить в нескольких списках? А если мне нужен не список, а КЧ дерево?

A>Понимаю как полиморфизм и инкапсуляцию.
WH>>...Такие помошники позволяют не задумоватся о исключениях, их использование прозрачно и не навязчиво, пишутся раз и навсегда.
A>См. ответ выше. ООП тоже понимает не задумываться о других кирпичиках. Но тут ключевой момент, что чтобы не задумываться, надо сначала отладить.
Это у вас в паскакале надо долго и нудно извращаться, а потом долго и нудно отлаживать. В С++ все просто.

template<class T>
struct co_array_t
{
    co_array_t(size_t count)
        :count_(count)
    {
        if(ptr_=(T*)CoTaskMemAlloc(sizeof(T)*count_))
            new(ptr_)T[count_];
        else
            _com_issue_error(E_OUTOFMEMORY);
    }
    ~co_array_t()
    {
        if(ptr_)
        {
            for(size_t i=0;i<count_;++i)
                ptr_[i].~T();
            CoTaskMemFree(ptr_);
        }
    }
    T& operator[](size_t i)
    {
        return ptr_[i];
    }
    T* begin()
    {
        return ptr_;
    }
    T* end()
    {
        return ptr_+count_;
    }
    T* detach()
    {
        T* ptr=ptr_;
        ptr_=0;
        return ptr;
    }
private:
    T* ptr_;
    size_t count_;
};

Итого: Автоматический массив который можно использовать со вмесно с алгоритмами STL, размещенный при помощи комовского аллокатора что дает возможность возвращать его из методов комсервера.
Ну и что тут отлаживать?
WH>>Слабо на дельфях написить такого помошника?
A>Может и нет, если постановку задачи сделать словами, или хотя бы на C#. А то слова вроде знакомые, а вместе — чехарда в голове.
Ни на дельфе ни на шарпе не реализуемо.
A>Только надо ли?
Однозначно.

WH>>Ой не надо на дельфе начинается try finaly hell.
A>Ну, ну. Я вот тоже не понимал, зачем не просматривается иерархии в блоках try и catch в C#.
Чаво???
A>В обоих случаях эти блоки просты, и их понимание и правильное использование приходит с опытом.
Ты что думаешь я не понимаю try finaly? Напрасно. Просто я не хочу освобождать ресурсы РУЧКАМИ. В С++ за этим следит компилятор.

procedure some;
begin
  try
    захватываем ресурсы
    работаем
  finaly
    освобождаем ресурсы ручками
  end;
end;

void some()
{
  захватываем ресурсы
  работаем
  компилятор генерирует код освобождающий ресурсы
}

Разница заметна или еще нет?
Вот это я и называю try finaly hell ибо каждый раз когда захватываем ресурсы мs должны их отдовать ручками и если мне не изменяет сколероз try finaly не ловит exit.

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

WH>>Я бы сказал безнадежно уступает.
A>Я бы нет. А почему, ответил в нашей беседе.
Ни чего ты не ответил.

WH>>И чтоже его может спасти? Добавят шаблоны, множественное наследование, приведут в порядок систему типов,...?
A>Слухи о смерти сильно преувеличены, потому как есть инструмент, есть область применения того, что можно сделать инструментом, есть те, кто умеет пользоваться инструментом.
В эту область применения пришол гораздо болие мощьный инструмент.

WH>> И чем он тогда будет от С++ отличатся кроме небольшого различия в синтаксисе?
A>Давай кривую аналогию? На что похож компилятор с C++, пытающийся увеличить скорость компиляции...
На С++ компилятор
A>Ещё одна. Почему французы упорно говорят на французском, немцы — на немецком, а мы на русском? Хотя, конечно, есть исключения...
Это еще кривее. Разговорные языки по функциональности практически равноценны. Но С++ и делфи... ой не смешите мои тапочки.

WH>>С++ это язык для создания других языков. Причем при наличии определенных знаний и воображения это делается очень легко.
A>Я тоже могу написать библиотеку для создания других языков по тому или иному принципу.
А ну-ну. Напиши boost::spirit на дельфе. Можешь даже не пытаться. Не выдет.
A>Даже писал в своё время.
Ну дай посмотреть.
A>Даже в Сети найти можно и не одну.
Линки пожалуйста.
A>Так что нет тут монополии у C++, плюс смотри выше.

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

A>>Ещё одна. Почему французы упорно говорят на французском, немцы — на немецком, а мы на русском? Хотя, конечно, есть исключения...
WH>Это еще кривее. Разговорные языки по функциональности практически равноценны. Но С++ и делфи... ой не смешите мои тапочки.

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

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

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

FWP>Какое самомнение! Ну почти господь бог. Истина в последней инстанции. А хотя бы задумался с чего бы это в Java уже почти 8 лет нет шаблонов. Разговоры идут, планы ввода есть. А реализаций нет. И в C# тож самое. Видно не все так просто с надежностью.


Как раз с надежностью-то проблем нет (шаблоны есть, скажем, в Ada и SDL, которые, вообще говоря, надежны), есть проблема со сложностью реализации поддержки шаблонов. Откройте стандарт С++ и посмотрите описания name resolution-а. В этом, кстати, и была проблема с тем, что очень долго не существовало компилятора поддерживающего С++ в полном объеме.
Name resolution в Java-е прост и ясен, внедрение шаблонов повлечет черезмерное его усложнение.

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

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

WH>>ТИПИЗАРОВАНОСТЬ такое слово знаешь? А можешь мне сказать какая структура данных лежат в основе TList?
FWP>Это для С++ программеров такое слово в новинку, а для пишущих на OP это само собой разумеется. Строгая типизация была в языке с самого начала.
Во первых: Не путай С и С++ это разные языки. С++ с самого начала строго типизирован.
Во врорых посмотри на дельфевые контейнеры...

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

WH>>Скорее C# окончательно добьет дельфю, а на счет нативных компиляторов это ты зря VC++7.1 практически полностью держит стандарт и оптимизитор у него весьма крутой.
FWP>C# и Delphi — это близнецы братья (или сестры?)
Общего у них только то что редактор форм немного похож.

WH>>Ну на эти шаблоны еще посмотреть надо. Еще надо подключение реализации. Короче я жду .NET 2 там будет видно.
WH>>А сейчас все очень убого. Почти на уровне дельфи.
FWP>Какое самомнение! Ну почти господь бог.
А что не похож?
FWP>Истина в последней инстанции.
Аргумента против.
FWP>А хотя бы задумался с чего бы это в Java уже почти 8 лет нет шаблонов.
Ибо реализовать их нАмного сложнее чем кажется.
FWP>Разговоры идут, планы ввода есть. А реализаций нет. И в C# тож самое. Видно не все так просто с надежностью.
С надежностью то как раз все хорошо, а вот реализовать это...
FWP>А ведь для разработки именно НАДЕЖНЫХ приложений создавались эти среды.
А это тут причем?
FWP>А вот интересно! После ввода шаблонов в С# куда они будут отнесены: к безопасному программированию или нет?
К безопасному. К томуже в шарпе шаблоны не будут обладать такойже мощью как в С++.

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

A>>Так что сейчас C# сдерживается очень сильно. Вот пройдёт время, MS сделает ротацию своих линеек ОС... Тогда можно будет говорить о прогрессе C#. А так пока, как он ни хорош, другие средства разработки ничего не потеряли.
WH>Не гони. Выкачать один раз фреймворк если прога ДЕЙСТВИТЕЛЬНО нужна не проблема. А если надо разрабатывать с нуля прогу из дельфевой ниши то на шарпе дешевле и сильно.

Это получится как в известном ералаше: "Ты куда? А батарейки?". Очень плохой тон, когда программа требует для своей работы дополнительного софта.

WH>>>>>А на поле нативных высокопроизводительных ресурсожрущих приложений дельфя против С++ ой не смешите мои тапочки.
A>>Ну а кто сейчас заботится об оптимизации?
WH>Я.
Что-то помнится, что рост exe-шника за счет шаблонов Вас не напугал. Да и в чем Дельфи так не оптимально? Работает во многом даже быстрее.

Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, akasoft, Вы писали:
WH>>>Ну ты эта зайди в форум по С++ и спроси почему нельзя использовать void*...
A>>То есть вопрос класса "goto или без goto"?
WH>Да. Только я скажу по другому. Класса прямые руки или кривые.

Видимо в основе у нас лежат диаметрально противоположные школы, поскольку, если Вас послушать то Сшный union это вообще ужас какой-то который надо убрать подальше. А я не представлаю себе нормальной работы без возможности смотреть на память так как это угодно мне, а не компилятору!

Что-то вы граждане поклонники С очень непоследовательны в своих заявлениях. Единственное исключение пожалуй Wolfhound, который усиленно гнет свою тему, но, если честно, я с ним в корне не согласен. Так нравится типобезопасность и обобщенность, так может какой-нибудь скриптик подходящий поискать?

Остальные же "защитники" С++ начинают кидаться лозунгами типа "С для инженеров, Pascal для обучения". Причем сильно напирая на низкоуровневость С по сравнению с паскалем, причем именно С, а не С++. Т.е. мы получаем прямой доступ к памяти без всяких там смартпойнтеров и т.д. т.е. это точкка зрения полностью противоположная точке зрения Wolfhound'а.

И еще. Очень часто в потверждение превосходства С++(а именно VC++), над Дельфи люди начинают сравнивать его(С++) с BCB. Я этим BCB в жизни не пользовался и насколько понял не зря, поскольку, видимо, это хуже даже Visual Studio.

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

WH>А какое отношение .NET имеет к сабжу?
Имеет и очень большое. Прежде всего как соотношение его к Delphi и С++.
Если брать иерархию классов,их продуманность, поддержка интерфейсов и компонентность то все это из Delphi.
Если в С++ разницы между структурами и классами практически нет, то классы в Net однозначно ссылочные как в Delphi. Структуры же играют по сути роль классов С++. Реализация множественного наследования в структурах легко проходит через агрегирование (включение структур как полей и при этом ссумарная структура получается аналогичной как при множественном наследовании) без конфликтов при одинаковых именах функций. А вот этого в Delphi нет, а нужно было бы, для скорости.
Но Структуры Net поддерживают интерфейсы (хотя боксинг и убивает все премущество, но позволяеи работать как с объектом). Хотя на данном этапе в Net и нет шаблонов , то универсальность достигается за счет поддержки объетов определенных интерфейсов или перегрузки соответствующих функций, так как все объекты наследуются от одного общего предка как в Delphi. Скорость при этом падает в 2 раза, но намного удобнее и читабельней чем в шаблонах.
Твои любимые СмартПоинтеры решены так же как и в Delphi наследники TInterfeicedObject за счет автоматического подсчета ссылок и GC.
Перегрузка операторов то же не помешала бы в Delphi.
Программировать можно на чем угодно, но на данном этапе выбор определяется набором компонент для решения той или иной задачи и знанием технологий. По сути языки не играют решающей роли и само программирование выхолащивается. Яркий пример 1С и Васик и зарплата у них выше чем у большинства Сишников.
Просто Delphi изначально занял среднюю позицию. Но время идет и ....
А вот при грамотном внедрении Net как офисные программы, базы данных (Юкон) может повернуть все вспять.
И при этом при кажущейся простоте C# он намного сложнее и гибче чем С++.
Сразу оговорюсь, что мои познания С++ весьма поверхностны (но читаю сищный код бегло), поэтому прошу извинить меня за возможные неточности. Но суть заключается в какой мере повлияли на новую платформу идеи заложенные в этих двух языках. А в том, что Net уже в скором времени займет главенствующие роли у меня лично сомнений не вызывает.

Hello, DOOM!
You wrote on Mon, 15 Sep 2003 09:48:56 GMT:

D> Что-то вы граждане поклонники С очень непоследовательны в своих
D> заявлениях.

Что-то вы гражданин DOOM не менее непоследавательны в своих заявлениях То у вас C и C++ — одно и то же, то — разное

D> Единственное исключение пожалуй Wolfhound, который усиленно
D> гнет свою тему, но, если честно, я с ним в корне не согласен. Так
D> нравится типобезопасность и обобщенность, так может какой-нибудь
D> скриптик подходящий поискать?

А что, ты можешь предложить хоть один широко распространенный скриптовый язык со строгой статической типизацией? Если нет, то ты нифига не понял из того, что тебе говорил Wolfhound.

D> Остальные же "защитники" С++ начинают кидаться лозунгами типа "С для
D> инженеров, Pascal для обучения".

Так защитники C или C++? Потому что "C vs. C++" — тоже вполне неслабая тема для holy war.

D> Причем сильно напирая на
D> низкоуровневость С по сравнению с паскалем, причем именно С, а не С++.

C++ позволяет обходиться с памятью столь же непосредственно, как и С. Но именно позволяет, а не принуждает. Кстати, и VB вплоть до 6'й версии включительно тоже позволял напрямую работать с памятью — но это не означало, что надо всегда так делать.

D> Т.е. мы получаем прямой доступ к памяти без всяких там смартпойнтеров и

Чем, с твоей точки зрения, доступ к памяти с помощью смартпойнтеров отличается от прямого доступа к памяти?

D> И еще. Очень часто в потверждение превосходства С++(а именно VC++), над
D> Дельфи люди начинают сравнивать его(С++) с BCB. Я этим BCB в жизни не
D> пользовался и насколько понял не зря, поскольку, видимо, это хуже даже
D> Visual Studio.

Вот только не надо валить в одну куча язык и средства разработки.

Best regards,
Sergey.

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

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

S>>>> Для различного рода задач нужны свои инструменты. Шаблоны, Inline, сматрпоинтеры очень хорошая вещь которой мне не достает, но для различного рода задач можно абсолютно безболезненно без каких либо затруднений обходится без них.
WH>>>Это где? В простеньком калькуляторе?

S>> Ну это ты загнул. Любая БД работает с нетипизированной памятью и почему-то большенству нравится, хотя скорость желает быть в десятки сотни и тысячи раз больше.
WH>И в какой БД ты не типизированую пимять нашол?
Как по твоему обрабатываются записи таблицы являющиеся некой структурой ?????? Наверное на лету генерятся структуры и на их основе с использованием шаблонов генерятся и компилируются алгоритмы выборки????
А мои примеры как раз из этой области.
А вот в Юкон это действительно воможно используя премущество Net.
И по поводу C# и Delphi.Net не рано ли говорить кто кого вытеснит????