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

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

DOO>>1-е Какого черта пости для каждого объекта я должен писать такую тучу конструкторов.
WH>Не для каждого, а только для тех в которых ты мудришь с ресурсами. А их поверь очень мало.
WH>Ибо нужно только один раз написать класс хозин какого либо ресурса и дальше пользоваться им.
WH>В 99% случаев компилятор генерирует правильные конструктор копирования и копирующие присваивания.
DOO>>2-е Почему в объекте сыне я могу вызвать конструктор родителя только перед выполнением своего конструктора.
WH>Потомучно в дельфе нет конструкторов. Те то что там называется конструктором в самом деле является лиш процедурой которая вызывается после создания объекта.
DOO>>3-е (к другому вопросу) Универсальная сортировка это TList.Sort.
WH> Еще раз отсортируй мне массив.
WH>Ы?

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

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

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

_>>>Не могу представить себе задачу, для которой C++ с отключенными exceptions и RTTI будет хуже, чем чистый C.
_O_>>Иногда не нужны ни виртуальные функции, ни RTTI ни даже динамическая память.

_>То есть для таких задач не надо использовать C, потому что в нем есть malloc? Никто же не заставляет использовать ненужную функциональность, а про RTTI и exceptions, добавляющие оверхед, я уже написал двумя строками выше.

Меньше функциональности — проще компилятор, зачем стрелять из пушки по воробъям ?

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

_>Разве? Пять лет мучался с ТКМ-51, где архитектура не очень-то заточена под C, даже push кладет два байта в стек в неправильном порядке. Кстати, приходилось использовать на тамошнем C структуры указателей на функции, чтобы эмулировать VMT. Или это уже на МФК...

Есть С заточенные под архитектуру. А вообще, в данном случае лучше рассматривать С как язык кодогенерации из чего-то другого.

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

_>>То есть для таких задач не надо использовать C, потому что в нем есть malloc? Никто же не заставляет использовать ненужную функциональность, а про RTTI и exceptions, добавляющие оверхед, я уже написал двумя строками выше.
_O_>Меньше функциональности — проще компилятор, зачем стрелять из пушки по воробъям ?

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

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

_>>Разве? Пять лет мучался с ТКМ-51, где архитектура не очень-то заточена под C, даже push кладет два байта в стек в неправильном порядке. Кстати, приходилось использовать на тамошнем C структуры указателей на функции, чтобы эмулировать VMT. Или это уже на МФК...
_O_>Есть С заточенные под архитектуру.

Если они держат хотя бы C89, то плюсы под эту же архитектуру затачиваются так же легко — в отсутствие exceptions вся разница только в удобстве программирования, на плюсах надо писать меньше буковок для решения той же задачи и получать более поддерживаемый и расширяемый код.

_O_>А вообще, в данном случае лучше рассматривать С как язык кодогенерации из чего-то другого.

У нас так и было. Но рантайм и драйвера к платам ввода-вывода приходилось писать, естественно, на C и ассемблере. Ассемблер оставим в покое, но в сишном коде и проявлялись все неудобства по сравнению с плюсами, на которых был написан кросс-компилятор и IDE.

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

S> Вопрос тебе сортировку массивов элементарных типов или сложных структур.
И тех и других в одном флаконе.
S>Иногда легче применять ссылочные массивы с функцией сравнения или при динамической сортировке применять Б деревья.
Типа std::map и std::set это из другой оперы у меня есть массив хочу его отсортировать.
S>Все о чем ты говришь с применением шаблонов легко решается с помощью Replace или заменой типа соответсвенно скопировав модуль и переименовав его. Не очень сложная задача.
cope/paste это не решение это проблема.
S>Можно вспомнить про GetIdsOfNames и Invoke, MakeCreateInstace. Несовместимост Дельфийных и Сишных классов. Суть в совместимости. И почему сишники пишут на Delphi совмещаяя с С++????? А их огромное множество.
Ни чего не понял.

WH>Ты от ответа не уходи ты функцию напиши.

