Будущее C# - Философия программирования

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

ГВ>Хорошо, я готов заменить определение "...в сущности является ошибкой дизайна." как двусмысленное на "...провоцирует на дизайн, который влечёт за собой неоправданную потерю быстродействия и снижение надёжности, поскольку контроль целостности перекладывается на время исполнения."

ГВ>И что от этого изменилось?

Опять какой то налет необъективности. Почему провоцирует? Я ведь точно так же могу сказать что шаблоны провоцируют создание некомпонентных слабоконфигурируемых приложений.

AVK>>Вот когда С++ научится распознавать хотя бы свои собственные типы в рантайме из чужих модулей тогда и поговорим. А пока плюсовые шаблоны даже такого не обеспечивают.

ГВ>Образно выражаясь, плюсовые шаблоны "направлены" не в сторону runtime-распознавания типов, а в сторону "исключения ситуации" распознаывания.

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

ГВ>>>Нет проблем. Ты приписываешь мне категоричное утверждение — "использование рефлекшена = кривой дизайн".
AVK>>Я не приписываю, оно так и есть. Или ты уже от своих слов отказываешься?

ГВ>Не отказываюсь. Просто они не означают того, что ты думаешь.

Это демагогия. Я тебе уже объяснял — смысл у твоей фразы один. Все кто читает этот топик именно так его и восприняли. Да и разъяснять смысл, который ты якобы имел ввиду ты стал далеко не сразу, сначала ты доказывал что именно любое использование rtti суть кривой дизайн.

ГВ>Угу, и ещё о том, что отсутствие рефлекшена в C++ — его чудовищный недостаток.

Так и есть. В его отсутствие приходиться рожать ужасных монстров вроде СОМ. Достаточно сравнить любой СОМ-класс и аналогичный ему класс дотнета и сразу все становиться понятно. Ты конечно опять будешь возражать, мол это просто СОМ такой кривой, но вот тебе пример:

[Serializable]
public class TestClass
{
    private string _someData;
    
    public TestClass(string someData)
    {
        _someData = someData;
    }
    
    public string SomeData
    {
        get { return _someData; }
    }
}

А вот теперь напиши аналогичный класс на плюсах, так чтобы он:
1) Мог использоваться отдельно в любом проекте без исходных кодов
2) Мог сериализоваться в бинарный поток и xml
3) Его экземпляр можно было бы передать по сети
4) Обеспечивался бы контроль версий класса
5) Можно было бы создать экземпляр по имени
6) Можно было бы визуально отредактировать его свойства.
Вот когда напишешь тогда и сравним. Результаты я думаю будут забавными

AVK>>Я тебе ничего не навязываю, я тебя цитирую. Уж извини, но никакими приемами ты не докажешь что твоя абсолютно односмысленная фраза выражала что то совсем другое.

ГВ>Фраза на самом деле не "абсолютно односмысленная", поскольку содержала неопределённое понятие "в сущности".

Опять ты пытаешься перевести спор на термины. В общем неубедительно.

AVK>>Твои приравнивания просто не правомерны. Рефлекшен — это технология, RTTI это принцип. Сравнивать их нельзя.

ГВ>Но тем не менее:

ГВ>Т.е., рефлекшен реализует rtti.

Да. Где здесь противоречие?

... << RSDN@Home 1.1 beta 1 >>

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

VD>>>Вообще-то он предостовляет механизм динамического вызова.
AVK>>Это тот же самый RTTI.

VD>В RTTI — такой функиональностью и не пахло.

rtti != реализация rtti в С++. В дельфи к примеру оно тоже называется rtti.

VD>Более того это появилось то ли в дотнете, то ли в Яве.

Ну уж не в дотнете точно.

VD> В том же COM-е был только IDispatch.

Ну так это оно и есть.

... << RSDN@Home 1.1 beta 1 >>

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

AVK>>Ключевая фраза. По месту. А вот если не по месту а для затычки дырок языка то куча вложенных шаблонов никаких положительных эмоций не вызывает.

