Re[13]: Вопрос о конкретных примерах
От: Nick_ Россия  
Дата: 01.10.04 11:52
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Тут доказывать нечего

WH>14.6/2
WH>

WH>A name used in a template declaration or definition and that is dependent on a template-parameter is assumed not to name a type unless the applicable name lookup finds a type name or the name is qualified by the keyword typename.


Hint: почитай порядок name lookup'а для идентификаторов зависящих от параметра шаблона. Поиск делается как в контексте определения шаблона, так и в контексте инстанциации. Синтаксический анализ невозможно сделать до лукапа, а лукап до инстанциации.

WH>ЗЫ А ты попробуй откомпилить это(без typename)

WH>
WH>template<class T>
WH>struct A
WH>{
WH>    typename T::x x;
WH>};

WH>struct B
WH>{
WH>    typedef int x;
WH>};

WH>int main()
WH>{
WH>    A<B> x;
WH>}
WH>


В данном случае строка в шаблоне не может быть двусмысленно интерпретирована. Если T::x будет не типом — возникнет ошибка. Тут как раз ничего удивительного и нет.
Re[14]: Вопрос о конкретных примерах
От: WolfHound  
Дата: 01.10.04 11:58
Оценка:
Здравствуйте, Nick_, Вы писали:

N_>Да?

А ты typename убрать не забыл? Похоже что забыл.

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

А! Ну-ну. Вот только компиляторы с фронтендом от EDG с тобой не согласны...

ЗЫ Re: ??? Какого оно компилится???
Автор: 0xDEADBEEF
Дата: 01.10.04
... << RSDN@Home 1.1.4 rev. 185 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Вопрос о конкретных примерах
От: prVovik Россия  
Дата: 01.10.04 12:01
Оценка:
Здравствуйте, INTP_mihoshi, Вы писали:

V>>То есть где?

INT>Там, где необходима инкапсуляция состояний.
Стажи, а, например, структуру "стек" можно описать, как объект, инкапсулирующий состояние?

INT>Там, где необходим интерфейс к какой-то физической сущности — устройству, окну, удаленной машине.

1) Разве бывают в реальной жизни программы, которые совсем не взаимодействуют с физическими сущносями?
2) А если сущность виртуальная? С ней не надо взаимодействовать?
... << RSDN@Home 1.1.4 @@subversion >>
лэт ми спик фром май харт
Re[15]: Вопрос о конкретных примерах
От: Nick_ Россия  
Дата: 01.10.04 12:08
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>А ты typename убрать не забыл? Похоже что забыл.


Я свой пример скомпилял. Собственно я про него тебя и спрашивал, а ты сказал что его не скомпилирует "нормальный компилятор".

WH>А! Ну-ну. Вот только компиляторы с фронтендом от EDG с тобой не согласны...

Это какие? Intel C++?

C:\Documents and Settings\nildugan>icl template.cpp
Intel(R) C++ Compiler for 32-bit applications, Version 8.0   Build 20031017Z Pac
kage ID: W_CC_P_8.0.037
Copyright (C) 1985-2003 Intel Corporation.  All rights reserved.

template.cpp
Microsoft (R) Incremental Linker Version 7.10.3077
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:template.exe
template.obj


WH>ЗЫ Re: ??? Какого оно компилится???
Автор: 0xDEADBEEF
Дата: 01.10.04


Может тогда не майкрософтовский компилятор "нормальный", а gcc?
Re[16]: Вопрос о конкретных примерах
От: WolfHound  
Дата: 01.10.04 13:07
Оценка:
Здравствуйте, Nick_, Вы писали:

А можно вопрос? Спасибо. Ты вобще читаешь что я пишу?
... << RSDN@Home 1.1.4 rev. 185 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: Вопрос о конкретных примерах
От: INTP_mihoshi Россия  
Дата: 01.10.04 13:08
Оценка:
Здравствуйте, prVovik, Вы писали:

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


V>>>То есть где?

INT>>Там, где необходима инкапсуляция состояний.
V>Стажи, а, например, структуру "стек" можно описать, как объект, инкапсулирующий состояние?
Стек — не состояние, а данное.

INT>>Там, где необходим интерфейс к какой-то физической сущности — устройству, окну, удаленной машине.

V>1) Разве бывают в реальной жизни программы, которые совсем не взаимодействуют с физическими сущносями?
В объект надо оброачивать только собственно эти сущностями.

V>2) А если сущность виртуальная? С ней не надо взаимодействовать?