TList.Sort — вот эта функция.

FWP>>1) На Delphi ошибки "выдаются залпом" с первой версии.

VD>Сказки расказываем в милиции. Первая дельфи ошбки по одной отплевывала.

В третьей точно залпом было. Правда, мало кто этим пользовался, по той причине которую я уже упоминал. Быстрее Ctrl+F9 нажать, чем табуляции да стрелочки.

FWP>>2) Прогресс компиляции существует с первой версии.

VD>Вот тут уже не помню. Но по умолчанию во всех версиях выключено.

Ага. Это точно во второй было. Включи, будь так любезен.

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

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

S>> Вопрос тебе сортировку массивов элементарных типов или сложных структур.
WH>И тех и других в одном флаконе.
S>>Иногда легче применять ссылочные массивы с функцией сравнения или при динамической сортировке применять Б деревья.
WH>Типа std::map и std::set это из другой оперы у меня есть массив хочу его отсортировать.
S>>Все о чем ты говришь с применением шаблонов легко решается с помощью Replace или заменой типа соответсвенно скопировав модуль и переименовав его. Не очень сложная задача.
WH>cope/paste это не решение это проблема.
S>>Можно вспомнить про GetIdsOfNames и Invoke, MakeCreateInstace. Несовместимост Дельфийных и Сишных классов. Суть в совместимости. И почему сишники пишут на Delphi совмещаяя с С++????? А их огромное множество.
WH>Ни чего не понял.

Что именно не понятно??? По сортировке тот же QuickSort + функция сравнения + размер записи легко решается без всяких шаблонов (см _DynArrayXXX в System). То что доступ к интерфейсам идет через процедуры а не методы объекта не есть хорошо. То есть для каждого объекта програмно в памяти создается процедура заглушка которая уже вызывает метод объекта передавая в нее данные объекта (Self). По поводу MakeObjectInstace опять для каждого экземпляра нужно городить функцию заглушку так как в API нет классов. А сишные классы не совместимы с Дельфийными. И можно сколько угодно говорить о достоинствах одного языка перед другим но если сама база трухлява ничего путного сделать нельзя.

По поводу Copy-Paste-Replace по скорости то же самое и по объему генерирумого кода. В свое время стандартном Паскале (Виртовском на ДК-2) когда не было динамических массивов итд все ограничения языка легко обходились и не вызывали как у ВАС такого раздражения.

Но меня лично до появления Net раздражало не совместимость языков. Я не думаю ( а во многих случаях знаю), что будь так плох Delphi как ВЫ говорите Сишники по каким то причинам на него переходили или совмещали два языка. В Net хоть засовмещайся и выбирай тот который более всего подходит для решения конкретной задачи.
В любом случае приходится изучать несколько Языков,хотя бы ради того что бы изучать чужой опыт.

В любом случае "КАЖДОМУ СВОЕ". И не нужно спорить и отдаляться. Все Мы выполняем одну и туже задачу только на разных языках.

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

WH>>Ты от ответа не уходи ты функцию напиши.
M>TList.Sort — вот эта функция.
Ты ручками сортировку написать можешь?
Сортировка(на дубость алгоритма не смотрим лень было нормальный писать)

template<class Iter, class Cmp>
void select_sort(Iter begin, Iter end, const Cmp& cmp)
{
    for(;begin!=end;++begin)
    {
        Iter cur=begin, best=begin;
        for(++cur;cur!=end;++cur)
            if(cmp(*cur, *best))
                best=cur;
        if(best!=begin)
            std::iter_swap(best, begin);
    }
}
template<class Iter>
void select_sort(Iter begin, Iter end)
{
    select_sort(begin, end, std::less<typename std::iterator_traits<Iter>::value_type>());
}

Функция помошник

template<class T, size_t N>
T* end_of_array(T(&arr)[N])
{
    return arr+N;
}

Тест

