Re[16]: Оптимизация .NET кода - Философия программирования

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

R>да, в языке не составляет, а вот понять специфику платформы — здесь нужен опыт. Точне даже не то, чтобы понять, а именно научиться эффективно использовать. Притом тонкостей, которые отличают .НЕТ от С++ очень и очень много. Взять хотя бы сборщик мусора в .НЕТ. Вроде мелочь, а вот научиться эффективно им пользоваться. Навскидку: деструкторы не уничтожают объект, а помещают его в Finalization Quere, нефрагментированные объекты в хипе, объекты разных поколений и их поведение и т.д.

Как все сложно! Толи дело на С++. Никаких тебе сборщиков мусора, никаких очередей финализации и поколений. Никаких генериков, все просто на шаблонах. Никакого маршалинга через интероп, все родное и проверенное годами. Хочешь оптимизауию — вот тебе вставка на асме, хочешь кроссплатформенность — пиши на страуструповском С++. Никаких тебе ремотингов и веб сервисов. Все через COM и сокеты. Все просто и удобно. Этот .NET специально придумали, чтобы дурить нашего брата. Зачем он нужен, если он такой сложный. А ведь сложный. Вы посмотрите сколько вопросов по С++ в день и .NET. В разу больше по Нету. И что это говорит, что не правильно продуманная и сложная архитектура, дающая мнимое превосходство.

Вердикт: .NET — ацтой

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

M>

Как все сложно! Толи дело на С++. Никаких тебе сборщиков мусора, никаких очередей финализации и поколений.

если сделали этот сборщик мусора — значит это кому-нибудь надо. Думаю, если бы его эффективность была нулевая — то кто бы его прикручивал бы к .НЕТу? Для программистов — плюс, не нужно беспокоиться об очистке памяти. Быстродействие... Спорный вопрос. Может он и медленнее, чем ручная очистка, а может и нет... Когда у тебя в хипе дыры появляются из-за того, что половина объектов уничтожено или когда они фрагментироваться начинают, хорошо? А .НЕТ сам за тебя это сделает, притом так, как наиболее оптимально в данный момент, а не так, как ты написал и как тебе кажется. Побочные эффекты конечно тоже есть (например, запуск мусорщика с самый ненужный момент), куда же без них... Но все же.

M> Никаких генериков, все просто на шаблонах. Никакого маршалинга через интероп, все родное и проверенное годами. Хочешь оптимизауию — вот тебе вставка на асме, хочешь кроссплатформенность — пиши на страуструповском С++.

аналогично, С++.НЕТ

M>Никаких тебе ремотингов и веб сервисов. Все через COM и сокеты.

пиши через сокеты если удобнее. Никто их не отменял. Посмотрим, за сколько бы ты программу типа Януса на сокетах написал бы

M>Все просто и удобно.

сокеты просто? вообще да, ничего сложного нет. А вот наладить взаимодействие между клиентом и сервером на сокетах... С обработкой исключительных ситуаций... Бррр... Тут насчет удобства с тобой не соглашусь

M> Этот .NET специально придумали, чтобы дурить нашего брата. Зачем он нужен, если он такой сложный.

чтобы ты велосипеды не писал типа своих Web сервисов на сокетах

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

нет, просто много всего готового (компонентов) и вопросы в основном по ним. А в С++ в основном вопросы найдите утечку памяти или неправильное обращение по адресу...

M>Вердикт: .NET — ацтой

все х??ня кроме пчел

... << RSDN@Home 1.1.2 stable >>

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

R>если сделали этот сборщик мусора — значит это кому-нибудь надо. Думаю, если бы его эффективность была нулевая — то кто бы его прикручивал бы к .НЕТу? Для программистов — плюс, не нужно беспокоиться об очистке памяти. Быстродействие... Спорный вопрос. Может он и медленнее, чем ручная очистка, а может и нет... Когда у тебя в хипе дыры появляются из-за того, что половина объектов уничтожено или когда они фрагментироваться начинают, хорошо? А .НЕТ сам за тебя это сделает, притом так, как наиболее оптимально в данный момент, а не так, как ты написал и как тебе кажется. Побочные эффекты конечно тоже есть (например, запуск мусорщика с самый ненужный момент), куда же без них... Но все же.

