Форум Всеукраїнської інтернет-олімпіади NetOI

Кароч, Jura не понял, в чем разница между СТЛ и ООП. СТЛ - это стандартная библиотека шаблонов, там есть много полезных вещей, которые помогают программисту (напр, динамические строки, списки и т.д.). Да, они используют динамическую память и в принципе замедляют работу программы. Но!
1. на различных конкурсах, где важна скорость набора программы (ТопКодер, ТТБ, АСМ, etc) - это незаменимый помощник
2. ООП!=СТЛ (ООП<>СТЛ)
3. что значит стабильность на олимпиаде не нужна???! И на олимпиаде тоже программа должна четко и корректно.

Ты на micro$oft не ровняйся, они ось без глюков сделать не могут, а ты про компилятор говоришь! Если тебя интересует нормальный компилятор, возьми Borland C++Builder или GNU GCC. Надежность проверена!

А ФриПаскаль используется на этой олимпиаде именно из-за кроссплатформенности. Из-за того, что паскаль имеет множество расширений, поэтому одноплатформенные компиляторы не подходят - разные оси.

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

Стабильность - не в том смысле, ну да ладно.

Насчет компиляторов, то у micro$oft`а может и глючный компилятор, но быстрый. Билдеру до него далеко, Билдер "даже" медленнее Делфи. Насчет gcc - то это скорее выбор для кроссплатформености, как и ФриПаскаль.

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

Но это просто мои рассуждения, моё ИМХО. Поэтому просьба не пинать - а подумать над этим...

Ээм.. Что значит - нагло слизанно?
1) Это все равно что сказать - арифметика была "нагло слизана" - ведь принципы ООП одни на всех.
2) Насчет скорость gcc - то это был простой синтетический тест.
3) КАКИЕ ограничения у паскаля?? Очень бы хотелось узнать..

Вот пример ограничения С++ в ООП:

Есть:
объект А
объект B (наследник А)
объект С (наследник А)
объект D (наследник А)

A B C D - очень разные объекты, у каждого определен метод assign, который копирует в текущий объект информацию из объекта, который подаеться в этот метод. Т.е. происходит присваивание объектов.

Есть массив А. (в котором могут храниться как объекты типа А, так и наследники - B,C,D)

Надо написать процедуру добавления в этот массив любого из классов (A,B,C,D)

В Делфи делаеться так:

type
MetaClass=class of A; // это у нас метакласс для типа А, и его наследников

var
AAA:array of A;

procedure AddToArray(Obj:A);
var l:integer;
     Meta:MetaClass;
begin
l:=length(AAA);
Setlength(AAA,l+1);     // это не важно - можно было и через property, но я для наглядности

Meta:=MetaClass(Obj.ClassType); // приведем глобальный метакласс к локальному MetaClass

// тут НУЖНО (по условию) сделать именно копирование, а не указатель передать - мало что мы будем делать с объектом вне этой процедуры.
AAA[l]:=Meta.Create;
AAA[l].assign(Obj);

end;

Вот вам и "ограничения" паскаля..

Про метаклассы. Во первых: что ты получил в результате в массиве AAA? Кучу разнородных объектов. Тот еще подарок. Такая гадость вообще может понадобиться только в одном случае: ты потом пройдешься по ним виртуальными функциями-членами. Кстати, через метаклассы можно вызывать виртуальные функции-члены?
В С++ вместо метаклассов с успехом работают ссылки и указатели. На примере с массивом все же часто удобнее использовать auto_ptr, чтобы не заботиться о удалении элементов. Кстати, если ты заметил, то метаклассы тоже используют динамическую память.
По поводу же ООП. Не знаю, как в делфи, но в С++ объекты не обязаны выделяться в куче. Объекты можно спокойно задавать так же, как и переменные элементарных типов. Про ООП на олимпиадах я уже писал 2 раза. Почитай мои посты в конце концов. Про ограничения в языках и написание чего угодно и на чем угодно я тактично умолчу: что-то не слышал я про выход ОС на бейсике, да и на паскале...

Jura
Неделю назад в чате ттб перед контестом пытались написать на делфе аналог такого кода:

#include <iostream>
class cl {
public:
    int val;
    int count_func() {return val*2;}
};
int main() {
    int cl::*var=&cl::val;
    int (cl::*func)()=&cl::count_func;
    cl obj;
    obj.val=5;
    std::cout<<obj.*var<<" "<<(obj.*func)()<<std::endl;
    return 0;
}

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

int cl::*var=&cl::val;
int (cl::*func)()=&cl::count_func;

Это создание указателя на функцию-член класса. В самом простом случае указатель на фунцию-член хранит смещение члена относительно указателя this.
переменная var типа
int cl::*
может указывать на любой член типа инт класса cl.
Использоваться этот указатель может только на конкретном екземпляре класса obj. Попробую пояснить другим примером:

#include <iostream>
class my_class {
public:
    int x,y;
};
int main() {
    my_class obj;
    int my_class::*var;
    obj.x=1;
    obj.y=2;
    var=&my_class::x;
    std::cout<<obj.*var<<std::endl; // выдаст 1
    var=&my_class::y;
    std::cout<<obj.*var<<std::endl; // выдаст 2
    return 0;
}

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

2Джулгаков Дмитрий
Я то же самое написал