//Встроеное сравнение
struct test1
{
    test1(int i)
        :i_(i)
    {}
    int i_;
    bool operator<(const test1& lhs)const
    {
        return i_<lhs.i_;
    }
};
//Внешний компатор
struct test2
{
    test2(int i)
        :i_(i)
    {}
    int i_;
};
struct test2_less
{
    bool operator()(const test2& rhs, const test2& lhs)const
    {
        return rhs.i_<lhs.i_;
    }
};
int main()
{
    std::string arr_string[]={"sdfs", "xvc", "afs", "sdf", "w3fd", "yeq"};
    int arr_int[]={12, 4, 8, 3, 5, 24, 63, 9};
    double arr_double[]={12, 4, 8, 3, 5, 24, 63, 9};
    test1 arr_test1[]={12, 4, 8, 3, 5, 24, 63, 9};
    test2 arr_test2[]={12, 4, 8, 3, 5, 24, 63, 9};
    select_sort(arr_string, end_of_array(arr_string));
    select_sort(arr_int, end_of_array(arr_int));
    select_sort(arr_double, end_of_array(arr_double));
    select_sort(arr_test1, end_of_array(arr_test1));
    select_sort(arr_test2, end_of_array(arr_test2), test2_less());
}

Изобрази тоже самое на паскакале.

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

WH>Вот только приходится использовать какойнибудь изварат типа TList либо писать ручками...

А почему TList это изврат, а std::vector нет? По мне дак TList поудобнее...

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


S>Ты придумай, а я постараюсь тебе показать, где ты неправ
S>Best regards,
S> Sergey.

Пожалуйста:

TAnotherClass = class(TComponent)
...
TMyClass = class(TComponent)
 constructor Create(Owner:TAnotherClass);
...

constructor TMyClass.Create(Owner:TAnotherClass)
begin
  //проверяем какие-нибудь условия на Owner'a
  ...
  if good then
   inherited Create(Owner)
end;

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

DOO>А почему TList это изврат, а std::vector нет? По мне дак TList поудобнее...
Если уж сравнивать то с std::list. А вчем это он удобней? Кроме того что типо не безопасен? Не может прибивать обхекты которые в нем хранятся при удалении их из себя....

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

DOO>Пожалуйста:
Ага проверяем параметры и если не правильные то создаем частично инициализированый объект. Очень крутая логика.
Если уж так надо проверить что-то перед инициализацией базы то

struct some{};
struct base
{
    base(some*){}
};
struct derived
    :base
{
    derived(some* ptr)
        :base(test_some(ptr))
    {}
    static some* test_some(some*)
    {
        if(!is_good)
            throw bad_some_ptr();
    }
};

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

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

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

WH>>Вот только приходится использовать какойнибудь изварат типа TList либо писать ручками...

DOO>А почему TList это изврат, а std::vector нет? По мне дак TList поудобнее...

Да уж, хранить указатели на объекты, когда это нафиг не нужно, конечно удобнее.

Вот прога на C++:

std::vector<double> data;
double result;

// задаём размер
data.resize(100);

// заполняем значениями
std::fill(data.begin(), data.end(), 10.0);

// суммируем
result = std::accumulate(data.begin(), data.end(), 0.0);

Всё красиво и понятно

Теперь тоже самое на Pascal'е (заранее извиняюсь за ошибки):

var
  list : TList;
  res  : double;
  ptr  : ^double;
  i    : integer;
begin
  // создаём TList
  list := TList.Create();

  // задаём размер
  list.Count := 100;

  // интциализируем
  for i := 0 to list.Count-1 do
  begin
    New(ptr);
    list.Items[i] := ptr;
  end;

  // заполняем
  for i := 0 to list.Count-1 do
  begin
    ptr := list.Items[i];
    ptr^ := 10;
  end;

  // суммируем
  res := 0;
  for i := 0 to list.Count-1 do
  begin
    ptr := list.Items[i];
    ptr^ := 10;
  end;

  // очищаем
    for i := 0 to list.Count-1 do Dispose(list.Items[i]);

  // удаляем TList
  list.destroy();

Чёрт ногу сломит. И чем же TList удобнее?

Не забывай, что кроме std::vector в STL еще есть std::deque, std::list, std::map, std::stack, std::set и т.д. Что тебе нужно, то и применяешь.


Денис.

AD>Теперь тоже самое на Pascal'е (заранее извиняюсь за ошибки):

AD>

AD>...
AD>  // суммируем
AD>  res := 0;
AD>  for i := 0 to list.Count-1 do
AD>  begin
AD>    ptr := list.Items[i];
AD>    res := res + ptr^; // вот она - ошибочка, за которую я извинился :-)
AD>  end;
AD>

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

WH>Если уж сравнивать то с std::list. А вчем это он удобней? Кроме того что типо не безопасен? Не может прибивать обхекты которые в нем хранятся при удалении их из себя....

TList не удаляет объекты при удалении элементов т. к. он содержит не объекты, а указатели, для хранения объектов есть TObjectList.

Я не утверждаю, что работа со сложными динамическими типами данных в Delphi сделана идеально, скорее наоборот, но лекарство в виде C++/STL может оказаться хуже болезни.

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

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

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

WH>>>Вот только приходится использовать какойнибудь изварат типа TList либо писать ручками...

DOO>>А почему TList это изврат, а std::vector нет? По мне дак TList поудобнее...

AD>Да уж, хранить указатели на объекты, когда это нафиг не нужно, конечно удобнее.

AD>Вот прога на C++:

AD>[ccode]
AD>std::vector<double> data;
AD>double result;

AD>// задаём размер
AD>data.resize(100);

AD>// заполняем значениями
AD>std::fill(data.begin(), data.end(), 10.0);

Вы всегда массив одинаковыми значениями заполняете?
std::fill — готов поспорить из memcpy слеплена. В Дельфи есть Move, Copy, FillChar


AD>Не забывай, что кроме std::vector в STL еще есть std::deque, std::list, std::map, std::stack, std::set и т.д. Что тебе нужно, то и применяешь.

А в Дельфи есть еще TStack, TQueue и т.п.

AD>Денис.

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

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

DOO>>Пожалуйста:
WH>Ага проверяем параметры и если не правильные то создаем частично инициализированый объект. Очень крутая логика.

Естественно дальше предполагалось кидать Exception

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

V>Я не утверждаю, что работа со сложными динамическими типами данных в Delphi сделана идеально, скорее наоборот, но лекарство в виде C++/STL может оказаться хуже болезни.
Ни разу проблем не было. К томуже есть очень удобная библиотека www.boost.org.
STL и BOOST решают практически все задачи связаные с логикой хранения и автоматического удаления сложных динамических объектов. И не только.
Например есть std::sort может сортировать любые массивы. Ктонибудь наконец покажите как это сделать на дельфе.
И очень многое другое.

К томуже в С++ все строго типизировано -> ошибиться много труднее.
А если учитывать шаблоны то можно вобще на этапе компиляции логику проверять

template<class T, int X, int Y>
struct matrix
{
    template<class,int,int>
    friend struct matrix;

    matrix<T, Y, X> transposition()
    {
        matrix<T, Y, X> tmp;
        for(int i=0;i<X;++i)
            for(int j=0;j<Y;++j)
                tmp[j][i]=(*this)[i][j];
        return tmp;
    }
    matrix& operator+=(const matrix& that)
    {
        for(int i=0;i<X;++i)
            for(int j=0;j<Y;++j)
                (*this)[i][j]+=that[i][j];
        return *this;
    }
    matrix operator+(const matrix& that)const
    {
        matrix tmp(*this);
        return tmp+=that;
    }
//...
};
int main()
{
    matrix<int, 3, 6> m_i_3_6_a;
    matrix<int, 3, 6> m_i_3_6_b;
    matrix<int, 6, 3> m_i_6_3;
    m_i_6_3=(m_i_3_6_a+m_i_3_6_b).transposition();
    return 0;
}

Если не совпадут размерности или типы то оно не скомпилится.