Давай пример виртуальной сущности, которая не является состоянием и которую стоит реализовать именно через класс.
Re[17]: Вопрос о конкретных примерах
От: Nick_ Россия  
Дата: 01.10.04 13:13
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

WH>А можно вопрос? Спасибо. Ты вобще читаешь что я пишу?


Твой пример я тоже посмотрел. Ошибку на нем выдает только VC++ 7.

Пора бы уже согласиться, что в текущем стандарте С++ шаблоны это не более чем продвинутые макросы с возможностью их рекурсивного определения и проверкой на типы.
Re[18]: Вопрос о конкретных примерах
От: WolfHound  
Дата: 01.10.04 14:07
Оценка: +1
Здравствуйте, Nick_, Вы писали:

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

... << RSDN@Home 1.1.4 rev. 185 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[16]: ФП: вводная статья
От: Gaperton http://gaperton.livejournal.com
Дата: 01.10.04 16:04
Оценка:
Здравствуйте, Quintanar, Вы писали:

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


G>>1) Попробуй пометить аргументы функций как strict. Насколько я помню, это делается так же как в Clean (!). Strictness analyzer не способен определить все strict вызовы, ему надо помочь.

G>>2) Попробуй использовать STUArray c типом Bool(Data.Array.ST).


Q>strict аргументов там нет, да и так там ничего ленивого в сущности нет.

"$!" — strict application (http://www.haskell.org/onlinereport/basic.html#sect6.2)
Проблема в том, что компилятор не всегда может определить, когда можно использовать strict вычисления. Он пытается это сделать (иначе было бы все очень медленно), но полный strictness-analyzis это NP-полная задача, так что компилятору надо помогать.

Q>STUArray работает буквально на пару секунд побыстрее. С Bool оба массива тормозят — 1м30 и 1м28 соответственно.

Плохо. Все-таки, нельзя настолько затруднять эффективный доступ к массивам и strict-evaluation, как это сделано в Haskell. От его массивов несет императивщиной за версту (монады!), а толку все равно никакого. Clean рулит. Тот же Haskell, но все по уму.
Re[20]: ФП: вводная статья
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.10.04 17:40
Оценка:
Здравствуйте, Блудов Павел, Вы писали:

БП>ИМХО, не в естестве дело. Костность мышления да, имеет место.

БП>Я знаю много людей, хорошо владещих процедурным программированием. Но при попытке пересадить их за ООП получается ПООП (псевдо ООП).
БП>Люди все равно думают строчками кода, а не сущностями, которые за ними стоят.
БП>Трудно переучиваться. Особенно если учишь процедурные языки со школы.
БП>А вот если бы в школах учили не паскалю, а смолтеку — щас бы грамотных С++шников было пруд пруди (это я так, наболело).

БП>С декларативными языками примерно тоже самое.


А я вот являюсь представителем обратного оптыа. Начинал я писать на С и потом очень просто и с радостью пересел за С++. Я уже на С думал объектами. Но восприятие функционального стиля, если сам алгоритм не рекурсивен мною воспринимается с трудом.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Вопрос о конкретных примерах
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.10.04 17:40
Оценка:
Здравствуйте, INTP_mihoshi, Вы писали:

INT>В С# есть сборка мусора и модульность. Строгой типизации — нет,


Это с чего же это нет?

INT> делегаты какие-то мутные,


Что в них мутного то? Медленные — да. Но мутные... Они как раз очень даже ясные и концептуально чистые. Единственная проблема — их параметры нельзя задавать частично. Но это решается анонимными методами.

INT> темплейтов нет.


Дженерики есть. Для задач обобщенного программирования более чем достаточно. Да я тут вам уже как-то приводил вариант функционального АндиКвикСорта на втором шарпе.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Вопрос о конкретных примерах
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.10.04 17:40
Оценка:
Здравствуйте, INTP_mihoshi, Вы писали:

WH>> Это как это нет? Есть! Причем как компаилтайм так и рантайм.

INT>Была бы строгая — не были бы возможны контейнеры.

Ошибашся. Строгая типизация требует только невозможность неверного привдения типов. Оно не требует чтобы все проверки делались в компайл-тайме (были статическими). Приведение в Шарпе полностью безопасны (если не используется ансэйф-режим). Для up-cast-ов делаются рантайм-проврки.

Но C# — это строго-типизированный язык. Об этом даже в спецификации наисано. Так что ты ошибашся.

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


Именно что. И вообще твое отвращение к Шарпу явно основано на том, что ты в него не вник.

WH>>Я про C#2 говорил.

INT>Он уже вышел? Я просто не в курсе. Может, дашь ссылку?

Он в бата-стадии, но работает и доступн.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: ФП: вводная статья
От: Gaperton http://gaperton.livejournal.com
Дата: 01.10.04 19:15
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


V>>Если уж и начали мерятся скоростями, то со стороны С++ должен выступать ICC. Ибо он рулит.

WH>Ну выступи. Ибо ICC у меня нет. К томуже на таких расчетах VC++ тоже рулит.
И Clean тоже, как выяснилось . Ну что, "не посчитать ли нам, уважаемые кроты?" Может, матрицы поперемножаем?
Re[15]: ФП: вводная статья
От: WolfHound  
Дата: 01.10.04 19:51
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>И Clean тоже, как выяснилось . Ну что, "не посчитать ли нам, уважаемые кроты?" Может, матрицы поперемножаем?

Не. Матрици перемножать это ICC надо. В этом деле он рулит просто не по децки.
... << RSDN@Home 1.1.4 rev. 185 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[15]: ФП: вводная статья
От: FR  
Дата: 01.10.04 20:07
Оценка: :)
Здравствуйте, Gaperton, Вы писали:

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


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


V>>>Если уж и начали мерятся скоростями, то со стороны С++ должен выступать ICC. Ибо он рулит.

WH>>Ну выступи. Ибо ICC у меня нет. К томуже на таких расчетах VC++ тоже рулит.
G>И Clean тоже, как выяснилось . Ну что, "не посчитать ли нам, уважаемые кроты?" Может, матрицы поперемножаем?

пока вы меряли (на эротосфене) только скорость работы озу
Re[10]: Вопрос о конкретных примерах
От: prVovik Россия  
Дата: 01.10.04 22:41
Оценка: +1 -3
Здравствуйте, INTP_mihoshi, Вы писали:

V>>Стажи, а, например, структуру "стек" можно описать, как объект, инкапсулирующий состояние?

INT>Стек — не состояние, а данное.
Ну так можно абсолютно обо всем сказать.

V>>1) Разве бывают в реальной жизни программы, которые совсем не взаимодействуют с физическими сущносями?

INT>В объект надо оброачивать только собственно эти сущностями.
А остальное куда девать?

V>>2) А если сущность виртуальная? С ней не надо взаимодействовать?

INT>Давай пример виртуальной сущности, которая не является состоянием и которую стоит реализовать именно через класс.
Объясню на пальцах...
Вооружимся функциональным подходом и рассмотрим некоторую сущность, которая существует в пределах своей среды окружения. Например, среда окружения — это предприятие П1, а сущность — сотрудник Иванов, которому 35 лет. В один прекрасный день, этот сотрудник справляет себе день рождения, в результате чего Иванов(35) умирает, и на его месте появляется Иванов(36). Посмотрим на предприятие: раньше было предприятие П1, в котором работал сотрудник Иванов(35), теперь Иванов(35) умер, следовательно должно также умереть и предприятие, вместе с остальными сотрудниками. На месте этих трупов появится новое предприятие П2, в котором теперь работает сотрудник Иванов(36). Предприятие П1 также существовало в пределах своей среды окружения, например, множества других предприятий, с которыми оно взаимодействовало. И этим предприятиям также придется помереть со всеми своими сотрудниками после того, как на предприятии П1 сотрудник Иванов отпразнует свой день рождения.

Понятно, что этот процесс регенерации сущностей теоретически должен продолжаться бесконечно: поменяется страна, планета, галлактика и т.д. Но также понятно, что рано или поздно необходимо явно зафиксировать границу регенерации сущностей, обусловленную конечностью вычислительных ресурсов, и как следствие, тем, что эти ресурсы следует расходовать экономно. Таким образом, рано или поздно(скорее, рано), у нас появится сущность, которая не регенерируется при изменении своих составных частей. Эту сущность НЕВОЗМОЖНО реализовать в виде детерминированного состояния (чтобы не превысить ресурсную границу), она и будет называться объектом. Это и есть ответ на твой вопрос

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

ЗЫ: все ИМХО
... << RSDN@Home 1.1.4 @@subversion >>
лэт ми спик фром май харт
Re[11]: Вопрос о конкретных примерах
От: Quintanar Россия  
Дата: 02.10.04 07:43
Оценка:
Здравствуйте, prVovik, Вы писали:

V>Объясню на пальцах...

V>Вооружимся функциональным подходом и рассмотрим некоторую сущность, которая существует в пределах своей среды окружения. Например, среда окружения — это предприятие П1, а сущность — сотрудник Иванов, которому 35 лет. В один прекрасный день, этот сотрудник справляет себе день рождения, в результате чего Иванов(35) умирает, и на его месте появляется Иванов(36). Посмотрим на предприятие: раньше было предприятие П1, в котором работал сотрудник Иванов(35), теперь Иванов(35) умер, следовательно должно также умереть и предприятие, вместе с остальными сотрудниками. На месте этих трупов появится новое предприятие П2, в котором теперь работает сотрудник Иванов(36). Предприятие П1 также существовало в пределах своей среды окружения, например, множества других предприятий, с которыми оно взаимодействовало. И этим предприятиям также придется помереть со всеми своими сотрудниками после того, как на предприятии П1 сотрудник Иванов отпразнует свой день рождения.

Чего-то я не понял, что ты этим хочешь доказать. С теоретической точки зрения императивные языки ничем не отличаются от функциональных — любой алгоритм реализованный на одном можно реализовать на другом. С практической
точки зрения у функциональных языков есть проблема — они работают на императивной машине и следовательно должны
уметь с ней как-то общаться минимизируя возникающий урон. Эти задачи решаются, в Haskell'е даже строго
функционально, моделируя состояние внешнего мира. В чем проблема я не вижу. Зачем кого-то убивать

V>Понятно, что этот процесс регенерации сущностей теоретически должен продолжаться бесконечно: поменяется страна, планета, галлактика и т.д. Но также понятно, что рано или поздно необходимо явно зафиксировать границу регенерации сущностей, обусловленную конечностью вычислительных ресурсов, и как следствие, тем, что эти ресурсы следует расходовать экономно. Таким образом, рано или поздно(скорее, рано), у нас появится сущность, которая не регенерируется при изменении своих составных частей. Эту сущность НЕВОЗМОЖНО реализовать в виде детерминированного состояния (чтобы не превысить ресурсную границу), она и будет называться объектом. Это и есть ответ на твой вопрос


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

V>Еще хочу обратить внимание, что любая другая сущность, взаимодействующая с изменяемой, также обязана быть изменяемой, то есть начиная с некоторого уровня абстракции, функциональное программирование исчезает полностью!!! Отсюда следует, что функциональные языки в целом не могут заменить итеративные. Ну разве что их гибриды в некоторых областях применения...


Странный и бездоказательный вывод. Функциональное программирование исчезает только при вводе-выводе, поскольку
внешний мир невозможно проконтролировать ну и что?
Re[12]: Вопрос о конкретных примерах
От: prVovik Россия  
Дата: 02.10.04 08:53
Оценка:
Здравствуйте, Quintanar, Вы писали:


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

А кто срорит? Вопрос в цене.

Q>С практической точки зрения у функциональных языков есть проблема — они работают на императивной машине и следовательно должны

Q>уметь с ней как-то общаться минимизируя возникающий урон. Эти задачи решаются, в Haskell'е даже строго
Q>функционально, моделируя состояние внешнего мира. В чем проблема я не вижу. Зачем кого-то убивать
см. далее

V>>Понятно, что этот процесс регенерации сущностей теоретически должен продолжаться бесконечно: поменяется страна, планета, галлактика и т.д. Но также понятно, что рано или поздно необходимо явно зафиксировать границу регенерации сущностей, обусловленную конечностью вычислительных ресурсов, и как следствие, тем, что эти ресурсы следует расходовать экономно. Таким образом, рано или поздно(скорее, рано), у нас появится сущность, которая не регенерируется при изменении своих составных частей. Эту сущность НЕВОЗМОЖНО реализовать в виде детерминированного состояния (чтобы не превысить ресурсную границу), она и будет называться объектом. Это и есть ответ на твой вопрос


Q>Ты что-то путаешь. Зачем что-то регенерировать, есть вполне строгие методы позволяющие заменить один элемент в

Q>массиве на другой без копирования всего массива.
Это как раз то, о чем я говорю. Если мы изменим элемент массива без его регенерации, то получим функцию с побочным эффектом. Массив теперь станет изменяемой сущностью, т.е. объектом, инкипсулирующим свое сотояние. Манипулировать такими изменяемыми сущностями, применяя чистый функциональный подход в общем случае невозможно, и хотим мы того, или нет, придется прсать итеративную программу. То есть на определенном уровне абстракции функциональный подход изчезает.


V>>Еще хочу обратить внимание, что любая другая сущность, взаимодействующая с изменяемой, также обязана быть изменяемой, то есть начиная с некоторого уровня абстракции, функциональное программирование исчезает полностью!!! Отсюда следует, что функциональные языки в целом не могут заменить итеративные. Ну разве что их гибриды в некоторых областях применения...


Q>Странный и бездоказательный вывод.

С чем именно ты не согласен? С тем, что побочные эффекты, возникающие в изменяемой сущности приведут к появлению побочных эффектов в других сущностях, взаимодействующих с данной?

Q>Функциональное программирование исчезает только при вводе-выводе, поскольку

Q>внешний мир невозможно проконтролировать ну и что?
Часто и внутренний мир контролировать очень накладно. Пример тому — те же массивы.
... << RSDN@Home 1.1.4 @@subversion >>
лэт ми спик фром май харт
Re[13]: Вопрос о конкретных примерах
От: INTP_mihoshi Россия  
Дата: 02.10.04 12:15
Оценка:
Здравствуйте, prVovik, Вы писали:

V>Это как раз то, о чем я говорю. Если мы изменим элемент массива без его регенерации, то получим функцию с побочным эффектом. Массив теперь станет изменяемой сущностью, т.е. объектом, инкипсулирующим свое сотояние. Манипулировать такими изменяемыми сущностями, применяя чистый функциональный подход в общем случае невозможно, и хотим мы того, или нет, придется прсать итеративную программу. То есть на определенном уровне абстракции функциональный подход изчезает.


Haskell — чисто функциональный язык. В программах на нем функциональный подход никуда нее исчезает.

Массив до изменения — это одна сущность/значение. Массив после изменения — другая. Можно рассмотреть сущность, объединяющую все состояния массива во все единицы времени.

Любой изменяющийся объект можно представить в виде значения функции двуэ переменных — времени и "указателя" на объект. Значение этой функции от аргументов ("Возраст Иванова", "сейчас") и ("Возраст Иванова", "год назад") имеет различные аргументы, чледовательно, имеет различные значения.

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

Q>>Функциональное программирование исчезает только при вводе-выводе, поскольку

Q>>внешний мир невозможно проконтролировать ну и что?
V>Часто и внутренний мир контролировать очень накладно. Пример тому — те же массивы.
Это тоже вопрос реализации. В функциональной программе можно на этапе компиляции проверить, требуется ли где-то одновременно значение массива в разные моменты времени. И подобрать наиболее подходяшую реализацию массива.

Кстати, гибридный OCaml как раз тем и хорош, что можно императивную реализацию обернуть в чисто функциональный интерфейс не выходя, за пределы языка.
Re[14]: Вопрос о конкретных примерах
От: prVovik Россия  
Дата: 02.10.04 13:25
Оценка:
Здравствуйте, INTP_mihoshi, Вы писали:

INT>Массив до изменения — это одна сущность/значение. Массив после изменения — другая.

А если на этот массив уже существуют ссылки?
После изменения массива, сущности, ссылающиеся на него могут начать работать иначе. То есть появится побочный эффект от изменения. После чего о функциональном программировании можно будет благополучно забыть...

INT>Можно рассмотреть сущность, объединяющую все состояния массива во все единицы времени.

И что это даст?

INT>Любой изменяющийся объект можно представить в виде значения функции двуэ переменных — времени и "указателя" на объект. Значение этой функции от аргументов ("Возраст Иванова", "сейчас") и ("Возраст Иванова", "год назад") имеет различные аргументы, чледовательно, имеет различные значения.

Во-первых, проблема не решена. Побочные эффекты будут проявляться при изменении времени.
Во-вторых, это простой случай. Что, если бы пришлось учитывать не возраст, а, например, количество волос на голове? Пришлось бы каждый момент времени сохранять текущее значение?

INT>Так что, изменяемость не противоречит функциональному подходу. Хотя и может вносить трудности в реализации.

Увы, но изменяемость ставит крест на функциональном подходе

V>>Часто и внутренний мир контролировать очень накладно. Пример тому — те же массивы.

INT>Это тоже вопрос реализации. В функциональной программе можно на этапе компиляции проверить, требуется ли где-то одновременно значение массива в разные моменты времени. И подобрать наиболее подходяшую реализацию массива.
Совершенно верно. Но проблему это всеравно не решает.

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

Хрчу заметить, что построить функциональный интерфейс к императивной резализации можно, если передавать в качестве параметра всю необходимую для выполнения алгоритма информацию, причем передавать эту информанию необходимо не по ссылке, а по значению. Отсюда следует, что применять такой подход можно только в простейших случаях, когда объем передаваемой информации достаточно мал, чтобы можо было позволить передавать копию этой информации.
... << RSDN@Home 1.1.4 @@subversion >>
лэт ми спик фром май харт
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.