int* GetArray()
{
  return new int[100];
}

void Process()
{
  int* array = GetArray();

  // процессинг данных

  delete[] array;
}

Ну и где тут что я забыл!? Да ничего! А код сам контролирую и сам слежу за памятью. Да в большом проекте это слишком смешной кусок кода, но память-то надо всегда контролировать. Даже в Нете. Не будешь что-то учитывать, и на тебе StackOverflowException или OutOfMemoryException. Или вот будет у тебя утечка в сборке Нетовской. И что ты будешь делать? Танцы с бубном. А меня все просто, мои смартпоинтеры все сделают сами. Только на печи лежи. Все как Нете, только так же плюсы от плюсов

M>> Никаких генериков, все просто на шаблонах. Никакого маршалинга через интероп, все родное и проверенное годами. Хочешь оптимизауию — вот тебе вставка на асме, хочешь кроссплатформенность — пиши на страуструповском С++.

R>аналогично, С++.НЕТ

Что аналогично? Ты давно на MC++ писал? Да там от __gc и __pin и прочей лабуды можно повеситься. Managed нельзя от unmanaged наследовать и наоборот (а так же еще с полями беда, unmanaged класс не может содержать managed переменные). А уж перевод и std::string в System.String это вообще отдельная песня с бубном на ночь.

M>>Никаких тебе ремотингов и веб сервисов. Все через COM и сокеты.

R>пиши через сокеты если удобнее. Никто их не отменял. Посмотрим, за сколько бы ты программу типа Януса на сокетах написал бы

Ой, не надо. Гуй бы я, конечно, долго делал, а вот установить соединенияи к базе подключиться, проще простого. Сокеты удобны потому, что с ними начать можно быстро (продолжить сложно, но это все зависит от архитектуры, которая непропорционально усложняется в Нете).

M>>Все просто и удобно.

R>сокеты просто? вообще да, ничего сложного нет. А вот наладить взаимодействие между клиентом и сервером на сокетах... С обработкой исключительных ситуаций... Бррр... Тут насчет удобства с тобой не соглашусь

А ты думаешь они нужны нормальному то проекту, эти исключения. Да я по сокету онлик послал, значит все нормально, 1 значит не нормально, и клиент определит код ошибки (могу даже для его другое конечное состояние завести на сервере, чтобы получать коды ошибок). А ты как будешь делать? У тебя одно искоючение байт 200 займет в лучшем случае, что ровно в 200 раб больше, чем у меня. Или у нас траффик уже не ресурс и dial up стал прошлым веком!?

M>> Этот .NET специально придумали, чтобы дурить нашего брата. Зачем он нужен, если он такой сложный.

R>чтобы ты велосипеды не писал типа своих Web сервисов на сокетах

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

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

R>нет, просто много всего готового (компонентов) и вопросы в основном по ним. А в С++ в основном вопросы найдите утечку памяти или неправильное обращение по адресу...

Давно не заходил ты в тот форум. Ибо в основном там с проектированием типов вопросы (шаблоны и т.д.). Это у вас, то спонсор не работает, то исключение не сериализуеться в веб сервисе.

M>>Вердикт: .NET — ацтой

R>все х??ня кроме пчел

Мы и до них дойдем.

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

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

R>>если сделали этот сборщик мусора — значит это кому-нибудь надо. Думаю, если бы его эффективность была нулевая — то кто бы его прикручивал бы к .НЕТу? Для программистов — плюс, не нужно беспокоиться об очистке памяти. Быстродействие... Спорный вопрос. Может он и медленнее, чем ручная очистка, а может и нет... Когда у тебя в хипе дыры появляются из-за того, что половина объектов уничтожено или когда они фрагментироваться начинают, хорошо? А .НЕТ сам за тебя это сделает, притом так, как наиболее оптимально в данный момент, а не так, как ты написал и как тебе кажется. Побочные эффекты конечно тоже есть (например, запуск мусорщика с самый ненужный момент), куда же без них... Но все же.