VD>Полностью соглаен. Прада согласен и с тем, что дырки есть в любых сзыках. Шарп по-мне так значительно менее дыряв чем плюсы, но тем не менее кое-чего не хватает.

Кто бы спорил.

... << RSDN@Home 1.1 beta 1 >>

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

ГВ>Э-э-э... немного не в кассу. Какой-либо API всегда известен или о нём договариваются заранее.

Вот только этот самый API либо flat либо COM, что как понимаешь не фонтан.

ГВ>Сомневаюсь, что в дотнетовском приложении ты будешь дёргать методы просто обнаружив факт их существования, игнорируя документированный API.

Да запросто. Например для той же сериализации.

ГВ>С другой стороны я понимаю, что ты имеешь ввиду. Заменить реализацию классов для изменения дизайна действительно может оказаться невозможно. Тут не исключено, что в каких-то случаях нечто типа rtti может оказаться единственным решением.

Ну наконец то.

AVK>>В смысле тот же компилятор шарпа кое какие атрибуты контроллирует при разработке.

ГВ>Я, наверное, плохо искал, но кроме наследования, другого способа гарантировать наличие custom-атрибута не нашёл.

Ну попробуй к примеру не указать для енума атрибут Flags и потом попробовать использовать его в бинарных операциях. Посмотришь что тебе компилятор скажет. Или попробуй неуказать DllImport для extern метода.

AVK>>Ну а как еще объяснить то что ты считаешь единственно верным только тот вариант дизайна который тебе известен? Опять твои суждения выглядят как — вот это рулез, а остальное кривота.

ГВ>Во-первых, я уже скорректировал своё утверждение об "ошибке" дизайна,

И сделал новое, ничуть не лучше.

Если алгоритм предполагает поиск атрибута => условность, то это уже не LSP-дизайн, => близок к кривому...

То есть если не LSP то криво.

ГВ>Во-вторых, "единственно верного" дизайна, ИМХО, не бывает.

Во, золотые слова. Если бы ты еще сам свои же утверждения помнил. А то единственно верного не бывает, но если не LSP то близок к кривому

.
Да, расшифровал бы что ли.

... << RSDN@Home 1.1 beta 1 >>

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

S>>Мы-то про вполне конкретный пример кода говорили, который, на мой взгляд, одинаково прост хоть на плюсах, хоть на шарпе.

VD>Тебе просто хочется так думть. Пару сотен килобайт такого "простого" кода и ты взывешь.

Ну не взвыл пока

Хотя сплошь и рядом такой код использую. Вот компилятор время от времени воет...

VD>Если бы небыло проблемы сложности С++, но код бы на нем писался так же шустро как на Шарпе и не приводил бы к огромному количеству ошибок.

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

VD>Выпендружи в стиле С — очень портят этот язык. Ну, а затычки дыр языка на шаблонах портят читабельность и замедляют компиляцию.

Вот компиляцию замедляют — это да. Еще и отладка сильно усложняется.
А насчет читабельности... Ну вот, например, кусок кода:

template<class F> void SetupDrawingDC(wxDC &dc, const GenericArea &area, F func)
{
    wxBrush OldBrush = dc.GetBrush();
    wxPen OldPen = dc.GetPen();
    const wxFont OldFont = dc.GetFont();
    wxColour OldTextColor = dc.GetTextForeground();
    try
    {
        wxBrush br(*wxLIGHT_GREY, wxSOLID);
        br.SetColour(area.BackColour());
        dc.SetBrush(br);

        if (area.Font().Ok())
            dc.SetFont(area.Font());
        dc.SetTextForeground(area.TextColour());
        func(dc);
    } catch (const exception& e)
    {
        const wxRect &rc_area = area.Rect();
        dc.DrawText(e.what() , rc_area.GetX(), rc_area.GetY());
    }
    dc.SetTextForeground(OldTextColor);
    dc.SetBrush(OldBrush);
    dc.SetPen(OldPen);
    dc.SetFont(OldFont);
}

void CAreaDrawer::Draw(wxDC &dc)
{ SetupDrawingDC(dc, m_area, boost::bind(&CAreaDrawer::InternalDraw, this, _1)); }

void CAreaDrawer::FlashDraw(wxDC &dc)
{ SetupDrawingDC(dc, m_area, boost::bind(&CAreaDrawer::_FlashDraw, this, _1)); }

void CAreaDrawer::DrawTip(wxDC &dc, const wxPoint &pt)
{ SetupDrawingDC(dc, m_area, boost::bind(&CAreaDrawer::_DrawTip, this, _1, pt)); }

bool CAreaDrawer::BeginDrag(wxDC &dc, const wxPoint &pt, std::vector<DragStruct> &drags)
{
    bool retval = false;
    using boost::ref;
    SetupDrawingDC(dc, m_area, boost::bind(&CAreaDrawer::_BeginDrag, this, _1, pt, ref(drags), ref(retval)));
    return retval;
}

void CAreaDrawer::_FlashDraw(wxDC &dc) { чегото рисуем }
void CAreaDrawer::_DrawTip(wxDC &dc, const wxPoint &pt) { чето рисуем }
void CAreaDrawer::_BeginDrag(wxDC &dc) { чето делаем }

Что, сильно он в читаемости от использования boost::bind и шаблонов проиграл? Или наоборот, выиграл? А в сопровождаемости?

S>>А вообще, конечно, да — но это потому, что на С++ можно некоторые более сложные вещи записать меньшим объемом кода.

VD>Только если пользоваться макросами.

Макросы тоже бывают полезны. Но значительно реже, чем шаблоны.

S>> Тут прямая аналогия с сервер-сайд скриптом,

VD>Это не прямая, а обратная аналогия.

Поясни.

VD>>>А эмуляций остуствущей в функциональности на шаблонах еще больше усугубляет это положение.

S>>Есть такое дело. Хотя если эту функциональность прятать в библиотеку с удобным интерфейсом, получается очень даже читабельно. Взять тот же boost::bind — внутри сущий кошмар, снаружи — лепота.

VD>Да не очень то. Все же проще было чуть-чуть изменить язык. При этом и кашмар был бы не нужен, и код был еще более читаемым универсальным.

А кто с этим спорит? __closure, или как она там называется, давно пора в язык. И какой-нибудь способ компил-тайм енумерации членов класса лично мне тоже очень бы пригодился. Однако возможность на ходу создать функтор с двумя аргументами вместо функции с четырьмя, предоставляемая bind'ом, пусть лучше остается в библиотеке.

VD>Факториалы мне никтогда в жизни небыли нужны.

Ну вообще можно и синус так посчитать, но компиляться дооолго будет

Просто знать о такой возможности полезно.

VD>Так что я вообще не знаю как их считать.

Если ты про частичную специализацию, то она один раз мне даже пригадилась.

При чем здесь частичная специализация? Для написания рекурсивных шаблонов обычно вполне хватает полной специализации. Хотя, конечно, часто код в отсутствии поддержки частичной специализации компилятором получается сложнее, чем с частичной специализацией. Но все равно — получается.

VD>Вот только один раз. Причем я зашел в форум по С++ и попроси, чтобы мне мой алгоритм перевели в константрный... И читать такой код ну очень не удобно.

Вот я говорю — не привык.

VD>Конечно приятно, что нет лишних действий в рантайме. Но боже мой, как же нужно переворачивать мозки чтобы разглядывать алгоритм в шаблонне?!

Это по первости только. Да и не сложнее оно, оно просто непривычное.

VD>Вот попробуй без подглядывания перевести этот алгоритм в аналогичный на базе цыкла:

VD>

VD>template<unsigned n>
VD>struct NBits
VD>{
VD>  enum { value = NBits<(n >> 1)>::value + 1 };
VD>    static int GetBitsCount()
VD>    {
VD>        return NBits<n - 1>::value;
VD>    }
VD>};
VD>template<>
VD>struct NBits<0>
VD>{
VD>  enum { value = 0 };
VD>};
VD>

Я так понял, тебя только этот кусок кода интересовал?
Ну тогда так:

int GetBitsCount(int n)
{
int nb = 0;
for (int i = n — 1; i > 0; i = i >> 1)
nb += 1;
return nb;
}

А смысл в таком преобразовании? Алгоритм что, понятней от этого стал, что ли?

VD>Поэтому. Знать я об этих приколах заню давно, но вот использовать приходится очень редкао. Ну, жалко мне мою бошку.

А некоторым жалко бошку с указателями работать

Про них еще Дейкстра кажись писал.

S>> И сколько раз писал рекурсивные шаблоны? Но это так, в порядке подколки

VD>Один!

Ну хоть что-то.

S>>Книжку Александреску прочитать тебе не зря советовали.

VD>А может зрая?

Не, не зря. Там новый (ну не для всех, конечно, он новый) подход к шаблонным извращениям описан.

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

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

S>>Кстати, а VisualAssist по этому критерию чем не подходит? Большая часть того, чем он занимается — это предоставляет информацию о типах в design-time

VD>1. Он не предаставляет метаданные, т.е. решает совершенно другие задачи.

Список членов класса — это метаданные или что?

VD>2. Безбожно врет и глючит.

угу.

S>>IMHO, в плюсах правильным (в том числе идеологически правильным

) было бы иметь полную метаинформацию о типах во время компиляции, и при необходимости вытаскивать ее в рантайм традиционным плюсовым путем — с помощью библиотек (ну и библиотека для этого нужны бы была стандартная). Я б тогда midl куда подальше закинул...

VD>Выкидывай. В дотнете МС++ прекрасно работает без него.

А не нужен мне ни MC++, ни дотнет. А нужна только метаинформация в компил-тайме.

VD>При этом метаданные на порядок лучше.

Ну, а метаданые в компайлтайме нужный не очень сильно. sizeof-а более чем достаточно.

Кому как. Мне так и typeof нужен, и список членов класса, и граф наследования. А дальше уж я б на них шаблоны бы натравил.

VD>Шаблоны и макросы позволяют делать универсальный код вообще без метаданный.

Здрасте. А про то, что сериализацию в шарпе проще и надежней делать, не ты ли распинался? Если б С++ была возможность получить хотя бы список членов класс и перебрать предков класса (в компил-тайме, само собой), сгенерить код сериализации класса на С++ не совтавляло бы почти никакого труда. Пока же приходится для такого перебора изгаляться по всякому. Самое обидное, что у компилятора эта информация есть, но он ей ни за что не поделится...

S>>А тут — уже не прав. Анализ в компил-тайме позволяет...

VD>Никаого анализ в компайлтайме у него небыло.

Естественно, потому как С++ такой информации и не предоставляет.

VD>Он прдлагал создавать структуры орписывающие метаинформацию и анализировать уже ее.

А можно было бы — просто структуры, соответсвующие входным данным. А метаинформацию, сгенеренную для них компилером, вытаскивать в рантайм и анализировать уже ее. Одним шагом меньше — ошибок тоже будет меньше.

VD>А анализировать при компиляции особо нечего.

Это как сказать.

S>> кучу проверок переложить с программиста на компилятор, при этом будет проверен весь сгенерированный код — а в рантайме вполне можешь пару-тройку процентов редко используемого кода, анализируещего метаинформацию, оставить с ошибками.

VD>Звучит здорово. Но реально в приложениях созданных на строкомпайлтаймном С++ рантайм ошибок в разы больше чем чем созданных на шапре.

Ну это у кого как.

VD>Причем приложение переживает такие ошибки куда болезнеей нежели созданное на Шарпе.

Есть живучесть, а есть надежность. Живучесть у шарпного кода может и выше, а вот с надежностью все не так однозначно.

S>>Да никто с ней в плюсах не борется.

VD>А ты почитай постинги Геннадия Васильева повнимательнее.

Мы, видимо, на его постинги с разных позиций смотрим.

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

VD>Варинат 1: Возвращую копию массива.
VD>Варинат 2: Возвращую этумератор (IEnumerable).
VD>Аариант 3: Возвращу обертку реализаующиую индексатор и дургие методы и свойства позволяющие только читать этот массив.

VD>Короче, тут проблем нет.
Это криво...
Это затычки....

Узнаешь себя?

А если поискать то я уверен можно еще много мест найти где на плюсах все проще.

... << RSDN@Home 1.1 alpha 1 >>

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

ГВ>А насчёт "просветишь"... Давай, если тебе интересно, посмотрим на какую-нибудь конкретную ситуацию в которой, как ты считаешь, оправданно используется rtti. Можно приватом (мыло в профайле). Ну а я — выскажусь.
Например в моем случае есть куча железок с логической точки зрения идентичных(один интерфейс), а вот реализация работы сильно разная. Причем у одного заказчика один набор типов железок у дугого другой у сотого сотый. Причем ни кто не застрахован что завтра не появится логически новая железка.

Было принято решение одна железка-одна длл (хотя в принципе возможно разложить по нескольким или общие части для нескольких железок вынести в другую длл) но в длл лежит не только работа с железкой но и визуализация(возможно несколько) и формы настройки и... Хардкорить функции экспорта нельзя(помним о новых логических типах). Короче ехешник это абстрактная фабрика классов создающея объекты по имени типа возвращать она может только I_Object, а к конкретному интерфейсу приводим на месте через dynamic_cast.

В .NET это можно сделать несколько проще(но не сильно).

... << RSDN@Home 1.1 alpha 1 >>

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

WH>Это криво...
WH>Это затычки....

Это нормальный дизайн. А вот const парметры это действительно криво

... << RSDN@Home 1.1 beta 1 >>

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

AVK>Это нормальный дизайн. А вот const парметры это действительно криво
Этот нормальный дизайн приводит к серьезным потерям в производительности. Вот зашибись, давайте копировать массив в пару тысяч элементов только ради того, чтобы быть спокойными, что никто его не изменит.
Вариант с енумератором вроде ничего себе. Вот только я не могу понять, как он работает. Ну взяли мы Current. Кто нам запретит вызвать на этом Current неконстантный метод? Или там тоже копирование выполняется? Ну, тогда это то же вид сбоку.
Единственный нормальный метод — это, вроде как, создание обертки. Я над ним еще подумаю. Очевидно, что без iniline
подстановок это даст свои накладные расходы, хотя и небольшие.

Единственное, что я хотел бы понять, это чем тебя не устраивает const?

... << RSDN@Home 1.1 alpha 1 >>

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

AVK>У сана вобще очень странная политика, больше похожая на политику комитета по плюсам. Они с радостью стандартизируют библиотеки, причем выделяя на доведение этих библиотек своих спецов, но вот когда дело заходит об изменении языка и jvm то они упираются рогом.

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

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

AVK>>Это нормальный дизайн. А вот const парметры это действительно криво
S>Этот нормальный дизайн приводит к серьезным потерям в производительности.

А реализация const-параметров в дотнете не приведет к потере производительности?

S>Вот зашибись, давайте копировать массив в пару тысяч элементов только ради того, чтобы быть спокойными, что никто его не изменит.

Зачем копировать? Сделать readonly обертку.

S>Вариант с енумератором вроде ничего себе. Вот только я не могу понять, как он работает. Ну взяли мы Current. Кто нам запретит вызвать на этом Current неконстантный метод?

А тут тебе и const-параметры не помогут. Мало ли что в Current сидит — компилятор об этом ничего знать не может.

S>Единственное, что я хотел бы понять, это чем тебя не устраивает const?

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

... << RSDN@Home 1.1 beta 1 >>

Здравствуйте, <Аноним>, Вы писали:

А> Сполне нормальная политика. Есть стандарты, которые работают многие годы.

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

В 1.5 планируется столько изменений языка что диву даешься — одни шаблоны с боксингом чего стоят.

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

Почему не надо? Такая же история.

... << RSDN@Home 1.1 beta 1 >>

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

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

AVK>>>Это нормальный дизайн. А вот const парметры это действительно криво
S>>Этот нормальный дизайн приводит к серьезным потерям в производительности.

AVK>А реализация const-параметров в дотнете не приведет к потере производительности?
Не понимаю. Модификатор const — он же только в Compile-Time.
AVK>А тут тебе и const-параметры не помогут. Мало ли что в Current сидит — компилятор об этом ничего знать не может.
Это еще почему? Если у меня Current возвращает константную ссылку, то я не смогу по ней вызвать неконстантный метод.
AVK>Как то не очень оно выглядит в условиях компонентной среды. Так же как и плюсовые шаблоны, которые в чистом виде для дотнета не годятся.
Да почему? Я этого хоть убей не пойму. Ну объясните мне наконец, почему const мешает компонентной среде?

... << RSDN@Home 1.1 alpha 1 >>

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

AVK>>А реализация const-параметров в дотнете не приведет к потере производительности?
S>Не понимаю. Модификатор const — он же только в Compile-Time.

А толку от него в compile-time? Какое то незаконченное решение выходит.

AVK>>А тут тебе и const-параметры не помогут. Мало ли что в Current сидит — компилятор об этом ничего знать не может.
S>Это еще почему? Если у меня Current возвращает константную ссылку, то я не смогу по ней вызвать неконстантный метод.

А если Current возвращает некий класс, который потом приводится к другому? А если методы через рефлекшен зовут? А если для некоего интерфейса реализация метода М в одном классе константная, а в другом неконстантная?

S>Да почему? Я этого хоть убей не пойму.

Да потому что дотнету необходимо чтобы сущность существовала в рантайме, иначе толку от этих шаблонов никакого.

S>Ну объясните мне наконец, почему const мешает компонентной среде?

Он не мешает, но его реализация окажет заметное влияние на производительность, так как проверять необходимо не компилятору а рантайму.

... << RSDN@Home 1.1 beta 1 >>

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

AVK>А если Current возвращает некий класс, который потом приводится к другому? А если методы через рефлекшен зовут? А если для некоего интерфейса реализация метода М в одном классе константная, а в другом неконстантная?
Ага, вот тут уже начинается интерестность. Ну, во-первых, приведение константной ссылки к неконстантной — запрещено. Поэтому никакого косяка не возникает.
При рефлекшне — это да. Но ведь я же не могу вызвать приватный метод через рефлекшн? Тогда и с констами проблем не будет. Ну, будет лишняя проверка того, на чем мы вызываем.
А вот про реализации — извините! const — это часть сигнатуры. Тs же не спрашиваешь "А если для некоего интерфейса реализация метода М в одном классе возвращает int, а в другом string?".
AVK>Да потому что дотнету необходимо чтобы сущность существовала в рантайме, иначе толку от этих шаблонов никакого.
Ну и прекрасно. Я, правда, не понял, при чем тут шаблоны... Никто не мешает const существовать и в рантайме.
AVK>Он не мешает, но его реализация окажет заметное влияние на производительность, так как проверять необходимо не компилятору а рантайму.
Да не будет никакого влияния на производительность! Большая часть проверок выполняется в компайл-тайме. Касты и так проверяются в рантайме, и дополнительная проверка на конст/неконст никак не изменит ситуацию.

... << RSDN@Home 1.1 alpha 1 >>

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	09.07.03 07:11
Оценка:

От:	_vovin	http://www.pragmatic-architect.com
Дата:	09.07.03 07:28
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	09.07.03 07:31
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	09.07.03 07:31
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	09.07.03 07:31
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	09.07.03 11:22
Оценка:

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	09.07.03 14:55
Оценка: