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

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

VD>Это относится к мелким частностям. Иначе от чего тогда Руби происходит? В нем как и в Паскле нельзя присваивать выражения в if-ах, но как в С присваение идет знаком =.

Не так. В Ruby можно присваивать в if-ах, поэтому правило "константа при сравнении слева" в Ruby так же нужно использовать. Только, в отличии от C++, в Ruby нельзя слева в качестве lvalue в присваивании использовать вызов метода:

# Так пройдет.
if a = 2 then "a==2" end

# А вот так -- нет.
if a() = 2 then "a==2" end

# Потому что так то же нельзя:
a() = 2

Поэтому в Ruby нужно следовать правилу "константа или вызов метода при сравнении слева".

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

VD>А весь бред который несут Вирт и его поклонники легко разбивается примером BNF где := было использовано для задания правил, которые ну, никак присвоением не обозвать. Это именно что равенство (имени правила его тлу).
Не богохульствуй. Это Вирт придумал EBNF.

С уважением, Gleb.

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

E>Поэтому в Ruby нужно следовать правилу "константа или вызов метода при сравнении слева".

Ясно. Сори. Был о Руби более высокого мнения. Оказывается в нем те же грабли что и в С. Прискорбно.

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

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

E>>>Ну дык почему же не сделать такую же возможность для обычных вызовов в рамках одного многопоточного процесса?

VD>>На то есть две причины:
VD>>1. Дико не эффективно!

E>+1. Но ведь многопоточным приложениям нужно как-то обмениваться данными между потоками. В любом случае здесь будет не эффективность по сравнению с обычными вызовами (и даже виртуальными).

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

VD>>2. На фиг не упало.

E>-1. Здесь у меня другой опыт.

Рад за тебя. Мне вот делегатов за глаза хватает. Не так часто создаются потоки, чтобы молиться на них.

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

E>>Поэтому в Ruby нужно следовать правилу "константа или вызов метода при сравнении слева".

VD>Ясно. Сори. Был о Руби более высокого мнения. Оказывается в нем те же грабли что и в С. Прискорбно.

Угу. Я уже, кажется говорил, что при близком рассмотрении Ruby оказывается совсем не таким простым языком, как можно было подумать. Он скорее ближе к C++ по количеству потаенных уголков.

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

VD>>А весь бред который несут Вирт и его поклонники легко разбивается примером BNF где := было использовано для задания правил, которые ну, никак присвоением не обозвать. Это именно что равенство (имени правила его тлу).
GZ>Не богохульствуй. Это Вирт придумал EBNF.

Читай внимательно (жирным). А BNF расшифровывается как "форма Бэкуса и Науэра).

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

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

VD>>>А весь бред который несут Вирт и его поклонники легко разбивается примером BNF где := было использовано для задания правил, которые ну, никак присвоением не обозвать. Это именно что равенство (имени правила его тлу).
GZ>>Не богохульствуй. Это Вирт придумал EBNF.

VD>Читай внимательно (жирным). А BNF расшифровывается как "форма Бэкуса и Науэра).
Какая разница EBNF расшифровывается примерно так же. И во-первых, я благодарен Вирту что с его страстью к простоте он ее таки сделал, а во вторых эта аналогия неуместна. Это все равно что сравнивать сишный '=' с оператором '=' в Лиспе или SML. И прошу не смешивать бред Вирта и "его поклонников"(не понял где ты его нашел).

С уважением, Gleb.

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

E>Я специально указал и Printer и Writer, чтобы посмотреть, насколько вырастет общий листинг, если будут использованы асинхронные делегаты.

Вот не надо больше так делать. Если тебе интересно, то подобный эксперимент ты сможешь проделать сам, не засоряя форум. А о результатах напишешь.

AVK>>Напоминаю, все это происходило в контексте разговора о том, какие технологии станут прорывом в программировании, сопоставимом с переходом от структурного программирования к ООП.

E>Ну контекстов там было затронуто множество.

Ну да, ты постоянно пытаешься перескочить на другую тему.

E>-- а ты сам подумай, если C++ станет настолько управляемым языком, что в production системе, средствами самого языка можно будет менять код какого-то метода на лету, то его роль в индустрии (по отношению к C#/Java) существенно изменится, тебе не кажется?

Не кажется. Такой С++ уже есть, называется C++/CLI. У нас есть прекрасная возможность пронаблюдать, насколько он изменит индус-трию.

E>Ну а если серьезно? Можно ли сейчас в мейнстримовых языках менять реализацию классов на лету, не уничтожая уже созданных объектов?

Нельзя и слава богу. Иначе надежность таких решений будет стремится к нулю. Даже при подмене отдельных классов в EJB-серверах (я экспериментировал с Orion Application Server) без сохранения экземпляров в приложении периодически возникают глюки, связанные с несовместимостью нового и старого кода. Поэтому такая фича полезна в основном для отладки, в продакшн-режиме ее отрубают (данные дороже).

E> Не через ручную "двойную" диспетчеризации + рефлекшен, а штатными средствами. Мне кажется, что это только увеличит для разработчиков свободу выбора и, как следствие, может привести к очень значительным изменениям при разработке ПО.

Ну вот был уже такой Smalltalk. И как то вот не очень получилось.

E>Про измерение опыта ты сам заговорил. А потом стал утверждать что-то на основании твоего опыта (про который я вообще ничего не знаю). Вот эти утверждения уже в серьез не воспринимаются.

Твое право, можешь мне не верить.

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

E>>-- а ты сам подумай, если C++ станет настолько управляемым языком, что в production системе, средствами самого языка можно будет менять код какого-то метода на лету, то его роль в индустрии (по отношению к C#/Java) существенно изменится, тебе не кажется?

AVK>Не кажется. Такой С++ уже есть, называется C++/CLI. У нас есть прекрасная возможность пронаблюдать, насколько он изменит индус-трию.

Имхо, C++/CLI -- это такая экзотика, которая и на сообщество C++ может не оказать влияния, т.к. нигде, кроме MS его не будет.

E>>Ну а если серьезно? Можно ли сейчас в мейнстримовых языках менять реализацию классов на лету, не уничтожая уже созданных объектов?

AVK>Нельзя и слава богу. Иначе надежность таких решений будет стремится к нулю. Даже при подмене отдельных классов в EJB-серверах (я экспериментировал с Orion Application Server) без сохранения экземпляров в приложении периодически возникают глюки, связанные с несовместимостью нового и старого кода. Поэтому такая фича полезна в основном для отладки, в продакшн-режиме ее отрубают (данные дороже).

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

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

AVK>

AVK>class Editor
AVK>{
AVK>  private void DoBackgroundSave()
AVK>  {
AVK>    m_writter.Store(m_Document, BackgroundSaveDone);
AVK>  }
        
AVK>  // Callback для получения результата сохранения.
AVK>    public void BackgroundSaveDone(SaveResult r)
AVK>  { ... }

AVK>}
AVK>

Андрей, а здесь вызов m_writter.Store() корректен? Или же аргумент BackgroundSaveDone нужно к какому-то делегату преобразовывать?

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

E>Имхо, C++/CLI -- это такая экзотика, которая и на сообщество C++ может не оказать влияния, т.к. нигде, кроме MS его не будет.

Все тебе не слава богу. Не будет никакой революции в обычном С++, даже не жди.

E>Так ведь здравый смысл то же не отменяют.

Здравый смысл хорош, когда ты от безделья балуешся.

E> Если происходят серьезные структурые изменения, то обновления на лету ни к чему хорошему не приведут.

Вопрос только в том, насколько серьезными должны быть эти изменения. Определить это практически невозможно. А рисковать себе дороже.

E> А вот если не большие, то почему бы и нет? Похоже на оператор goto

Поому что все равно это нужно протестировать, прежде чем ломать рабочую систему.

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

Для этого всего лишь нужен приличный логгер.

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

Т.е. отладка на шкуре потребителя .

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

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

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

E>Андрей, а здесь вызов m_writter.Store() корректен? Или же аргумент BackgroundSaveDone нужно к какому-то делегату преобразовывать?

В C# 2.0 корректен.

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

E>>Имхо, C++/CLI -- это такая экзотика, которая и на сообщество C++ может не оказать влияния, т.к. нигде, кроме MS его не будет.

AVK>Все тебе не слава богу. Не будет никакой революции в обычном С++, даже не жди.

Да я и не жду. Это тебе просто показалось.

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

AVK>Для этого всего лишь нужен приличный логгер.

Логгер здесь не причем. Иногда бывает необходимо вставить логгирование туда, где его не было. Или вообще убрать откуда-то.

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

AVK>Т.е. отладка на шкуре потребителя .

А что делать, если не все можно на тестовых стендах воспроизвести.

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

VD>А весь бред который несут Вирт и его поклонники легко разбивается примером BNF где := было использовано для задания правил, которые ну, никак присвоением не обозвать. Это именно что равенство (имени правила его тлу).

Во первых, не :=, а ::= . Во-вторых, не равенство.

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

E>А для того, чтобы не приявязывать lambda к локальному контексту (доступ к occur, например) можно применить такой метод bind-инга параметров:
E>

E>for_each( begin(a), end(a),
E>        void lambda( const int & x, map_t & m = occur )
E>            { if( x < 7 ) m[ x ]++; }
E>    );
E>

А смысл? ИМХО компилятор сможет легко сам найти на какие имена ссылается лямбда.
Чем просто

for_each( begin(a), end(a),
        void lambda( const int & x)
            { if( x < 7 ) occur[ x ]++; }
    );

Хуже?
Да и вобще если уж на то пошло то так:

for_each( begin(a), end(a),
        ( auto const& x) =>
            { if( x < 7 ) occur[ x ]++; }
    );

Этот код сгенерит класс типа

class lambda
{
    map_t& occur;
public:
    lambda(map_t& occur)
        :occur(occur)
    {}
    templarte<class T>
    void operator()(T const& x)
    {
        if( x < 7 ) occur[ x ]++;
    }
};

И заменит вызов на такой

for_each( begin(a), end(a), lambda(occur));

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

D>>Согласен. Однако, imho, разница синтаксиса Паскаля и C в том, что Паскаль — ориентирован на быстрое обучение начинающих

D>>секции лучше чем их отсутствие, = — это привычный значок "равно", а не "присвоить" и т.п.

VD>И чем он привычен тем кто никогда не программировал на Паскале. Для меня := было дико непривычно, так как начинал писать я на С, но я прекрасно понимаю, что такова семантика языка.

Привычен для тех, кто вообще никогда ни на чем не программировал, а вот математика в школе была. Для таких начинающих, x=2 — это утверждение, а не действие. А понятия присваивания в курсе математики вообще нет. Логично, что для этого нового понятия новый значок использовать.

VD>А весь бред который несут Вирт и его поклонники легко разбивается примером BNF где := было использовано для задания правил, которые ну, никак присвоением не обозвать. Это именно что равенство (имени правила его тлу).

А в BNF ::= это не присваивание и не равенство, это разделитель. Он отделяет нетерминал слева от правила справа.

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

E>>А для того, чтобы не приявязывать lambda к локальному контексту (доступ к occur, например) можно применить такой метод bind-инга параметров:
E>>

E>>for_each( begin(a), end(a),
E>>        void lambda( const int & x, map_t & m = occur )
E>>            { if( x < 7 ) m[ x ]++; }
E>>    );
E>>

WH>А смысл? ИМХО компилятор сможет легко сам найти на какие имена ссылается лямбда.

Нет, смысл в том, чтобы можно было использовать приведения типов, а внутри лямбда проверять совпадения типов. Например, представь, что occur -- это не map_t, а какой-то другой тип, который умеет приводиться к map_t. Или мы хотим объявить m константной ссылкой. Или вообще передавать m по значению.

VladD2,

> Кстаит, Паш, а ты смотрел ОКамл и другие МЛ-подобные языки?

Потихоньку.

> Ведь то что тебе нравится в С++ там реализовано несравннено лучше.

Интересно, что же это?

> По скорости некоторые компиляторы ОКамла не хуже VC7.

Это для меня имеет косвенное значение.

> Что мешает перейти?

Вопрос (пока?) так вообще не стоит. Главного возможного мотива, существенной неудовлетворенности использованием C++, в нашей команде незаметно; пока, скорее, наоборот. Таким образом, речь о переходе на другой язык могла бы идти в основном в случае, если бы этот переход сулил бы нам какие-то существенные преимущества. Соответственно, прежде, чем задавать вопрос в таком виде, нужно очень хорошо себе представить, что именно это нам может дать, и чего это нам будет стоить. Этого анализа никто пока не делал.

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

WH>Да и вобще если уж на то пошло то так:
WH>

WH>for_each( begin(a), end(a),
WH>        ( auto const& x) =>
WH>            { if( x < 7 ) occur[ x ]++; }
WH>    );
WH>

Если честно, то можно обойтись только параметрами, предопределёнными компилятором: _1, _2, _3, и т.д. Не путать с Boost'ом. Эти параметры будут иметь специальное значение внутри ламбда выражений и функций. Как например:

for_each(begin(a), end(a), {if (_1 < 7) occur[_1]++});

Или более развёрнуто:

for_each(begin(a), end(a),
    {
        auto x = _1;
        if (x < 7)
            occur[x]++;
    } );

То бишь узаконим существующую практику. То же удобство, что и в Boost'е, только поддерживаемое языком напрямую. Возможности здесь, конечно, гораздо превосходят Boost'овские. Такие вещи, как occur[_1]++ или _1.first с помощью Boost.Lambda сделать нельзя.

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

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

VD>>А весь бред который несут Вирт и его поклонники легко разбивается примером BNF где := было использовано для задания правил, которые ну, никак присвоением не обозвать. Это именно что равенство (имени правила его тлу).

Т>Во первых, не :=, а ::= .

Да, но сути дела это не меняет. Все равно похоже.

Т> Во-вторых, не равенство.

А что же? Натуральный спец. язык определения краматик.