M>

M>int* GetArray()
M>{
M>  return new int[100];
M>}

M>void Process()
M>{
M>  int* array = GetArray();

M>  // процессинг данных

M>  delete[] array;
M>}
M>

M>Ну и где тут что я забыл!? Да ничего!

это хорошо, что не забыл

M> А код сам контролирую и сам слежу за памятью. Да в большом проекте это слишком смешной кусок кода, но память-то надо всегда контролировать. Даже в Нете. Не будешь что-то учитывать, и на тебе StackOverflowException или OutOfMemoryException. Или вот будет у тебя утечка в сборке Нетовской. И что ты будешь делать? Танцы с бубном. А меня все просто, мои смартпоинтеры все сделают сами. Только на печи лежи. Все как Нете, только так же плюсы от плюсов

попробуй напиши вроде Week Reference

M>>> Никаких генериков, все просто на шаблонах. Никакого маршалинга через интероп, все родное и проверенное годами. Хочешь оптимизауию — вот тебе вставка на асме, хочешь кроссплатформенность — пиши на страуструповском С++.

R>>аналогично, С++.НЕТ

M>Что аналогично? Ты давно на MC++ писал? Да там от __gc и __pin и прочей лабуды можно повеситься. Managed нельзя от unmanaged наследовать и наоборот (а так же еще с полями беда, unmanaged класс не может содержать managed переменные). А уж перевод и std::string в System.String это вообще отдельная песня с бубном на ночь.

пиши или managed или unmanaged и не мешай все в кучу

M>>>Никаких тебе ремотингов и веб сервисов. Все через COM и сокеты.

R>>пиши через сокеты если удобнее. Никто их не отменял. Посмотрим, за сколько бы ты программу типа Януса на сокетах написал бы

M>Ой, не надо. Гуй бы я, конечно, долго делал, а вот установить соединенияи к базе подключиться, проще простого. Сокеты удобны потому, что с ними начать можно быстро (продолжить сложно, но это все зависит от архитектуры, которая непропорционально усложняется в Нете).

Да ну ладно проще простого... Еще чтобы по 80 порту все крутилось на клиенте и на сервере.. Хотя отдельный порт не так уж и сложно, только геморрно все это, велосипед однако

M>>>Все просто и удобно.

R>>сокеты просто? вообще да, ничего сложного нет. А вот наладить взаимодействие между клиентом и сервером на сокетах... С обработкой исключительных ситуаций... Бррр... Тут насчет удобства с тобой не соглашусь

M>А ты думаешь они нужны нормальному то проекту, эти исключения.

да, ошибки это неотъемлимая часть

Притом иногда ошибки на физическом уровне.

M>Да я по сокету онлик послал, значит все нормально, 1 значит не нормально, и клиент определит код ошибки (могу даже для его другое конечное состояние завести на сервере, чтобы получать коды ошибок). А ты как будешь делать? У тебя одно искоючение байт 200 займет в лучшем случае, что ровно в 200 раб больше, чем у меня. Или у нас траффик уже не ресурс и dial up стал прошлым веком!?

ресурс, только не в таких масштабах

M>>> Этот .NET специально придумали, чтобы дурить нашего брата. Зачем он нужен, если он такой сложный.

R>>чтобы ты велосипеды не писал типа своих Web сервисов на сокетах

M>А ты думаешь на С++ нет готовых библиотек, которые бы мне облегчили жизнь. Ошибаешься. Еще как есть. Ибо не вчера на сях начали писать распределенные вычисления.

ну я думаю, микрософт шаг назад в web сервисах не сделал

M>>>Вердикт: .NET — ацтой

R>>все х??ня кроме пчел

M>Мы и до них дойдем.

только там нас еще не хватало

... << RSDN@Home 1.1.2 stable >>

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

M>

int* GetArray()
{
  return new int[100];
}

void Process()
{
  int* array = GetArray();

  // процессинг данных
  throw new MyException();

  delete[] array;
}

M>Ну и где тут что я забыл!?

Получите лик.

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

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

M>>

IT>int* GetArray()
IT>{
IT>  return new int[100];
IT>}

IT>void Process()
IT>{
IT>  int* array = GetArray();

IT>  // процессинг данных
IT>  throw new MyException();

IT>  delete[] array;
IT>}
IT>

M>>Ну и где тут что я забыл!?

IT>Получите лик.

И что? А если я поток запусаю или мьютекс так же создаю (это в Нете), то по они так же никогда не исчезнут. Так что это блы гипотетичский пример, без обработки исключений. Я там мог бы смартпоинтеры ввести и вообще было бы отлично. Кстати, я мог бы их и для создания потока сделать, что было бы невозможно для С#. Так что, как ни крути, тут С++ впереди.

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

M>>>Ну и где тут что я забыл!?

IT>>Получите лик.

M>И что?

Okey

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

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

M>>

IT>int* GetArray()
IT>{
IT>  return new int[100];
IT>}

IT>void Process()
IT>{
IT>  int* array = GetArray();

IT>  // процессинг данных
IT>  throw new MyException();

IT>  delete[] array;
IT>}
IT>

M>>Ну и где тут что я забыл!?

IT>Получите лик.

я так и думал, ты таки не знаешь С++

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

M>

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

IT>>Получите лик.

N>я так и думал, ты таки не знаешь С++

Имхо, там действительно лик.

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

ну так давайте подведем итог(если тут ещё кто-то остался

), вот по пунктам с кратким описанием моего мнения:

1. С++ (без .NET):
1.1. Недостатка
1.1.1) плохо отлаживать (лики, оверфловы, обрезки объектов и т.п.)
проблема легко решаема, програмирование на современном С++,
1.1.2) малая скорость разработки (то же что и 1.1)

1.2. Достоинства
из достоинств было упомянуто свобода в выборе
не добовляя ничево в сам язык можно добится всего что есть в С# и большего чего нельзя в C#, без изменения языка AOP (и это тоже, как бы не было написано в умных статьях, AOP на С++ это действительно реально на С# нужно вводить что-то в язык, по крайней мере на том уровне на котором сейчас находится теория AOP).

2. C#.NET
2.1. За
2.1.1) плохая производительность
2.1.1.1) gc,
2.1.1.2) jit — вроде догворились что ничево не замедляет а наоборот даже ускоряет, хотя, честно, я не догоняю преимуществ, почему не компилировать во время инсталяции?, например, такого в С++ можно тоже добится, не предоставляя исходников, я понимаю что это я тут чево-то не понимаю, объясните.
2.1.1.3) boxing — вроде бы решился с помощью generic'ов, которые часто путают с шаблонами C++, которыми они совсем не являются (пользуясь продвинутой терминалогией я бы сказал что это просто заплатка к первой версии чтобы обойти проблему боксинга)
(тут приводилась ссылка с тестами от микрософт, там где С++ безнадёжно проигрывал, я попробывал у себя всё это на тех же компиляторах, и оказалось что в исходных тестах они поставили inline а вот в ключах компилятора они ничево не отобразили, а они ведь ничево не инлайнят если их хоршо не попросить)
2.1.1.4) помоему что-то ещё есть, но могу вспомнить
2.2. Достоинства.
2.2.1) Всё что нужно в одном месте (не знаю достоинство это или недостаток, помоему это просто создаёт илюзию того что всё есть и просто можно перестать искать что-то другое, а ведь оно всегда есть, что-то другое, и лучшее)
2.2.2) мультиплатформенность jit (2.1.1.2) с учётом того что sun вроде бы что-то там начал сертефицировать под windows вполне возможно скоро это будет большим плюсом
2.2.3) автоматическое управление памятью (в с++ немеренно как коммерчиски так и бесплатных gc, с самыми разными алгроритмами, с самой разной производительностью, но как оказывается смартпоинтеров вполне достаточно, конечно тут есть небольшой недостаток с недостаточной стандартизованостью алокаторов).
2.2.4) рефлекшин (легко обхожусь в С++ даже без rtti, у меня всё что нужно генерится в ct (кто-то говорил что шаблоны отлаживать сложно — компилировать сложно, зато если откомпилировалось 80% что будет работать) с проверкой ошибок в ct.
2.2.5) возможно скоро не будет других альтернатив для win-разработчиков(наверное большлй +, в моих проектах win это 2%, но кто его знает что дальше будет (я не линуксоид, сразу говорю))

это то что было отмечено здесь (я правильно всё понял?)
я немного неправильно высказался выше, признаю, извиняюсь
что-то упустил?, если что-то не так, расскажите без наездов, пожалуста, я читал этот топик до сих пор не потому что хотел отстоять честь С++, а просто чтоб узнать что-то что ради чего стоит больше внимания уделить .NET, я пока ничево не узнал

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

N>ну так давайте подведем итог(если тут ещё кто-то остался

), вот по пунктам с кратким описанием моего мнения:
думаю что нет смысла ничего оспаривать просто добавлю свое мнение

N>1. С++ (без .NET):
N>1.1. Недостатка
N>1.1.1) плохо отлаживать (лики, оверфловы, обрезки объектов и т.п.)
N>проблема легко решаема, програмирование на современном С++,
N>1.1.2) малая скорость разработки (то же что и 1.1)

N>1.2. Достоинства
N>из достоинств было упомянуто свобода в выборе
N>не добовляя ничево в сам язык можно добится всего что есть в С# и большего чего нельзя в C#, без изменения языка AOP (и это тоже, как бы не было написано в умных статьях, AOP на С++ это действительно реально на С# нужно вводить что-то в язык, по крайней мере на том уровне на котором сейчас находится теория AOP).
— "компактность" готовых решений
— высокая производительность как на вычислениях, так и при работе с памятью

N>2. C#.NET
N>2.1. За
видимо ты хотел написать "недостатки"
N>2.1.1) плохая производительность
— простые тесты производительности (http://www.osnews.com/story.php?news_id=5602) это подтверждают
N>2.1.1.1) gc,
N>2.1.1.2) jit — вроде догворились что ничево не замедляет а наоборот даже ускоряет, хотя, честно, я не догоняю преимуществ, почему не компилировать во время инсталяции?, например, такого в С++ можно тоже добится, не предоставляя исходников, я понимаю что это я тут чево-то не понимаю, объясните.
N>2.1.1.3) boxing — вроде бы решился с помощью generic'ов, которые часто путают с шаблонами C++, которыми они совсем не являются (пользуясь продвинутой терминалогией я бы сказал что это просто заплатка к первой версии чтобы обойти проблему боксинга)
N>(тут приводилась ссылка с тестами от микрософт, там где С++ безнадёжно проигрывал, я попробывал у себя всё это на тех же компиляторах, и оказалось что в исходных тестах они поставили inline а вот в ключах компилятора они ничево не отобразили, а они ведь ничево не инлайнят если их хоршо не попросить)
N>2.1.1.4) помоему что-то ещё есть, но могу вспомнить
— библиотека API .NET (которая входит в Mono) не перенесена в полном объеме на *nix
— инструментальные средства разработки только для Windows
— отсутствие открытых спецификаций на API (во всяком случае у меня найти их не получилось, кто знает киньте ссылку)
— наличие в сборке unsafe-кода, IMHO потенциальная уязвимость

N>2.2. Достоинства.
N>2.2.1) Всё что нужно в одном месте (не знаю достоинство это или недостаток, помоему это просто создаёт илюзию того что всё есть и просто можно перестать искать что-то другое, а ведь оно всегда есть, что-то другое, и лучшее)
N>2.2.2) мультиплатформенность jit (2.1.1.2) с учётом того что sun вроде бы что-то там начал сертефицировать под windows вполне возможно скоро это будет большим плюсом
N>2.2.3) автоматическое управление памятью (в с++ немеренно как коммерчиски так и бесплатных gc, с самыми разными алгроритмами, с самой разной производительностью, но как оказывается смартпоинтеров вполне достаточно, конечно тут есть небольшой недостаток с недостаточной стандартизованостью алокаторов).
N>2.2.4) рефлекшин (легко обхожусь в С++ даже без rtti, у меня всё что нужно генерится в ct (кто-то говорил что шаблоны отлаживать сложно — компилировать сложно, зато если откомпилировалось 80% что будет работать) с проверкой ошибок в ct.
N>2.2.5) возможно скоро не будет других альтернатив для win-разработчиков(наверное большлй +, в моих проектах win это 2%, но кто его знает что дальше будет (я не линуксоид, сразу говорю))
— поддержка спецификаций w3c SOAP, что облегчает интеграцию в гетерогенных системах
— стандартизация языка C# и CLI
— похоже что в России растет спрос на NET разработчиков у молодых специалистов есть шанс,
но тут есть и обратная сторона, со временем может произойти снижение уровня ЗП

Для себя, ответ на вопрос "Где нет места NET?" я сформулировал так, ".Net сейчас нет места на ДРУГИХ платформах.

" Надеюсь в будущем он там появится.

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

N>AOP на С++ это действительно реально на С# нужно вводить что-то в язык, по крайней мере на том уровне на котором сейчас находится теория AOP).

А можно чуть подробнее про реализацию AOP на с++ ?

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

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

N>>AOP на С++ это действительно реально на С# нужно вводить что-то в язык, по крайней мере на том уровне на котором сейчас находится теория AOP).

AJD>А можно чуть подробнее про реализацию AOP на с++ ?

слишьком подробно наверное нельзя
реализуется с помощью шаблонов,
фреймворк уже есть созданный, работающий (но мало используемый), который впринципе повторяет все фичи AspectJ (в сам язык С++ при этом ничево добовлять не надо) можно и больше, зборка аспектов может проходить как в ct так и в rt (ct больше по C++'овски)

сейчас у меня нет времени более подробно рассказать, но чуть позже (может через неделю) я сюда могу запостить более подробно, с примерами.
Фреймворк полностью отдать не могу так как это собственность моей компании.

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

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

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

, идешь в магазин покупаешь видиби и с радостью употребляешь новые функции

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

W>PS просьба к словам сильно не цепляться, объяснял как мог, это было только имхо начинающего

То есть тебе просто впадлу учится?
А куча книг это огромный плюс. Есть возможность познакомиться с разными мнениями по нужному вопросу. НЕТ — технология молодая. Если б ей было хоть вполовину столько сколько сям, ты бы тоже самое говорил про бардак в НЕТе.
А насчет консоли — ты на асме попиши ввод/вывод чисел в разных форматах и тому подобные мульки — после этого С покажется просто сказкой. Но зато программинг на асме это совсем другое измерение творчества )))

От:	mikа	Stock#
Дата:	20.01.04 08:45
Оценка:

От:	mikа	Stock#
Дата:	20.01.04 08:48
Оценка:

	От:	oRover
	Дата:	20.01.04 13:23
	Оценка:

От:	mikа	Stock#
Дата:	20.01.04 15:05
Оценка:	1 (1) +2

	От:	oRover
	Дата:	20.01.04 17:07
	Оценка:

От:	IT	linq2db.com
Дата:	21.01.04 03:17
Оценка:

	От:	naje
	Дата:	21.01.04 07:50
	Оценка:

	От:	dad
	Дата:	21.01.04 07:55
	Оценка:

	От:	AVM
	Дата:	21.01.04 08:00
	Оценка: