Re[3]: C++ операция запятая - Философия программирования

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

Q>>В C# не хватает возможности ограничить область видимости «let-привязки» вычисляемым выражением: http://bik-top.livejournal.com/50984.html.

L>А что, фигурные скобки уже запретили?

Фигурные скобки были упомянуты:

«Можно использовать для sin_φ естественные ограничители скоупа:
double y;
{
    double const sin_φ = sin(φ);
    y = 0.5 * log((1.0 + sin_φ) / (1.0 - sin_φ));
}
Но теперь переменная y перестаёт быть константой, помимо объявлений/определений появляются присваивания. Усугубляется тем, что всё вышеизложенное касается не только переменной y, но и любой другой переменной в примере.»

L>Если первоначальный код с какой-то натяжкой еще можно согласиться и признать непонятным, то окончательный вариант просто ужасен. :down:

Он ужасен только в Си-подобных языках, в ML-подобных языках всё хорошо. «Окончательный вариант» — всего лишь обоснование принципиальной возможности добиться нужного поведения в императивных языках с анонимными функциями — просто на основании того, что обсуждаемые конструкции являются не более чем синтаксическим сахаром в рамках лямбда-исчисления:

let x : σ = N in M ≝ (λx : σ. M) N
M where x : σ = N  ≝ (λx : σ. M) N

Никто не настаивает на использовании приведённых C#-аналогов требуемых ML-конструкций. Если бы я считал их практичными, я б не жаловался в этот тред на недостаток нужных мне возможностей :)

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

L>>А что, фигурные скобки уже запретили?

Q>Фигурные скобки были упомянуты:
Q>

«Можно использовать для sin_φ естественные ограничители скоупа:
Q>
Q>double y;
Q>{
Q>    double const sin_φ = sin(φ);
Q>    y = 0.5 * log((1.0 + sin_φ) / (1.0 - sin_φ));
Q>}
Q>
Q>Но теперь переменная y перестаёт быть константой, помимо объявлений/определений появляются присваивания. Усугубляется тем, что всё вышеизложенное касается не только переменной y, но и любой другой переменной в примере.»

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

L>>Если первоначальный код с какой-то натяжкой еще можно согласиться и признать непонятным, то окончательный вариант просто ужасен.

Q>Он ужасен только в Си-подобных языках, в ML-подобных языках всё хорошо.

Ну как же так, совсем не хорошо: radiansPerDegree фигурирует в выражении только как правый операнд оператора "*", однако "светится" и там, где его быть не полжно (справа). Непорядок.

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

L>Лично мне:

L>1. const для локальных переменных
L>2. паттерн-матчинг
L>3. нормалный синтаксис для туплов
L>4. локальные функции с нормальным синтаксисом
L>5. вывод типов для приватных методов
L>6. yield в лямбдах
L>7. string interpolation (хз как правильно называть)
L>8. Свободные функции (без класса)
L>9. Вызов extension-методов без this
L>10. Поддержка паралельности на уровне синтаксиса (async не щупал)
11. Поддержка "ленивых" const переменных на уровне синтаксиса.

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

Ф>Есстественно, что имеется ввиду язык, на котором вы специализируетесь, т.е. если вы пишете на ЯП "А", но раз в неделю вам приходится написать 10 строчек на ЯП "Б", то не надо писать о "Б".

Ф>Пожалуйста, выносите в заголовок ответа название языка.

Ф>Очень надеюсь, что ветка не скатися в холливар.

C++ невозможно отличить создание временнoгo обьекта от вызова функции:

int a = foo(B(x)); — что здесь B(x) ?

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

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

L>1. const для локальных переменных
L>2. паттерн-матчинг
L>3. нормалный синтаксис для туплов
L>4. локальные функции с нормальным синтаксисом
L>5. вывод типов для приватных методов
L>6. yield в лямбдах
L>7. string interpolation (хз как правильно называть)
L>8. Свободные функции (без класса)
L>9. Вызов extension-методов без this
L>10. Поддержка паралельности на уровне синтаксиса (async не щупал)

Хотел перечислить фичи Nemerle которых мне не хватает в C#, но ты меня опередил

11. метапрограммирование

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

Z>Хотел перечислить фичи Nemerle которых мне не хватает в C#, но ты меня опередил

Z>11. метапрограммирование

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

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

С>C++ невозможно отличить создание временнoгo обьекта от вызова функции:

С>int a = foo(B(x)); — что здесь B(x) ?

А это действительно важно? Конструктор ведь и есть функция создающая объект.

C++, неявное преобразование signed <-> unsigned

I>C++, неявное преобразование signed <-> unsigned

варнинги же

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

L>Ну так это совсем другая проблема — невозможность объявить такую перепенную константной, хотя она очевидно таковой является.

Так даже если такую возможность добавить в C#, в данном случае воспользоваться ей будет нельзя (по той же причине, по которой нельзя в C++).

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

L>>Ну так это совсем другая проблема — невозможность объявить такую перепенную константной, хотя она очевидно таковой является.

I>Так даже если такую возможность добавить в C#, в данном случае воспользоваться ей будет нельзя (по той же причине, по которой нельзя в C++).

Почему?

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

L>Почему?

Там же написано: потому что "помимо объявлений/определений появляются присваивания".

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

С>C++ невозможно отличить создание временнoгo обьекта от вызова функции:
С>int a = foo(B(x)); — что здесь B(x) ?

И не надо. Считай конструктор функцией, возвращающей экземпляр объекта. Тем более, что это позволяет создавать конструктороподобные функции с сохранением синтаксиса:

class Point
{
    Point(double x, double y);
    . . .
};

Point polarPoint(double ρ, double φ);

doSomething(Point(1, 2));
doSomething(polarPoint(3, 4));

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

typename. В половине случаев обязательно, в остальных случаях недопустимо, что затрудняет написание макросов. А кроме того, я считаю, что синтаксически оно ставится не туда:

// сейчас
typename std::iterator_traits<I>::reference r = c.front();

// логичнее
std::iterator_traits<I>::typename reference r = c.front();

поскольку вся суть typename здесь в том, чтобы сказать, что «reference» есть имя типа (type name), вот возле этого идентификатора ему бы и стоило находиться. Заодно были бы решены вот такие проблемы:

#define HOMEMADE_TYPEOF(x) /* typename? */ SomeHelper<sizeof(darkWizardry(x))>::type

template <class X>
void f(X x)
{
    typedef HOMEMADE_TYPEOF(x) T;
    // typedef typename SomeHelper<. . .>::type T;
    // требуется typename, чтобы отметить идентификатор type как имя типа

    int const y = HOMEMADE_TYPEOF(x)::some_const;
    // int const y = SomeHelper<. . .>::type::some_const;
    // требуется отсутствие typename, иначе оно бы распространялось на имя some_const
}

// то ли дело, если typename стоит перед своим идентификатором:

#define HOMEMADE_TYPEOF(x) SomeHelper<sizeof(darkWizardry(x))>::typename type

template <class X>
void f(X x)
{
    typedef HOMEMADE_TYPEOF(x) T;
    // typedef SomeHelper<. . .>::typename type T;
    // type должным образом отмечен как имя типа

    int const y = HOMEMADE_TYPEOF(x)::some_const;
    // int const y = SomeHelper<. . .>::typename type::some_const;
    // type — имя типа (что избыточно, :: и так говорит об этом), some_const — нет
}

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

L>>Почему?

I>Там же написано: потому что "помимо объявлений/определений появляются присваивания".

Там же написано:

то совсем другая проблема — невозможность объявить такую перепенную константной, хотя она очевидно таковой является

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

D>варнинги же

На уровне по умолчанию VS их не выдает.

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

L>Там же написано:
L>

L>то совсем другая проблема — невозможность объявить такую перепенную константной, хотя она очевидно таковой является

goto здесь

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

Ф>но раз в неделю вам приходится написать 10 строчек на ЯП "Б", то не надо писать о "Б".

а если я всего 10 строчек кода в неделю пищу, то уже и совсем отвечать не стоит?

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

L>>Там же написано:
L>>

L>>то совсем другая проблема — невозможность объявить такую перепенную константной, хотя она очевидно таковой является

I>goto здесь

Идите подумайте, что именно я написал. В частности, рекомендую помедитировать над частью "хотя она очевидно таковой является".

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

Ф>Пожалуйста, выносите в заголовок ответа название языка.

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

def make_list(element, head=[]):
    head.append(element)
    return head

print make_list(42)
print make_list(42)

и http://rsdn.ru/forum/dynamic/3587540.1.aspx

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

L>Идите подумайте, что именно я написал. В частности, рекомендую помедитировать над частью "хотя она очевидно таковой является".

Есть!

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

L>Идите подумайте, что именно я написал. В частности, рекомендую помедитировать над частью "хотя она очевидно таковой [константной] является".

Кому очевидно? Переменная y (жаль, что повсеместно используется термин variable вместо assignable) уже не является константной, а всего лишь монотонной. В общем случае между объявлением и окончательным присваиванием может произойти выброс исключения с последующей ловлей. Так что даже компилятору будет тяжело поручиться в том, что y «на самом деле» константа.

Q>В общем случае между объявлением и окончательным присваиванием может произойти выброс исключения с последующей ловлей.

А в let-е его не может произойти?

Q>Так что даже компилятору будет тяжело поручиться в том, что y «на самом деле» константа.

Нет никаких сложностей.

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

Q>>а всего лишь монотонной.
L>Нет, она является кусочно-постоянно. :-\

Я использовал термин «монотонное изменение состояния» в смысле, как в статье Кирпичёва, на которую выше давал ссылку.

Q>>В общем случае между объявлением и окончательным присваиванием может произойти выброс исключения с последующей ловлей.
L>А в let-е его не может произойти?

В синтаксисе let/where нельзя выцепить момент, в котором можно использовать переменную y до получения ею требуемого значения. А в C++/C# можно. Скажем, блок catch, если вызов sin бросит исключение в блоке try.

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

L>>Идите подумайте, что именно я написал. В частности, рекомендую помедитировать над частью "хотя она очевидно таковой [константной] является".

Q>Кому очевидно? Переменная y (жаль, что повсеместно используется термин variable вместо assignable) уже не является константной, а всего лишь монотонной. В общем случае между объявлением и окончательным присваиванием может произойти выброс исключения с последующей ловлей. Так что даже компилятору будет тяжело поручиться в том, что y «на самом деле» константа.

Просто смотри на блок кода, в котором происходит присваивание как на сахар над вызовом лямбды и тогда все встанет на свои места.

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

Q>>>а всего лишь монотонной.
L>>Нет, она является кусочно-постоянно.

Q>Я использовал термин «монотонное изменение состояния» в смысле, как в статье Кирпичёва, на которую выше давал ссылку.

Ок. Больше так не делай.

Q>>>В общем случае между объявлением и окончательным присваиванием может произойти выброс исключения с последующей ловлей.
L>>А в let-е его не может произойти?

Q>В синтаксисе let/where нельзя выцепить момент, в котором можно использовать переменную y до получения ею требуемого значения. А в C++/C# можно. Скажем, блок catch, если вызов sin бросит исключение в блоке try.

Я писал не о реальном языке, а о гипотетической фиче. С учетом этого, в чем смысл аппелирования к C++/C# с их "можно/неможно"?

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

L>Просто смотри на блок кода, в котором происходит присваивание как на сахар над вызовом лямбды и тогда все встанет на свои места.

Хотел бы, да не могу. Это ж императивные языки, тут превалируют statements, а не expressions. И они выполняются в определённом порядке, это надо учитывать.

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

L>>Просто смотри на блок кода, в котором происходит присваивание как на сахар над вызовом лямбды и тогда все встанет на свои места.

Q>Хотел бы, да не могу. Это ж императивные языки, тут превалируют statements, а не expressions.

Это не важно. Разбей в своем примере присваение и декларацию переменной и попробуй между ними вставить обращение к это переменной. Компилятор отследит использование неинициализированной переменной. Как видиш, никаких сложностей с этим нет. Осталось только убедить компилятор, что присваивать значение повторно такой переменной нельзя.

Q>И они выполняются в определённом порядке, это надо учитывать.

Это не имеет отношения.

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

L>Я писал не о реальном языке, а о гипотетической фиче. С учетом этого, в чем смысл аппелирования к C++/C# с их "можно/неможно"?

Смотри. Я считаю, что в C++/C# проблема ограничения видимости переменной в выражениях связана с отсутствием синтаксической поддержки ограничения видимости переменной в выражениях. И при переходе от гипотетической фичи к практическому расширению языка, имхо, стоит добавить эту самую синтаксическую поддержку аналогов let-in/where (например, как обёртку над замыканиями).

Ты же говоришь, что проблема ограничения видимости переменной в выражениях связана с отсутствием гибких возможностей по декларированию константности, а ограничение скоупа уже есть в виде фигурных скобок (хотя они в C++/C# ограничивают блок операторов, а не выражений). Хотя фактически, константность тут не при чём. Пусть, скажем, y задумана быть изменяемой (если язык допускает). Что-то типа такого (на псевдокоде):

mutable y = f(sin_φ) where sin_φ = sin(φ)
...
y = g(cos_φ) where cos_φ = cos(φ)

Уже константности от y никто не требует, но нотация с фигурными скобками и присваиванием по-прежнему скользкая в виду тех же самых исключений. Если в приведённом коде y может принимать только два значения (или не принимать их в случае исключения), то в C++/C#-коде к ним добавляется потенциально достижимое состояние, когда y не определена (или инициализирована по умолчанию).

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

L>>Я писал не о реальном языке, а о гипотетической фиче. С учетом этого, в чем смысл аппелирования к C++/C# с их "можно/неможно"?

Q>Смотри. Я считаю, что в C++/C# проблема ограничения видимости переменной в выражениях связана с отсутствием синтаксической поддержки ограничения видимости переменной в выражениях. И при переходе от гипотетической фичи к практическому расширению языка, имхо, стоит добавить эту самую синтаксическую поддержку аналогов let-in/where (например, как обёртку над замыканиями).

Аналог let-а — это полумера, т.к. проблема скоупа переменной останется проблемой для конструкций, не являющихся выражениями (например, циклы).

Q>Ты же говоришь, что проблема ограничения видимости переменной в выражениях связана с отсутствием гибких возможностей по декларированию константности, а ограничение скоупа уже есть в виде фигурных скобок (хотя они в C++/C# ограничивают блок операторов, а не выражений). Хотя фактически, константность тут не при чём.

Константность тут очень даже причем. Озвученая проблема скоупа решается блоком {}, но когда мы используем такое решение, то вылазит проблема ограниченности понятия константности.

Q>Пусть, скажем, y задумана быть изменяемой (если язык допускает). Что-то типа такого (на псевдокоде):
Q>

Q>mutable y = f(sin_φ) where sin_φ = sin(φ)
Q>...
Q>y = g(cos_φ) where cos_φ = cos(φ)
Q>

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

Я не понимаю, где скользкость? И какое отношение пример с mutable имеет к обсуждению костантности тоже не понимаю.

Q>Если в приведённом коде y может принимать только два значения (или не принимать их в случае исключения), то в C++/C#-коде к ним добавляется потенциально достижимое состояние, когда y не определена (или инициализирована по умолчанию).

Как в приведенном примере достить такого состояния?

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

L>Аналог let-а — это полумера, т.к. проблема скоупа переменной останется проблемой для конструкций, не являющихся выражениями (например, циклы).

Ну и что, что полумера. Мне для выражений важнее, потому что я предпочитаю их операторам.

L>И какое отношение пример с mutable имеет к обсуждению костантности тоже не понимаю.

Отношение такое: даже в случае, когда не требуется константность, декларативный expressions based синтаксис с let-in/where «прямее» и безопаснее, чем императивный statements based синтаксис «1) объявить переменную; 2) изменить переменную в фигурных скобках».

Q>>Если в приведённом коде y может принимать только два значения (или не принимать их в случае исключения), то в C++/C#-коде к ним добавляется потенциально достижимое состояние, когда y не определена (или инициализирована по умолчанию).
L>Как в приведенном примере достить такого состояния?

На C++ не писал очень давно, так что извините, если что.

#include <cstdlib>
#include <iostream>
#include <stdexcept>

#define _USE_MATH_DEFINES
#include <math.h>

namespace
{
    double my_sin(double φ)
    {
        if (::rand() % 2 == 1)
            throw std::runtime_error("Some failure.");
        else
            return ::sin(φ);
    }
}

int main(int argc, char const* argv[])
{
    double const latitude = 37.0;
    double const radiansPerDegree = M_PI / 180.0;
    double const φ = latitude * radiansPerDegree;
    double y;
    try
    {
        double const sin_φ = my_sin(φ);
        y = 0.5 * ::log((1.0 + sin_φ) / (1.0 - sin_φ));
    }
    catch (std::runtime_error const&)
    {
    }
    
    std::cout << y << std::endl;

    return 0;
}

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

L>>Аналог let-а — это полумера, т.к. проблема скоупа переменной останется проблемой для конструкций, не являющихся выражениями (например, циклы).

Q>Ну и что, что полумера. Мне для выражений важнее, потому что я предпочитаю их операторам.

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

L>>И какое отношение пример с mutable имеет к обсуждению костантности тоже не понимаю.

Q>Отношение такое: даже в случае, когда не требуется константность, декларативный expressions based синтаксис с let-in/where «прямее» и безопаснее, чем императивный statements based синтаксис «1) объявить переменную; 2) изменить переменную в фигурных скобках».

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

Q>>>Если в приведённом коде y может принимать только два значения (или не принимать их в случае исключения), то в C++/C#-коде к ним добавляется потенциально достижимое состояние, когда y не определена (или инициализирована по умолчанию).
L>>Как в приведенном примере достить такого состояния?

Q>На C++ не писал очень давно, так что извините, если что.
Q>

Q>#include <cstdlib>
Q>#include <iostream>
Q>#include <stdexcept>

Q>#define _USE_MATH_DEFINES
Q>#include <math.h>

Q>namespace
Q>{
Q>    double my_sin(double φ)
Q>    {
Q>        if (::rand() % 2 == 1)
Q>            throw std::runtime_error("Some failure.");
Q>        else
Q>            return ::sin(φ);
Q>    }
Q>}

Q>int main(int argc, char const* argv[])
Q>{
Q>    double const latitude = 37.0;
Q>    double const radiansPerDegree = M_PI / 180.0;
Q>    double const φ = latitude * radiansPerDegree;
Q>    double y;
Q>    try
Q>    {
Q>        double const sin_φ = my_sin(φ);
Q>        y = 0.5 * ::log((1.0 + sin_φ) / (1.0 - sin_φ));
Q>    }
Q>    catch (std::runtime_error const&)
Q>    {
Q>    }
    
Q>    std::cout << y << std::endl;

Q>    return 0;
Q>}
Q>

И в этом случае компилятор не ругнется на использование неинициализированной переменной? Имхо, если это так, то это скорее упущение в компиляторе, но не свидетельство некорректности концепции.

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

L>Ну я лично предпочитаю решения, покрывающие все случаи, а не только частности.

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

L>Чо-та я опять не догоняю. В чем потоенный смысл рассмотрения не-константных переменных в ветке, посвязенной обсуждению их констатнных братьев.

Ветка посвящена не константности, а проблеме ограничения видимости. В частности, критиковалось такое решение этой проблемы: «1) Объявление; 2) Блок с присваиванием; 3) Использование». В качестве аргумента высказывались соображения константности. Но теперь вместо этого аргумента используются соображения безопасности, не имеющие отношения к константности. Наоборот, рассматривается случай, где константность не только недостижима, но и по каким-то соображениям нежелательна (скажем, дальше y передаётся в third-party функцию по ссылке на неконстанту для чтения и изменения). Всё, забудь про константность. Добавление хитрой константности в язык решит только пол-проблемы, ты же «лично предпочитаешь решения, покрывающие все случаи, а не только частности».

L>И в этом случае компилятор не ругнется на использование неинициализированной переменной? Имхо, если это так, то это скорее упущение в компиляторе, но не свидетельство некорректности концепции. :xz:

Боюсь, что это упущение в языке. Компилятор не может в compile-time понять, будет ли присвоена переменная y в run-time. А если вообще запретить использование «сомнительной» переменной y вне try-catch-блока, то где ж её тогда использовать? Внутри нельзя, мы ж специально старались вынести работу с y из скоупа, чтоб не мешали вспомогательная переменные типа sin_φ.

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

Ф>Что вам не нравится в языке, на котором вы пишете

В шарпе не хватает NotNullable типов классов. Будь такие типы код бы стал проще и надежнее.

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

L>>Ну я лично предпочитаю решения, покрывающие все случаи, а не только частности.

Q>Я предпочитаю два частных, но удобных решения для разных нужд, чем одно общее, но страшное решение для, опять таки, разных нужд.

Не могу не согласиться. А какое решение для второго случая?

L>>Чо-та я опять не догоняю. В чем потоенный смысл рассмотрения не-константных переменных в ветке, посвязенной обсуждению их констатнных братьев.

Q>Ветка посвящена не константности, а проблеме ограничения видимости. В частности, критиковалось такое решение этой проблемы: «1) Объявление; 2) Блок с присваиванием; 3) Использование». В качестве аргумента высказывались соображения константности. Но теперь вместо этого аргумента используются соображения безопасности, не имеющие отношения к константности. Наоборот, рассматривается случай, где константность не только недостижима, но и по каким-то соображениям нежелательна

А если нежелательна константность, то и let — неприменим. Я правильно тебя понимаю, что ты теперь стал против испорльзования let-а?

Q>(скажем, дальше y передаётся в third-party функцию по ссылке на неконстанту для чтения и изменения).

Ок. И как такая передача будет выглядеть для let-выражения?

Q>Всё, забудь про константность. Добавление хитрой константности в язык решит только пол-проблемы, ты же «лично предпочитаешь решения, покрывающие все случаи, а не только частности».

"Добавление хитрой константности" решит озвученную проблему со скоупом.

L>>И в этом случае компилятор не ругнется на использование неинициализированной переменной? Имхо, если это так, то это скорее упущение в компиляторе, но не свидетельство некорректности концепции.

Q>Боюсь, что это упущение в языке. Компилятор не может в compile-time понять, будет ли присвоена переменная y в run-time.

Зато компилятор может понять, что она может быть не присвоена.

Q>А если вообще запретить использование «сомнительной» переменной y вне try-catch-блока, то где ж её тогда использовать? Внутри нельзя, мы ж специально старались вынести работу с y из скоупа, чтоб не мешали вспомогательная переменные типа sin_φ.

Ее можно использовать извне, но надо убедиться, что она корректно проинициализирована. Например, можно убедиться, что внутри всех catch блоков без throw есть присваивание ей значения.

Я на самом деле не понимаю, о чем спор. Вариант с хитрой константностью сводим к не-хитрой константе с инициализацией вызовом лямбды:

const' double y;
{
    try
    {
        double const sin_φ = my_sin(φ);
        y = 0.5 * ::log((1.0 + sin_φ) / (1.0 - sin_φ));
    }
    catch (std::runtime_error const&)
    {
    }
}

эквивалентен

const double y = ((Func<double>) (() => 
{
    double y;
    try
    {
        double const sin_φ = my_sin(φ);
        y = 0.5 * ::log((1.0 + sin_φ) / (1.0 - sin_φ));
    }
    catch (std::runtime_error const&)
    {
    }
    return y;
}))();

Если ты видишь проблемы в первом варианте, то и во втором они тоже должны присутствовать. Можешь показать, как они будут выглядеть?

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

...

Много букв приходится писать. Например
вместо void func(par) нужно городить template<typename T> void func(T par),
вместо this->bar() — static_cast<T*>(this)->bar() и в таком духе.

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

L>>Лично мне:

L>>1. const для локальных переменных
L>>2. паттерн-матчинг
L>>3. нормалный синтаксис для туплов
L>>4. локальные функции с нормальным синтаксисом
L>>5. вывод типов для приватных методов
L>>6. yield в лямбдах
L>>7. string interpolation (хз как правильно называть)
L>>8. Свободные функции (без класса)
L>>9. Вызов extension-методов без this
L>>10. Поддержка паралельности на уровне синтаксиса (async не щупал)
L>11. Поддержка "ленивых" const переменных на уровне синтаксиса.

Гулять, так гулять.
12. .? оператор.

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

U>В шарпе не хватает NotNullable типов классов. Будь такие типы код бы стал проще и надежнее.
Правильное решение вообще выкинуть Null, а тем где нужно опциональное значение использовать тип Option[T] с двумя вариантами None и Some(T).
Причем чтобы достать оттуда значение нужно явно проверить, что там что-то есть.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

WH>Правильное решение вообще выкинуть Null, а тем где нужно опциональное значение использовать тип Option[T] с двумя вариантами None и Some(T).
WH>Причем чтобы достать оттуда значение нужно явно проверить, что там что-то есть.

Если действо будет происходить на Nemerle, то на 3-й день будет написан макрос, который забьет большой болт на эти проверки и "упростит" жизнь программисту.

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

L>Если действо будет происходить на Nemerle, то на 3-й день будет написан макрос, который забьет большой болт на эти проверки и "упростит" жизнь программисту.

На немерле null никто не использует. За исключением случая общения с внешними либами.
Все используют описанный вариант.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

L>Гулять, так гулять.
L>12. .? оператор.
А вот это в немерле сделано макросом...

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

Z>>Хотел перечислить фичи Nemerle которых мне не хватает в C#, но ты меня опередил

Z>>11. метапрограммирование

L>Не нужно. В конечном итоге приведет к адовому кол-ву несовместимых "языков". Фича интересная "на поиграться", но в реальной жизни лучше лишний раз перестраховаться, чем потом разгребать тонны "гениальных" свистелок.

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

Предлагаю запретить референсить в проекты всё кроме либ фреймворка подписанного строгой подписью от MS. Остальные "гениальные" свистелки просто не нужны, стандартный фреймворк дает достаточно средств для реализации любого функционала ради которого делаются эти велосипеды.

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

L>>Не нужно. В конечном итоге приведет к адовому кол-ву несовместимых "языков". Фича интересная "на поиграться", но в реальной жизни лучше лишний раз перестраховаться, чем потом разгребать тонны "гениальных" свистелок.

Z>Как страшно жить. Сейчас все сводится к адову количеству несовместимых библиотек.

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

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

L>Нет никаких проблем с несовместимыми библиотеками, не выдумывайте.
L>Но даже если бы они и были, то это не повод усугублять ситуацию.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

L>>Нет никаких проблем с несовместимыми библиотеками, не выдумывайте.
L>>Но даже если бы они и были, то это не повод усугублять ситуацию.

WH>Нет никаких проблем с несовместимыми макросами, не выдумывайте.

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

WH>Но даже если бы они и были, то это не повод усугублять ситуацию.

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

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

I>На уровне по умолчанию VS их не выдает.

поменяйте уровень по умолчанию

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

L>Их нет потому что их никто не использует.
Я использую.

L>А вот в лиспе использовали и если погуглите, то сможете найти восторженные отзывы тех, кому довелось с столкнуться с использованием чутка различающейся семантики одого и того же "кода".

Ссылку дай.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

L>>Их нет потому что их никто не использует.
WH>Я использую.

Это очень ценный ответ, особенно в свете обсуждения несовместимости разных реализаций.

L>>А вот в лиспе использовали и если погуглите, то сможете найти восторженные отзывы тех, кому довелось с столкнуться с использованием чутка различающейся семантики одого и того же "кода".

WH>Ссылку дай.

Увы, не дам. Если хочешь, можешь считать это признаком слива. Если действительно интересно, то воспользуйся гуглом.

L>>Ну вот и не усугубляйте. Добавление фичи в язык — проблема сложная не технически, а концептуально. Нужно чтобы фича хорошо "легла" на язык, чтобы грамотно состыковалась с остальными фичами. Путем выставления потрохов компилятора наружу и разрешения всем и каждому менять синтаксис, эта проблема не решается.
WH>Круть макросов немерла в том что они точно как библиотеки. Не хочешь не используешь.

Клева. А я-то, дурак, не знал. Ниче, что вы в каждой первой статье о Немерле об этом пишете?

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

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

L>Не могу не согласиться. А какое решение для второго случая?

Это ты про него упомянул. Сформулируй на примере, что ты имеешь в виду. Мне же достаточно, чтоб я мог в выражениях «скрывать» используемые обозначения для подвыражений.

L>А если нежелательна константность, то и let — неприменим. Я правильно тебя понимаю, что ты теперь стал против испорльзования let-а? :)

Почему?

mutable y =
  let sin_φ = sin(φ) in
  f(sin_φ)
... // Здесь уже sin_φ нет, что и требовалось.

Мне в C++ не хватает как раз let-in для внутренних подвыражений, здесь sin_φ. В случае фигурных скобок в C++ возникает проблема с константностью внешнего выражения. Но даже если константность внешнего выражения не требуется, проблема с видимостью по прежнему остаётся. Так что добавление хитрой константности в C++ не решит проблему для тех случаев, где она не требуется.

L>Ок. И как такая передача будет выглядеть для let-выражения?

В F# синтаксис позволяет сделать объявление и инициализацию y (пусть даже мутабельной переменной) одновременно, поэтому у тебя нет синтаксической возможности обратиться к переменной где-то в момент между её созданием и присваиванием. Этот аспект не связан с константностью, почему ты этого не хочешь признавать?

L>"Добавление хитрой константности" решит озвученную проблему со скоупом.

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

L>Зато компилятор может понять, что она может быть не присвоена.

Ок, и как он должен на это реагировать?

L>Я на самом деле не понимаю, о чем спор. Вариант с хитрой константностью сводим к не-хитрой константе с инициализацией вызовом лямбды:
L>

L>const' double y;
L>{
L>    try
L>    {
L>        double const sin_φ = my_sin(φ);
L>        y = 0.5 * ::log((1.0 + sin_φ) / (1.0 - sin_φ));
L>    }
L>    catch (std::runtime_error const&)
L>    {
L>    }
L>}
L>

L>эквивалентен
L>

L>const double y = ((Func<double>) (() => 
L>{
L>    double y;
L>    try
L>    {
L>        double const sin_φ = my_sin(φ);
L>        y = 0.5 * ::log((1.0 + sin_φ) / (1.0 - sin_φ));
L>    }
L>    catch (std::runtime_error const&)
L>    {
L>    }
L>    return y;
L>}))();
L>

L>Если ты видишь проблемы в первом варианте, то и во втором они тоже должны присутствовать. Можешь показать, как они будут выглядеть?

Точно так же будут выглядеть. Из лямбды вернётся неинициализированная (неконстантная, кстати) локальная переменная y.
Нужно было проще:

double const y = [=]() -> double
    {
        double const sin_φ = my_sin(φ);
        return 0.5 * ::log((1.0 + sin_φ) / (1.0 - sin_φ));
    }();

Это примерно то, что ты назвал «ужасным окончательным вариантом» из поста в начале ветки. И к константности это не имеет абсолютно никакого отношения. Да, в C++0x и в C# такая конструкция применяется для инициализации константных значений (я же про это и писал), но это всего лишь частный случай применения такого сокрытия скоупа путём упаковывания нескольких байндингов в одну анонимную функцию.

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

L>Увы, не дам. Если хочешь, можешь считать это признаком слива. Если действительно интересно, то воспользуйся гуглом.
Ой напугал

L>Клева. А я-то, дурак, не знал. Ниче, что вы в каждой первой статье о Немерле об этом пишете?

Похоже, что нет.

L>Да, и какое отношение твой ответ имеет в вопросу концептуальной сложности добавления фич в язык?
Это я не понимаю, какое отношение твой наезд на макросы имеет к добавлению фич в язык?
Меж тем разница огромна. В случае с монолитным языком фича добаляется для всех и навсегда.
В случае с макросами фичу используют только те, кому она нужна и только пока нужна.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

L>>Не могу не согласиться. А какое решение для второго случая?

Q>Это ты про него упомянул. Сформулируй на примере, что ты имеешь в виду. Мне же достаточно, чтоб я мог в выражениях «скрывать» используемые обозначения для подвыражений.

Я там привел пример — например, выражение, содержащие циклы.

L>>А если нежелательна константность, то и let — неприменим. Я правильно тебя понимаю, что ты теперь стал против испорльзования let-а?

Q>Почему?
Q>

Q>mutable y =
Q>  let sin_φ = sin(φ) in
Q>  f(sin_φ)
Q>... // Здесь уже sin_φ нет, что и требовалось.
Q>

И почему такой подход не применим в моем случае?

Q>Мне в C++ не хватает как раз let-in для внутренних подвыражений, здесь sin_φ. В случае фигурных скобок в C++ возникает проблема с константностью внешнего выражения. Но даже если константность внешнего выражения не требуется, проблема с видимостью по прежнему остаётся. Так что добавление хитрой константности в C++ не решит проблему для тех случаев, где она не требуется.

То, о чем мы ведем речь — это 2 независимых понятия: константность и проверка инициализированности. константность — это что переменную нельзя менять после инициазизации, "хитрая" инициализированность — это что переменная должна быть инициализирована до того, как к ней начали обращаться. если тебе не нужна константность, то просто делаешь переменную неконстантной, но инициализацию оставляешь "хитрой".

L>>Ок. И как такая передача будет выглядеть для let-выражения?

Q>В F# синтаксис позволяет сделать объявление и инициализацию y (пусть даже мутабельной переменной) одновременно, поэтому у тебя нет синтаксической возможности обратиться к переменной где-то в момент между её созданием и присваиванием. Этот аспект не связан с константностью, почему ты этого не хочешь признавать?

Я тебя просто неправильно понял. Я подумал, что ты говоришь о модификации перепенной, связанной в let-е.

L>>"Добавление хитрой константности" решит озвученную проблему со скоупом.

Q>Наоборот. Способ, изложенный тобой ниже (по сути, повторенный из поста), будет решением проблемы со скоупом, которое помимо прочего решит проблему с константностью. (Точнее, от неё никак не зависит, хочешь — объявляй переменную константой, не хочешь — не объявляй.)

L>>Зато компилятор может понять, что она может быть не присвоена.

Q>Ок, и как он должен на это реагировать?

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

L>>Я на самом деле не понимаю, о чем спор. Вариант с хитрой константностью сводим к не-хитрой константе с инициализацией вызовом лямбды:
L>>

L>>const' double y;
L>>{
L>>    try
L>>    {
L>>        double const sin_φ = my_sin(φ);
L>>        y = 0.5 * ::log((1.0 + sin_φ) / (1.0 - sin_φ));
L>>    }
L>>    catch (std::runtime_error const&)
L>>    {
L>>    }
L>>}
L>>

L>>эквивалентен
L>>

L>>const double y = ((Func<double>) (() => 
L>>{
L>>    double y;
L>>    try
L>>    {
L>>        double const sin_φ = my_sin(φ);
L>>        y = 0.5 * ::log((1.0 + sin_φ) / (1.0 - sin_φ));
L>>    }
L>>    catch (std::runtime_error const&)
L>>    {
L>>    }
L>>    return y;
L>>}))();
L>>

L>>Если ты видишь проблемы в первом варианте, то и во втором они тоже должны присутствовать. Можешь показать, как они будут выглядеть?

Q>Точно так же будут выглядеть. Из лямбды вернётся неинициализированная (неконстантная, кстати) локальная переменная y.
Q>Нужно было проще:
Q>

Q>double const y = [=]() -> double
Q>    {
Q>        double const sin_φ = my_sin(φ);
Q>        return 0.5 * ::log((1.0 + sin_φ) / (1.0 - sin_φ));
Q>    }();
Q>

Не понимаю. С какого перепуга она неинициализированная?

Q>Это примерно то, что ты назвал «ужасным окончательным вариантом» из поста в начале ветки.

Именно потому, что этот вариант ужасен, я и предлагаю сахар.

Q>И к константности это не имеет абсолютно никакого отношения. Да, в C++0x и в C# такая конструкция применяется для инициализации константных значений (я же про это и писал), но это всего лишь частный случай применения такого сокрытия скоупа путём упаковывания нескольких байндингов в одну анонимную функцию.

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

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

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

Интересно было наблюдать, как некоторые противники var, в следующем холиваре становятся его сторонниками (просто, за это время, они поели устриц). Буквально вчера была невиртуальная дискуссия с С++-ником переходящим на шарп. Он очень скептически относился к этому кейворду, я сразу вспомнил эти холивары с 2008 года.

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

L>>Увы, не дам. Если хочешь, можешь считать это признаком слива. Если действительно интересно, то воспользуйся гуглом.
WH>Ой напугал

Уж извини, если так получилось. Это не входило в мои планы.

L>>Клева. А я-то, дурак, не знал. Ниче, что вы в каждой первой статье о Немерле об этом пишете?

WH>Похоже, что нет.

Похоже что нет что? Что не клева? Или что я не знал? Или что не в каждой статье?

L>>Да, и какое отношение твой ответ имеет в вопросу концептуальной сложности добавления фич в язык?
WH>Это я не понимаю, какое отношение твой наезд на макросы имеет к добавлению фич в язык?
WH>Меж тем разница огромна. В случае с монолитным языком фича добаляется для всех и навсегда.
WH>В случае с макросами фичу используют только те, кому она нужна и только пока нужна.

Понимаешь, если я сейчас начну объяснять, то весь разговор опять сведется к тому, что вы будете себя бить в грудь и на весь форум кричать, что вы настолько умные, что всегда в состоянии предусмотреть все возможные варианты использования ваших расширений синтаксиса, а все, кто это сделать не в состоянии — недостойны гордого звания программиста и им нельзя давать в руки этот интсрумент и нужно довериться истинным гуру, а-ля WolfHound.
Между тем, пример того же шарпа показывает, что даже имея ограниченый набор фич, предусмотреть все крайне сложно, что явно демонстрируют многочисленные этюды nikov-а.
Далее разговор перейдет к обсуждению личности Хайсльберга и его ограниченных умственных способностей.

Поскольку я уже знаю сценарий развития нашей возможной беседы и осведомлен о ваших непробиваемых аргументах (мы — о-го-го, Хайзельберг — лох), то я пожалуй воздержусь от участия в оной.

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

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

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

Очередное доказательство того что читать ты не умеешь.

Я тебе говорю про то что применять мерки монолитных языков к языкам с макросами нельзя, а ты опять за свое...

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

WH>Правильное решение вообще выкинуть Null, а тем где нужно опциональное значение использовать тип Option[T] с двумя вариантами None и Some(T).

И что это даст, кроме синтаксического оверхеда? Вон в шарпе зачем-то сделали, что обращение к Nullable структуре идет через Value и что это дало, кроме синтаксического мусора?

Правильное решение это записывать Nullable типы как тип с вопросиком, но при этом обращение к нему должно идти обычным образом, без всяких мусорных None и Some.

WH>Причем чтобы достать оттуда значение нужно явно проверить, что там что-то есть.

Зачем для этого вводить кошмарный Option?

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

Some? value = GetSome();

if (value == null)
  return;

value.Func();

а такой нет:

Some? value = GetSome();

value.Func();

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

L>Я там привел пример — например, выражение, содержащие циклы.

С циклами в F# тоже всё в порядке. Всё в порядке, когда язык не позволяет отторгать инициализацию переменной от её объявления. Причём, невозможность такого отторжения не ограничивает программиста.

Q>>

Q>>mutable y =
Q>>  let sin_φ = sin(φ) in
Q>>  f(sin_φ)
Q>>... // Здесь уже sin_φ нет, что и требовалось.
Q>>

L>И почему такой подход не применим в моем случае? :???:

Потому что let-in — это жёсткая конструкция, ограничивающая от произвола. Ты же предлагаешь (насколько я понял) что-то вроде:

double const y = some_syntactic_sugar_for_constness
{
  statement1;
  statement2;
  statement3;
  return something;
}

И вот эти statement'ы могут делать что угодно, в частности, возвращать неинициализированную переменную. Ты просто скрыл недостижимую константность внутри. Снаружи всё константное, но внутри по прежнему программист может «вклиниться» в момент, где какая-то переменная уже создана, но ещё не инициализирована.

L>То, о чем мы ведем речь — это 2 независимых понятия: константность и проверка инициализированности. константность — это что переменную нельзя менять после инициазизации, "хитрая" инициализированность — это что переменная должна быть инициализирована до того, как к ней начали обращаться.

Примерно так.

Q>>Ок, и как он должен на это реагировать?

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

Тогда ты не можешь использовать эту переменную вне скоупа, загрязнённого «техническими» переменными типа sin_φ.

L>>>

L>>>const double y = ((Func<double>) (() => 
L>>>{
L>>>    double y;
L>>>    try
L>>>    {
L>>>        double const sin_φ = my_sin(φ);
L>>>        y = 0.5 * ::log((1.0 + sin_φ) / (1.0 - sin_φ));
L>>>    }
L>>>    catch (std::runtime_error const&)
L>>>    {
L>>>    }
L>>>    return y;
L>>>}))();
L>>>

L>>>Если ты видишь проблемы в первом варианте, то и во втором они тоже должны присутствовать. Можешь показать, как они будут выглядеть?

Q>>Точно так же будут выглядеть. Из лямбды вернётся неинициализированная (неконстантная, кстати) локальная переменная y.

L>Не понимаю. С какого перепуга она неинициализированная?

Просто вбей в редактор и проверь (именно так я и сделал). Только синтаксис C++0x-замыканий используй: «[=]() -> double { ...; return ...; }».

Q>>Это примерно то, что ты назвал «ужасным окончательным вариантом» из поста в начале ветки.

L>Именно потому, что этот вариант ужасен, я и предлагаю сахар.

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

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

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

U>И что это даст, кроме синтаксического оверхеда?
Статический контроль.

U>Вон в шарпе зачем-то сделали, что обращение к Nullable структуре идет через Value и что это дало, кроме синтаксического мусора?
Это вообще к делу не относится.. В шарпе вообще очень много странных решений.

U>Правильное решение это записывать Nullable типы как тип с вопросиком, но при этом обращение к нему должно идти обычным образом, без всяких мусорных None и Some.
Правильное решение вообще не тащить никаких Nullable в язык.

U>Зачем для этого вводить кошмарный Option?
Кошмарный он для тех кто его ни разу не использовал.
Вся прелесть Option в том что это просто еще один тип в стандартной библиотеке.
И для компилятора он не отличается от любого другого типа.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

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

Боюсь, вы сами того не ведая, написали пост в мою поддержку.

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

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

L>Даже такой простой выбор, как выбор между var и явной типизацией — весьма неоднозначен и приводит к долгим, продолжительным и безсмысленным спорам, не утихающим и до сих пор. Эти споры имеют место быть даже не смотря на то, что (я уверен) проектировшики языка сидели и целенаправленно рассматривали все плюсы и минусы этого решения.
Ага... споры есть, а вреда нет.
И те кто использовал понимают что вреда нет.
И даже те ко использовал намного более мощьный вывод типов говорят что вреда нет даже от него.
Но теоретики всеравно спорят и кричат что вред есть.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

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

WH>Очередное доказательство того что читать ты не умеешь.

Очередное доказательство того, что ты не в состоянии понять прочитанное.

WH>Я тебе говорю про то что применять мерки монолитных языков к языкам с макросами нельзя, а ты опять за свое...

Ты рассмотри конечного потребителя доработанного языка. Ему глубоко фиолетово, захардкожена фича в компилятор или реализована макросом. Тот факт, что те или иные фичи можно отключать, не имеет особого значения.
Я веду речь о том, что изменение синтаксиса — задача концептуально не тривиальная.
Во избежание недоразумений: речь идет не о том, что сложно взять и залезть в потроха компилятора и поправить ast, а о том, что далеко не так просто внести изменения в язык, чтобы при этом он со временем не превратился в кривого уродца.

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

Q>>Но теперь переменная y перестаёт быть константой, помимо объявлений/определений появляются присваивания. Усугубляется тем, что всё вышеизложенное касается не только переменной y, но и любой другой переменной в примере.»[/q]
L>Ну так это совсем другая проблема — невозможность объявить такую перепенную константной, хотя она очевидно таковой является.

final double y;
{
  final double sin_φ = sin(φ);
  y = 0.5 * log((1.0 + sin_φ) / (1.0 - sin_φ));
}

Всё работает, язык — Java.

Достаточно изменить немного семантику const-переменных. Они должны быть константными не с создания, а с первого присваивания.

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

L>>И почему такой подход не применим в моем случае?

Q>Потому что let-in — это жёсткая конструкция, ограничивающая от произвола. Ты же предлагаешь (насколько я понял) что-то вроде:
Q>

Q>double const y = some_syntactic_sugar_for_constness
Q>{
Q>  statement1;
Q>  statement2;
Q>  statement3;
Q>  return something;
Q>}
Q>

Q>И вот эти statement'ы могут делать что угодно, в частности, возвращать неинициализированную переменную.

Каким образом statement может что-то возвращать?

Q>Ты просто скрыл недостижимую константность внутри. Снаружи всё константное, но внутри по прежнему программист может «вклиниться» в момент, где какая-то переменная уже создана, но ещё не инициализирована.

Каким образом?

Q>>>Ок, и как он должен на это реагировать?

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

Q>Тогда ты не можешь использовать эту переменную вне скоупа, загрязнённого «техническими» переменными типа sin_φ.

По каким причинам я не могу этого сделать?

L>>Не понимаю. С какого перепуга она неинициализированная?

Q>Просто вбей в редактор и проверь (именно так я и сделал). Только синтаксис C++0x-замыканий используй: «[=]() -> double { ...; return ...; }».

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

Q>>>Это примерно то, что ты назвал «ужасным окончательным вариантом» из поста в начале ветки.

L>>Именно потому, что этот вариант ужасен, я и предлагаю сахар.

Q>Так в исходном комментарии я как раз этот сахар и запрашивал

Да, сахар может быть основанным на лямбдах, согласно приведённому определению из книжки Митчелла.

Предложенный let работает только в выражениях. Ты предлагаешт выбросить все императивные конструкции?

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

Ну уж нет, рано или позно ты вернешься.

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

L>Ты рассмотри конечного потребителя доработанного языка. Ему глубоко фиолетово, захардкожена фича в компилятор или реализована макросом.
Это мягко говоря не так.

L>Тот факт, что те или иные фичи можно отключать, не имеет особого значения.
Не отключать, а подключать. Разница существенная.

L>Я веду речь о том, что изменение синтаксиса — задача концептуально не тривиальная.
L>Во избежание недоразумений: речь идет не о том, что сложно взять и залезть в потроха компилятора и поправить ast, а о том, что далеко не так просто внести изменения в язык, чтобы при этом он со временем не превратился в кривого уродца.
Пятисотый раз повторяю: Твои слова справедливы для монолитов. Для макроязыков это не так.
Просто по тому что кривые фичи отомрут точно также как кривые библиотеки.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

L>>Даже такой простой выбор, как выбор между var и явной типизацией — весьма неоднозначен и приводит к долгим, продолжительным и безсмысленным спорам, не утихающим и до сих пор. Эти споры имеют место быть даже не смотря на то, что (я уверен) проектировшики языка сидели и целенаправленно рассматривали все плюсы и минусы этого решения.
WH>Ага... споры есть, а вреда нет.
WH>И те кто использовал понимают что вреда нет.
WH>И даже те ко использовал намного более мощьный вывод типов говорят что вреда нет даже от него.
WH>Но теоретики всеравно спорят и кричат что вред есть.

Ты ведь правда понимаешь, что ты тем самым меня только поддерживаешь?

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

C>Всё работает, язык — Java.

C>Достаточно изменить немного семантику const-переменных. Они должны быть константными не с создания, а с первого присваивания.

Надеюсь теперь Qbit86-таки согласится, что это возможно.

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

L>Ты ведь правда понимаешь, что ты тем самым меня только поддерживаешь?

Я понял только одно. Логика у тебя очень странно работает.
Это особенно весело на фоне того что ты выступаешь на стороне тех кто кричит не разобравшись.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

L>>Ты рассмотри конечного потребителя доработанного языка. Ему глубоко фиолетово, захардкожена фича в компилятор или реализована макросом.
WH>Это мягко говоря не так.

Аргументы?

L>>Тот факт, что те или иные фичи можно отключать, не имеет особого значения.
WH>Не отключать, а подключать. Разница существенная.

Нет никакой разницы.

L>>Я веду речь о том, что изменение синтаксиса — задача концептуально не тривиальная.
L>>Во избежание недоразумений: речь идет не о том, что сложно взять и залезть в потроха компилятора и поправить ast, а о том, что далеко не так просто внести изменения в язык, чтобы при этом он со временем не превратился в кривого уродца.
WH>Пятисотый раз повторяю: Твои слова справедливы для монолитов. Для макроязыков это не так.

Что именно для макроязыков не так? Для макроязыков так просто спроектировать фичу языка, что они хорошо ляжет на целевой язык? Благодаря чему?

WH>Просто по тому что кривые фичи отомрут точно также как кривые библиотеки.

Внимание, вопрос. Что делать с унаследованным кодом? А ну да, "настояшие" программисты от такого нос воротят.

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

WH>Правильное решение вообще не тащить никаких Nullable в язык.

В реальных задачах Nullable типы составляют очень весомую часть всех типов, соответственно отказ от их прямой поддержки в языке и замена этой поддержки на костыли означает горы синтаксического мусора в коде.

WH>Эта проверка только на первый взгляд кажется простой.
WH>Ты себе даже не представляешь насколько сильно придется надругаться на системой типов языка чтобы такое стало возможным.

Мы про систему типов шарпа или про проектирование языка с нуля?

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

L>>Ты ведь правда понимаешь, что ты тем самым меня только поддерживаешь?

WH>Я понял только одно. Логика у тебя очень странно работает.

Ты что-то не понял в том посте? Если да, то не стесняйся, спрашивай. Я постараюсь ответить.

WH>Это особенно весело на фоне того что ты выступаешь на стороне тех кто кричит не разобравшись.

В чем именно я не разобрался?

P.S. WolfHound, если просто хочешь написать, что у меня плохо с головой, ты не стесьняйся, пиши. Нам обоим будет польза: и мне не прилется расшифровывать что именно ты имел в виду под "кричит не разобравшись", и тебе не придется сдерживать себя. Чистый win-win. А админов не бойся, они свои, не обидят.

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

U>В реальных задачах Nullable типы составляют очень весомую часть всех типов, соответственно отказ от их прямой поддержки в языке и замена этой поддержки на костыли означает горы синтаксического мусора в коде.
Не в реальных задачах. А в твоем подходе к решения задач.
Почувствуй разницу.
Во многих языках null отсутствует и никто не страдает.

U>Мы про систему типов шарпа или про проектирование языка с нуля?
Один хрен там магия жуткая понадобится.
Причем на ровном месте. Просто по тому что тебе так захотелось.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

L>Аргументы?
Уже много раз написал.
Но ты проигнорировал.

L>Что именно для макроязыков не так? Для макроязыков так просто спроектировать фичу языка, что они хорошо ляжет на целевой язык? Благодаря чему?
Благодаря тому что этой задачи нет вообще.
Я тебе тут давно об этом говорю.
А ты все понять не можешь.
Если макра кривая она просто умрет и все.
Точно также как умирают кривые библиотеки.

L>Внимание, вопрос. Что делать с унаследованным кодом? А ну да, "настояшие" программисты от такого нос воротят.

Тоже что делают с унаследованным кодом, в котором используется мертвая и кривая библиотека.
Разницы нет никакой.
Совсем.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

А еще:
0) нельзя использовать русские буквы в именах переменных и функций
1) нельзя сделать operator[](int index1, int index2)
2) и вообще переопределенных операторов как-то мало
3) нельзя return x,y ;
4) нет безымянных функций и нельзя сделать вот так "функция( { тут какое-нибудь выражение } )"
5) нельзя поймать исключение SegFault и продолжить работу
6) В STL нет контейнера "граф"

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

A>0) нельзя использовать русские буквы в именах переменных и функций

int Проверка(int Переменная)
{
return Переменная + 1;
}

VC++ давно такое переваривает, последние gcc вроде тоже.

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

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

A>>0) нельзя использовать русские буквы в именах переменных и функций

FR>

FR>int Проверка(int Переменная)
FR>{
FR>return Переменная + 1;
FR>}
FR>

FR>VC++ давно такое переваривает, последние gcc вроде тоже.

VC++ переваривает, но это не по стандарту.
gcc жрать отказывается. Гад.

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

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

С>>C++ невозможно отличить создание временнoгo обьекта от вызова функции:

С>>int a = foo(B(x)); — что здесь B(x) ?

I>А это действительно важно? Конструктор ведь и есть функция создающая объект.

Да, но тут под капотом ещё и вызов деструктора. Кода весь код свой — можно жить, а когда чужой разбираешь?

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

Q>На C++ не писал очень давно, так что извините, если что.
Q>

Q>#include <cstdlib>
Q>#include <iostream>
Q>#include <stdexcept>

Q>#define _USE_MATH_DEFINES
Q>#include <math.h>

Q>namespace
Q>{
Q>    double my_sin(double φ)
Q>    {
Q>        if (::rand() % 2 == 1)
Q>            throw std::runtime_error("Some failure.");
Q>        else
Q>            return ::sin(φ);
Q>    }
Q>}

Q>int main(int argc, char const* argv[])
Q>{
Q>    double const latitude = 37.0;
Q>    double const radiansPerDegree = M_PI / 180.0;
Q>    double const φ = latitude * radiansPerDegree;
Q>    double y;
Q>    try
Q>    {
Q>        double const sin_φ = my_sin(φ);
Q>        y = 0.5 * ::log((1.0 + sin_φ) / (1.0 - sin_φ));
Q>    }
Q>    catch (std::runtime_error const&)
Q>    {
Q>    }
    
Q>    std::cout << y << std::endl;

Q>    return 0;
Q>}
Q>

Ну так инициализируй y перед использованием, особенно в таких случаях,

ну или так:

catch (std::runtime_error const&)
{
   y = some_fake_val;
}

ты же для чего-то ловишь исклучение.

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

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

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

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

Z>Интересно было наблюдать, как некоторые противники var, в следующем холиваре становятся его сторонниками (просто, за это время, они поели устриц). Буквально вчера была невиртуальная дискуссия с С++-ником переходящим на шарп. Он очень скептически относился к этому кейворду, я сразу вспомнил эти холивары с 2008 года.

У C++ — ников появилось auto — и он им нравится.

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

A>А еще:
A>0) нельзя использовать русские буквы в именах переменных и функций

А это зачем? сделать 1С из С++ ?

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

A>поменяйте уровень по умолчанию

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

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

С>Да, но тут под капотом ещё и вызов деструктора. Кода весь код свой — можно жить, а когда чужой разбираешь?

Вызов деструктора здесь есть назависимо от того, является ли B конструктором или функцией возвращающей объект.

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

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

A>>поменяйте уровень по умолчанию

I>Тогда компилятор начинает выдавать всякую ерунду.

Это не ерунда, а трудно вылавливаемые баги в будующем. У нас по умолчанию W4 и работаем без варнингов.

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

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

С>>Да, но тут под капотом ещё и вызов деструктора. Кода весь код свой — можно жить, а когда чужой разбираешь?

I>Вызов деструктора здесь есть назависимо от того, является ли B конструктором или функцией возвращающей объект.

Точно

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

I>Тогда компилятор начинает выдавать всякую ерунду.

значит ваш код плохой.

код должен нормально компилиться c /W4 — стандартная библиотка компилится с /W4, большинство либ буста тоже.
если либа не компилится с /W4, используйте #pragma warning,
если ваш код не компилится с /W4 — правьте ваш код.

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

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

A>>А еще:
A>>0) нельзя использовать русские буквы в именах переменных и функций

С>А это зачем? сделать 1С из С++ ?

Ложная связка. Java по твоему 1С?

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

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

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

A>>>А еще:
A>>>0) нельзя использовать русские буквы в именах переменных и функций

С>>А это зачем? сделать 1С из С++ ?

A>Ложная связка. Java по твоему 1С?

Разве кто-то этим пользуется?

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

L>Каким образом statement может что-то возвращать?

a return что, не statement?

Q>>Ты просто скрыл недостижимую константность внутри. Снаружи всё константное, но внутри по прежнему программист может «вклиниться» в момент, где какая-то переменная уже создана, но ещё не инициализирована.

L>Каким образом?

Да вот тем, который ты же показал:
L>

const double y = ((Func<double>) (() => 
{
    double y;
    try
    {
        double const sin_φ = my_sin(φ);
        y = 0.5 * ::log((1.0 + sin_φ) / (1.0 - sin_φ));
    }
    catch (std::runtime_error const&)
    {
    }
    return y;
}))();

Внутренняя «double y» у тебя не константа, и какое-то время пребывает в неинициализированном состоянии. Во, ещё один эксплоит придумал, даже без исключений. Предположим, у тебя рассчёт производится в сторонней библиотеке:

#include <iostream>

#define _USE_MATH_DEFINES
#include <math.h>

namespace third_party
{
    void compute(double sin_φ, double& y)
    {
        y = 0.5 * ::log((1.0 + sin_φ) / (1.0 - sin_φ));
    }
}

int main(int argc, char const* argv[])
{
    double const latitude = 37.0;
    double const radiansPerDegree = M_PI / 180.0;
    double const φ = latitude * radiansPerDegree;
    double const y = [=]() -> double
    {
        double y_local;
        double const sin_φ = ::sin(φ);
        third_party::compute(sin_φ, y_local);
        return y_local;
    }();
    std::cout << y << std::endl;    

    return 0;
}

И всё бы ничего, но в один прекрасный день разработчики сторонней библиотеки изменили код:

void compute(double sin_φ, double& y)
{
    if (0.0 < y) // Использование потенциально неинициализированной переменной.
        y = 0.5 * ::log((1.0 + sin_φ) / (1.0 - sin_φ));
}

И всё! Даже исключения об использовании неинициализированной переменной не будет! Компилятор в общем случае не в состоянии понять, что во внешней функции с переданной ссылкой творится.

Q>>Просто вбей в редактор и проверь (именно так я и сделал). Только синтаксис C++0x-замыканий используй: «[=]() -> double { ...; return ...; }».
L>Нет у меня редактора, я говорю о гипотетическом языке.

Я так понял, ты говоришь о гипотетическом языке, который будет расширять сахаром существующий язык (или аналог), заменяя существующий подход более простым синтаксически. Очевидно, C++ таким образом не расширишь. В него и лямбды-то со скрипом всунули, да и то получилось не ахти.

L>Предложенный let работает только в выражениях. Ты предлагаешт выбросить все императивные конструкции?

А что, было бы неплохо. И уже для имитации императивных конструкций добавлять сахар, который позволит вместо вложенной структуры байндингов использовать линейную последовательность «инструкций» с «присваиваниями»... Постойте-ка, где-то я это уже видел!

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

:)

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

C>>Достаточно изменить немного семантику const-переменных. Они должны быть константными не с создания, а с первого присваивания.
L>Надеюсь теперь Qbit86-таки согласится, что это возможно. :)

В Джаве — да :)

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

WH>>Причем чтобы достать оттуда значение нужно явно проверить, что там что-то есть.
U>Зачем для этого вводить кошмарный Option?

Это идиома, она везде есть, чем C# хуже? (Да, как минимум тем, что в нём с этим Option'ом паттерн-матчить не так удобно, как в нормальных языках.)
Option можно трактовать как коллекцию, состояющую из нуля или одного элемента. Преполезнейшая штука.
Про паттерн try-get в C# слышал? Так вот, он нахрен не нужен, если б сразу Option<T> использовали как, опять же, в библиотеках нормальных языков.

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

Q>Про паттерн try-get в C# слышал? Так вот, он нахрен не нужен, если б сразу Option<T> использовали как, опять же, в библиотеках нормальных языков.

Что такое паттерн try-get?

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

U>Что такое паттерн try-get?

Я название исказил. В «FDG» это называется Tester-Doer Pattern. Это когда к методу Parse, бросающему исключение, добавляют метод TryParse с мерзкими out-параметрами и возвращаемым bool'ом. Или когда в ассоциативном контейнере наряду с индексатором, бросающим исключение *NotFound есть метод TryGeValue с упомянутым out-параметром и возвращающим bool. Вот это костыли так костыли. Уж лучше из таких методов возвращать IEnumerable<Result>, всегда состоящий из нуля или одного элемента (если религия не позволяет идиоматичный Option<Result> использовать).

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

A>>0) нельзя использовать русские буквы в именах переменных и функций
С>А это зачем? сделать 1С из С++ ?

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

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

A>2) и вообще переопределенных операторов как-то мало

По-моему, их слишком много.

A>3) нельзя return x,y ;

Ну, кортежи в Бусте есть. Без деконструкции паттерн-матчингом, конечно, тяжело, но и там, вроде, были какие-то костыли вроде boost::tuples::tie(x, y).

A>4) нет безымянных функций и нельзя сделать вот так "функция( { тут какое-нибудь выражение } )"

В C++0x есть.

A>6) В STL нет контейнера "граф"

А чем бустовские графы не устраивают?

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

Q>А что, было бы неплохо. И уже для имитации императивных конструкций добавлять сахар, который позволит вместо вложенной структуры байндингов использовать линейную последовательность «инструкций» с «присваиваниями»... Постойте-ка, где-то я это уже видел!
В немерле?
Причем весь сахар макросами сделан.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

L>>Аргументы?
WH>Уже много раз написал.
WH>Но ты проигнорировал.

Нет, это не так. Фраза про "глубоко фиолетово" прозвучала 2 поста назад, много раз ты на нее ответить чисто физически не мог.

L>>Что именно для макроязыков не так? Для макроязыков так просто спроектировать фичу языка, что они хорошо ляжет на целевой язык? Благодаря чему?
WH>Благодаря тому что этой задачи нет вообще.
WH>Я тебе тут давно об этом говорю.
WH>А ты все понять не можешь.
WH>Если макра кривая она просто умрет и все.
WH>Точно также как умирают кривые библиотеки.

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

L>>Внимание, вопрос. Что делать с унаследованным кодом? А ну да, "настояшие" программисты от такого нос воротят.

WH>Тоже что делают с унаследованным кодом, в котором используется мертвая и кривая библиотека.
WH>Разницы нет никакой.
WH>Совсем.

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

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

Q>>А что, было бы неплохо. И уже для имитации императивных конструкций добавлять сахар, который позволит вместо вложенной структуры байндингов использовать линейную последовательность «инструкций» с «присваиваниями»... Постойте-ка, где-то я это уже видел!
WH>В немерле?

Не, я про do-нотацию для монад в Хаскеле.

Отсутствие двоичного стандарта.

Множество всяких "но", о которых начинаешь узнавать только после пары лет активной практики.

Отсутствие многопоточности как таковой.

Отсутствие частичной специализации шаблонных функций.

Зоопарк библиотек, из которых трудно выбрать ту самую единственную, которая на всю жизнь.

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

Очень большое время сборки (на известных мне компиляторах).

Наплодили меташаблоны с концептами, списками типов и кортежами, вместо того, чтобы вызвать
add_ref, поставить блокировку и вернуть shared_ptr.

Очень много платформенных "заточек" вроде #pragma, __declspec и #ifdef _X64.

Все начинающие плюсовики обречены на провал и переосмысление ценностей в районе
второго-третьего года практики. Не все проходят.

P.S. Написал бы еще, но C++ уж больно люблю.

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

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

L>>Каким образом statement может что-то возвращать?

Q>a return что, не statement?

Тут под "statement" я имел в виду statement-ы из твоего примера. Раз ты отдельно выделил return, я решил, что в других statement-ах return-ов нет.

Q>>>Ты просто скрыл недостижимую константность внутри. Снаружи всё константное, но внутри по прежнему программист может «вклиниться» в момент, где какая-то переменная уже создана, но ещё не инициализирована.

L>>Каким образом?

Q>Да вот тем, который ты же показал:
L>>
Q>

Q>const double y = ((Func<double>) (() => 
Q>{
Q>    double y;
Q>    try
Q>    {
Q>        double const sin_φ = my_sin(φ);
Q>        y = 0.5 * ::log((1.0 + sin_φ) / (1.0 - sin_φ));
Q>    }
Q>    catch (std::runtime_error const&)
Q>    {
Q>    }
Q>    return y;
Q>}))();
Q>

Q>Внутренняя «double y» у тебя не константа, и какое-то время пребывает в неинициализированном состоянии.

Этот код не должен скомпилироваться. Если он компилируется, это ошибка. Но в самой концепции ошибки нет.

Q>Во, ещё один эксплоит придумал, даже без исключений. Предположим, у тебя рассчёт производится в сторонней библиотеке:
Q>

Q>#include <iostream>

Q>#define _USE_MATH_DEFINES
Q>#include <math.h>

Q>namespace third_party
Q>{
Q>    void compute(double sin_φ, double& y)
Q>    {
Q>        y = 0.5 * ::log((1.0 + sin_φ) / (1.0 - sin_φ));
Q>    }
Q>}

Q>int main(int argc, char const* argv[])
Q>{
Q>    double const latitude = 37.0;
Q>    double const radiansPerDegree = M_PI / 180.0;
Q>    double const φ = latitude * radiansPerDegree;
Q>    double const y = [=]() -> double
Q>    {
Q>        double y_local;
Q>        double const sin_φ = ::sin(φ);
Q>        third_party::compute(sin_φ, y_local);
Q>        return y_local;
Q>    }();
Q>    std::cout << y << std::endl;    

Q>    return 0;
Q>}
Q>

Q>И всё бы ничего, но в один прекрасный день разработчики сторонней библиотеки изменили код:
Q>

Q>void compute(double sin_φ, double& y)
Q>{
Q>    if (0.0 < y) // Использование потенциально неинициализированной переменной.
Q>        y = 0.5 * ::log((1.0 + sin_φ) / (1.0 - sin_φ));
Q>}
Q>

Q>И всё! Даже исключения об использовании неинициализированной переменной не будет! Компилятор в общем случае не в состоянии понять, что во внешней функции с переданной ссылкой творится.

Тут мы отдаем контроль в руки программиста. По правильному — надо различать ref и out-параметры, как это сделано в том же шарпе.

Q>>>Просто вбей в редактор и проверь (именно так я и сделал). Только синтаксис C++0x-замыканий используй: «[=]() -> double { ...; return ...; }».
L>>Нет у меня редактора, я говорю о гипотетическом языке.

Q>Я так понял, ты говоришь о гипотетическом языке, который будет расширять сахаром существующий язык (или аналог), заменяя существующий подход более простым синтаксически. Очевидно, C++ таким образом не расширишь. В него и лямбды-то со скрипом всунули, да и то получилось не ахти.

Да я на C++ и не покушался.

L>>Предложенный let работает только в выражениях. Ты предлагаешт выбросить все императивные конструкции?

Q>А что, было бы неплохо. И уже для имитации императивных конструкций добавлять сахар, который позволит вместо вложенной структуры байндингов использовать линейную последовательность «инструкций» с «присваиваниями»... Постойте-ка, где-то я это уже видел!

Ох, не начинай.

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

1. Инструментарий: медленная компиляция в сочетании с глючной инкрементальной компиляцией и пока ещё убогими и сырыми IDE.
2. Отсутствие хорошей документации по некоторыми нетривиальным вещам (combinator parsers; actors — с механикой остановки актора не разобрался, времени не хватило).
3. Ограничение на максимальное количество полей (22) у case-классов; для классов данных с большим количеством полей приходится вручную писать все те же методы, что case-классы дают автоматом.
4. Как ни странно, отсутствие метапрограммирования (макросов как в Nemerle) — некоторые вещи напрашиваются на обобщение (entity-классы; в lib.web forms многовато рефлексии и т.п.).
5. Вывод типов мог бы быть куда мощнее. Ладно ещё обязательное указание типов для параметров функций — я типы указываю частенько даже там, где необязательно, чтобы логику свою контролировать. Но очень часто она требует типы в параметрах анонимных функций (в частности внутри generic-контекста), хотя запросто могла бы и сама вывести. Блин, точно надо на немерл переходить.

Позвольте представить: говно, просто говно. Я не могу придумать ничего, что бы мне в нём нравилось.

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

L>По правильному — надо различать ref и out-параметры, как это сделано в том же шарпе.

Всё верно. Оба патологических случая (ловля исключения до завершения инициализации и передача неинициализированной переменной в метод по ссылке), видимо, не удалось бы воспроизвести в СиШарпе или Джаве. Правда, может, есть другие контрпримеры — «отсутствие доказательства не означает доказательства отсутствия» :)

L>Но в самой концепции ошибки нет.

Всё равно math-like синтаксис «where» в Хаскель мне нравится больше, чем дурацкое разнесение объявления и определения переменной по разным углам. В нём иерархическая структура выражения чётче просматривается.

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

L>>Но в самой концепции ошибки нет.

Q>Всё равно math-like синтаксис «where» в Хаскель мне нравится больше, чем дурацкое разнесение объявления и определения переменной по разным углам. В нём иерархическая структура выражения чётче просматривается.

да я не против. вопрос лишь в том, как это ляжет на императивные блоки кода.

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

Q>Я название исказил. В «FDG» это называется Tester-Doer Pattern. Это когда к методу Parse, бросающему исключение, добавляют метод TryParse с мерзкими out-параметрами и возвращаемым bool'ом.

Дискуссия на эту тему уже была: http://rsdn.ru/forum/philosophy/3715263.1.aspx Out, конечно, не идеальное решение, но Option еще хуже.

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

U>Дискуссия на эту тему уже была: http://rsdn.ru/forum/philosophy/3715263.1.aspx

Ох, щи! Там 100500 комментариев, «tl;dr», извините.

U>Out, конечно, не идеальное решение, но Option еще хуже.

Это что; есть мнение, что стандартные итераторы вместо «MoveNext():bool»/«Current:T» надо было на опционах делать. Но если что, я этого не говорил. Десятистраничного холивара не осилю.

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

RO>

RO>def make_list(element, head=[]):
RO>    head.append(element)
RO>    return head

RO>print make_list(42)
RO>print make_list(42)
RO>

какая-то надуманная придирка.. об этом написано в оф.доках, и выглядит оно вполне логично..

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

O>Отсутствие многопоточности как таковой.

o_O

O>Зоопарк библиотек, из которых трудно выбрать ту самую единственную, которая на всю жизнь.

а где иначе?.

Отсутствие многопоточности.

1. Много синтаксических конструкций ради "галочки", одну вещь можно сделать разными способами.
2. Много завязок на java. Не хватает простых обёрток и библиотек (большой оверхед). Местами требуется, чтобы код был более java-подобный, т.е. приходится думать почти на 2х языках.
3. Дефолтная фича для конфигов является наполовину кодом, но не валидным, а потому неисполняема. Зато очень хорошо путает.
4. Крайне медленная работа.
5. Невнятный и неудобный рефлекшн.
6. Безумные стек-трейсы, которые могут в своём безумстве посоревноваться с эрланговскими.
7. В некоторых случаях не все ошибки расскажет (и это в рантайме!).

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

L>>Что именно для макроязыков не так? Для макроязыков так просто спроектировать фичу языка, что они хорошо ляжет на целевой язык? Благодаря чему?
WH>Благодаря тому что этой задачи нет вообще.
WH>Я тебе тут давно об этом говорю.
WH>А ты все понять не можешь.
WH>Если макра кривая она просто умрет и все.
WH>Точно также как умирают кривые библиотеки.

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

VE>>Т.е. долго и мучительно, по пути съедая мозг всем поддерживающим код программистам.
WH>Да. Но разницы с обычными библиотеками совершенно никакой.

Главное в это верить.

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

L>Главное в это верить.

В отличие от тебя я это знаю.
А у тебя только вера в какие-то страшные бедствия, которые никто из практиков не видел.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

L>>Главное в это верить.

WH>В отличие от тебя я это знаю.

И часто-часто повторять. И ни в коем случае не сомневаться.

WH>А у тебя только вера в какие-то страшные бедствия, которые никто из практиков не видел.

Практиков, говоришь? Я с год назад спрашивал про практику использования, кроме самого компилятора никто особо серьезного примера использования привести не смог. За год что-то изменилось или это и есть ваша "практика"?

Поскольку никто про жаву не пишет, придётся мне. Давно уже не юзал, но кое-что помнится.

1. Многабукаф. Нупростодоужасамногабукаф.

2. Не люблю, когда злоупотребляют аннотациями: они хуже проверяются типизатором. В жаве почти все фреймворки работают на аннотациях. Это вот отчаянное желание превратить всё на свете в POJO с аннотациями бесит. Взять тот же Spring MVC. Я хз чем плохо запихать обработчик каждого URL в отдельный класс-функтор (Page.service: Request -> Response), а свойства обработчика сделать дополнительными свойствами / виртуальными методами этого класса. (Не, правда, если кто пробовал и знает, чем плохо, очень прошу поделиться.) Нет, мы разрешим использовать POJO, обращать любой метод в обработчик запроса путём навешивания на него тонны аннотаций — на сам метод и на каждый параметр. Итого: типизация пролетает, как фанера над парижем; нетривиальную валидацию параметров, как и нетривиальную обработку ошибок, хрен прикрутишь; отладить эту AOP-хрень практически невозможно; IDE никаких подсказок не возможностям не даёт (базового класса нет, виртуальные методы подсмотреть негде, а аннотации я хз какие в каком случае применимы), приходится долго читать доки на каждую мелочь. Аналогичные претензии к Tapestry, а вот Wicket рулит.

3. После знакомства с ФП стало резко не хватать методов map(), filter() и т.п. на коллекциях. Плодить циклы на каждое элементарное функциональное преобразование — ну просто тоска смертная. Были какие-то Google collections, но у меня с зависимостями что-то не срослось. Разбираться забил, т.к. в этот период уже от жавы отошёл и не был особо заинтересован (иначе на крайняк сам бы классы-утилиты написал).

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

С>У C++ — ников появилось auto — и он им нравится.

Думаю мой С++-ник был просто незнаком с С++0х

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

F>и выглядит оно вполне логично..

можно посмотреть на эту логику?

Медленная компиляция обоих языков раздражает.

В Немерле не нравится низкая и сложно предсказуемая производительность. В С++ не нравится многословность. К счастью, они отлично совмещаются через C++/CLI.

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

L>>>Главное в это верить.

WH>>В отличие от тебя я это знаю.

L>И часто-часто повторять. И ни в коем случае не сомневаться.

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

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

WH>>А у тебя только вера в какие-то страшные бедствия, которые никто из практиков не видел.

L>Практиков, говоришь? Я с год назад спрашивал про практику использования, кроме самого компилятора никто особо серьезного примера использования привести не смог. За год что-то изменилось или это и есть ваша "практика"?

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

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

DR>В Немерле не нравится низкая и сложно предсказуемая производительность.

О, как? А можно с этого места по подробнее? Чем эта предсказуемость отличается скажем от C#?

Недостатки в компиляторе и языке:
1. Низкая скорость компиляции и как следствие периодическое подторможивание при комплите в IDE.
2. Сложность разработки не тривиальных макросов (требующих наличии информации о типах).
3. Недостаточная для некоторых задач расширяемость синтаксиса.
4. Компилятор основан на System.Reflection.Emit, что приводит к привязке исполняемых модулей к текущим версиям фрэймворка (FW). По сути из-за этого поддерживаются только FW 2-4 и Моно. Такие ответвления как КомпактFW и Сервилат не поддерживаются. Планируется перевод на CCI, что должно снять эту проблему.

Недостатки в IDE:
1. Макросы уровня выражения под управлением IDE ведут себя не так же как при компиляции. Неумелый макро-писатель может создать макрос неустойчиво работающий в IDE, но работающий в компиляторе. Виной сему императивный подход в работе с деревом типов.
2. Малый набор рефакторингов, точнее наличие всего двух их видов. Не помешали бы многие фичи РеШарпера. Особенно выделение метода (а еще лучше перевод локальной функции в метод), выделение интерфейса и т.п.

Надеюсь, что все эти недостатки будут устранены в Nemerle 2.0. Ну, а некоторые и раньше.

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

L>>>>Главное в это верить.

WH>>>В отличие от тебя я это знаю.

L>>И часто-часто повторять. И ни в коем случае не сомневаться.

VD>Ты часто раздражаешь меня своей манерой алогичного мышления.

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

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

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

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

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

Дабы не искать, отквочу:

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

Хотя я уже знаю ответ. Вы просто опять съедете на то, что нет такой проблемы.
Собственно, как было с ненужностью "отладки" макросов, когда ты на публике с пеной у рта уверял, что средств получения кода, сгенерированного макросом нет за ненадобностью, а в личной переписке, надев маску "ты кого угодно достанешь", признал, что средства-таки есть.

WH>>>А у тебя только вера в какие-то страшные бедствия, которые никто из практиков не видел.

L>>Практиков, говоришь? Я с год назад спрашивал про практику использования, кроме самого компилятора никто особо серьезного примера использования привести не смог. За год что-то изменилось или это и есть ваша "практика"?

VD>Случаев использования полно.

Опять как и год назад сошлешься на компилятор?

VD>Но ты от вопроса то не уходит.

А это и не уход от вопроса. Собеседник в качестве аргумента сослался на практику, вот пусть и уточнит, что за практику он имеет в виду.

VD>А то у тебя и так логиках хромает как у блондинки. Сосредоточься на одной проблеме. Так будет проще не ошибиться.

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

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

Q>>Всё равно math-like синтаксис «where» в Хаскель мне нравится больше, чем дурацкое разнесение объявления и определения переменной по разным углам. В нём иерархическая структура выражения чётче просматривается.

L>да я не против. вопрос лишь в том, как это ляжет на императивные блоки кода.

В языках ML семейства (которые вполне и императивные) нормально ложится.

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

VD>О, как? А можно с этого места по подробнее? Чем эта предсказуемость отличается скажем от C#?

.NET вообще плохая платформа для вычислений, но в Немерле производительность сильно зависит ещё и от того, инлайнятся ли функции, оптимизируется ли хвостовая рекурсия, во что разворачивается использование туплов, и какой код генерируется макросами (особенно foreach). Чисто личный опыт.

On 23.04.2011 1:22, Философ wrote:

Что вам не нравится в языке, на котором вы пишете

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

Posted via RSDN NNTP Server 2.1 beta

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

D>2. Не люблю, когда злоупотребляют аннотациями: они хуже проверяются типизатором. В жаве почти все фреймворки работают на аннотациях. Это вот отчаянное желание превратить всё на свете в POJO с аннотациями бесит. Взять тот же Spring MVC. Я хз чем плохо запихать обработчик каждого URL в отдельный класс-функтор (Page.service: Request -> Response), а свойства обработчика сделать дополнительными свойствами / виртуальными методами этого класса. (Не, правда, если кто пробовал и знает, чем плохо, очень прошу поделиться.) Нет, мы разрешим использовать POJO, обращать любой метод в обработчик запроса путём навешивания на него тонны аннотаций — на сам метод и на каждый параметр. Итого: типизация пролетает, как фанера над парижем; нетривиальную валидацию параметров, как и нетривиальную обработку ошибок, хрен прикрутишь; отладить эту AOP-хрень практически невозможно; IDE никаких подсказок не возможностям не даёт (базового класса нет, виртуальные методы подсмотреть негде, а аннотации я хз какие в каком случае применимы), приходится долго читать доки на каждую мелочь. Аналогичные претензии к Tapestry, а вот Wicket рулит.

А покажи неривиальную валидаци, не вписывающуюся в JSR-303?

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

A>А еще:
A>0) нельзя использовать русские буквы в именах переменных и функций
Можно любые, вот цитата из стандарта (старого):

identifier:
  nondigit
  identifier nondigit
  identifier digit

nondigit: one of
  universal-character-name
  _ a b c d e f g h i j k l m
  n o p q r s t u v w x y z
  A B C D E F G H I J K L M
  N O P Q R S T U V W X Y Z

hex-quad:
  hexadecimal-digit hexadecimal-digit hexadecimal-digit hexadecimal-digit

universal-character-name:
  \u hex-quad
  \U hex-quad hex-quad

так что все вопросы к конкретному редактору — по старому стандарту он обязан просто превращать юникодные символы в \uXXXX в момент сохранения файла на диск (и обратно при загрузке).
Кстати, если вызов компилятора завернуть в элементарный скрипт, который любые уникодные символы будет превращать в universal-character-name и потом звать компилятор — вообще никаких усилий от редактора не потребуется.
В новом стандарте еще проще:

identifier-nondigit:
  nondigit
  universal-character-name
  other implementation-defined characters

но universal-character-name никуда не делся, так что скрипт будет работать и с кодом, соответствующим новому стандарту.

A>1) нельзя сделать operator[](int index1, int index2)
это да, арность, приоритеты и прочая менять нельзя. Это, кстати, дает стабильность синтаксиса, в отличие от языков, в которых это можно. Потому что сейчас a[1,2] эквивалентно a[2], потому что оператор запятая. И это не зависит от типа а. А если разрешить такое, как у тебя, то в зависимости от типа а может быть как оператор запятая + вызов унарной версии, так и вызов бинарной версии.

A>2) и вообще переопределенных операторов как-то мало
В сымсле — мало? 46 операторов (все, кроме четырёх ". .* :: ?:") — это мало? Или ты к тому, что нельзя новых наопределять? Так это палка о двух концах, так как, определяя новый оператор, его нужно каким-то образом включить в систему существующих операторов в смысле приоритета и ассоциативности — немаленькая нагрузка на компилятор, не говоря уже о возникающих неоднозначностях: a**b — это новый оператор ** или a*(*b), как сейчас? Но лучше, конечно, 5 звёздочек

A>3) нельзя return x,y ;

return boost::make_tuple(x,y);

A>4) нет безымянных функций и нельзя сделать вот так "функция( { тут какое-нибудь выражение } )"
можно в C++0x (VC и GCC уже поддерживают)

A>5) нельзя поймать исключение SegFault и продолжить работу
оно за пределами языка, так что надо пользоваться внеязыковыми средствами, доступными в библиотеках.

A>6) В STL нет контейнера "граф"
А так же Map/Reduce, youtube video search, переводчика с японского на корейский и еще миллиона структур и алгоритмов. Библиотеки на что? Boost.Graph, например.

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

O>Отсутствие двоичного стандарта.
Посмотрел бы я на этот стандарт, который бы удовлетворил и 64-битовым билдам, и 8-битным микроконтроллерам

O>Зоопарк библиотек, из которых трудно выбрать ту самую единственную, которая на всю жизнь.
Ну вот была MFC "на всю жизнь" — и как?

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

O>Наплодили меташаблоны с концептами, списками типов и кортежами, вместо того, чтобы вызвать
O>add_ref, поставить блокировку и вернуть shared_ptr.
не понял, какая связь?

O>Очень много платформенных "заточек" вроде #pragma, __declspec и #ifdef _X64.
Вообще-то возможность заточки под платформу — это фича языка

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

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

O>>Отсутствие двоичного стандарта.
J>Посмотрел бы я на этот стандарт, который бы удовлетворил и 64-битовым билдам, и 8-битным микроконтроллерам

O>>Зоопарк библиотек, из которых трудно выбрать ту самую единственную, которая на всю жизнь.
J>Ну вот была MFC "на всю жизнь" — и как?

O>>Отсутствие единого глобального соглашения о скобках, отступах и именах.
J>Это должно быть частью языка? Типа не правильный отступ или скобка не на той строчке — и код не должен компилироваться?

В качестве примеров "из другой песочницы" — Code Conventions for the Java Programming Language и Style Guide for Python Code.

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

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

VD>>О, как? А можно с этого места по подробнее? Чем эта предсказуемость отличается скажем от C#?

DR>.NET вообще плохая платформа для вычислений, но в Немерле производительность сильно зависит ещё и от того, инлайнятся ли функции, оптимизируется ли хвостовая рекурсия, во что разворачивается использование туплов, и какой код генерируется макросами (особенно foreach). Чисто личный опыт.

а на N хвостовая рекурсия может не разворачиваться в цикл???

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

O>>Отсутствие двоичного стандарта.
J>Посмотрел бы я на этот стандарт, который бы удовлетворил и 64-битовым билдам, и 8-битным микроконтроллерам

А мне бы хватило стандарта для одной определенной платформы (Windows) — схема расширения имен,
объектные файлы, передача объектов/исключений между модулями и тому подобное.
Чтобы можно было гарантировать совместимость интерфейсов C++ между теми же dll, собранными
разными компиляторами. Может быть, в таких громадинах как COM тогда и не было бы необходимости.

O>>Зоопарк библиотек, из которых трудно выбрать ту самую единственную, которая на всю жизнь.
J>Ну вот была MFC "на всю жизнь" — и как?

Вот и я о том же — MFC даже не является частью языка, подобно STL.
А если сесть и перечислить все либы, с которыми приходилось работать, получится весьма немалый список.
Причем каждая из них реализует какую-то особую концепцию, каждую нужно понять и осилить, хотя бы
на уровне прототипов. Куда эта дорога ведет ? Почему в новом стандарте нет либы для работы с XML,
ведь он используется повсеместно ?

O>>Отсутствие единого глобального соглашения о скобках, отступах и именах.
J>Это должно быть частью языка? Типа не правильный отступ или скобка не на той строчке — и код не должен компилироваться?

Ну да, это как-то маниакально.
Но почему-то в том же .NET принято именовать сущности более-менее единообразно (видел в нескольких
проектах), а в коде на C++ постоянно приходится видеть нечто в таком стиле:

BOOL _stdcall AcquireCompletionToken(thread_handle &Handle)
{
    if (Handle.get_owner_thread != PERF_THREAD_ID(S_ResourcePool->GetThisThread()))
    {
        return FALSE;
    }

    return (PERF_THREAD_ACQTOKEN(Handle.get_storage()));
}

Не правда ли, все это гораздо приятнее читалось бы так:
(На мой вкус. Кому-то не понравится, но по крайней мере выполнено в едином стиле).

bool acquire_completion_token(thread_handle &handle)
{
    if (handle.get_owner_thread != perf_thread_id(s_resource_pool->get_this_thread()))
    {
        return false;
    }

    return (perf_thread_acqtoken(handle.get_storage()));
}

O>>Наплодили меташаблоны с концептами, списками типов и кортежами, вместо того, чтобы вызвать
O>>add_ref, поставить блокировку и вернуть shared_ptr.
J>не понял, какая связь?

Я к тому, что некоторые существующие концепции программирования в C++ эволюционировали в нечто
настолько сложное и запредельное для понимания обычными людьми, что сильно потеряли, на мой взгляд,
в практическом отношении. Особенно в коллективной разработке, когда квалификация программистов
может значительно отличаться. Мне нравится, когда шаблоны используются как в STL или бустовских
смартпоинтерах, или как обертки для COM-интерфейсов в ATL, но когда из них делают что-то,
понятное лишь гуру метапрограммирования — это перебор.

O>>Очень много платформенных "заточек" вроде #pragma, __declspec и #ifdef _X64.
J>Вообще-то возможность заточки под платформу — это фича языка

Если заточек становится слишком много, значит язык не справляется со своей задачей.

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

F>>и выглядит оно вполне логично..
Z>

можно посмотреть на эту логику?

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

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

O>>>Отсутствие единого глобального соглашения о скобках, отступах и именах.
J>>Это должно быть частью языка? Типа не правильный отступ или скобка не на той строчке — и код не должен компилироваться?

К>В качестве примеров "из другой песочницы" — Code Conventions for the Java Programming Language и Style Guide for Python Code.

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

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

F>Здравствуйте, Курилка, Вы писали:

O>>>>Отсутствие единого глобального соглашения о скобках, отступах и именах.
J>>>Это должно быть частью языка? Типа не правильный отступ или скобка не на той строчке — и код не должен компилироваться?

К>>В качестве примеров "из другой песочницы" — Code Conventions for the Java Programming Language и Style Guide for Python Code.

F>для плюсов тоже есть различные соглашения, но все забивают..
Различные != рекомендуемые
F>и для жавы забивают, и на пеп8 кладут бывает.. особенно брутальны бывают споры при переносе кода на несколько строк..
Ну на любом языке можно писать ужасный код, и что?
Вопрос-то в первую очередь организационный, а в случае жабы/питона есть чуть большая вероятность решения этого вопроса ну и чуть меньше визуального мусора при работе с чужим кодом (типа приведённого okman рядом).

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

J>а на N хвостовая рекурсия может не разворачиваться в цикл???

Насколько я знаю, хвостовая рекурсия разворачивается всегда. Для меня проблема только в том, что отсутствие хвостовой рекурсии не всегда очевидно. О нём узнаёшь из профайлера или при падении со StackOverflowException.

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

O>Здравствуйте, jazzer.
O>Вы как-то очень уж серъезно решили "не обойти стороной" мое сообщение.
А почему я должен к вашим сообщениям относиться несерьезно?

O>В любом языке, как и в человеке, можно найти кучу недостатков, и при этом спокойно с ним жить.
С этим никто не спорит.

O>>>Отсутствие двоичного стандарта.
J>>Посмотрел бы я на этот стандарт, который бы удовлетворил и 64-битовым билдам, и 8-битным микроконтроллерам

O>А мне бы хватило стандарта для одной определенной платформы (Windows) — схема расширения имен,
O>объектные файлы, передача объектов/исключений между модулями и тому подобное.
O>Чтобы можно было гарантировать совместимость интерфейсов C++ между теми же dll, собранными
O>разными компиляторами. Может быть, в таких громадинах как COM тогда и не было бы необходимости.
Ну, вам бы на Windows хватило, а что насчет всех остальных? Речь же о языке. Никто не мешает компиляторостроителям договориться, как реализовать совместимость в рамках конкретной платформы. Было бы желание. А вот его, как показывают заседания комитета, как рих и нет. С другой стороны, есть же усилия на ABI типа Itanium, DWARF и т.д. — может, оно понемножку и выстаканится. Но это в любом случае не проблема языка, именно из-за его огромной кроссплатформенности.

O>>>Зоопарк библиотек, из которых трудно выбрать ту самую единственную, которая на всю жизнь.
J>>Ну вот была MFC "на всю жизнь" — и как?

O>Вот и я о том же — MFC даже не является частью языка, подобно STL.
А была бы — было бы хорошо? А что делать нам на Motif, маководам на Cocoa и прочим на gnome/KDE/whatever?
Там архитектура и подходы в принципе разные, не просто названия классов-методов.
В винде — сообщения и одна оконная функция.
В иксах — индивидуальный колбэк на каждое сообщение, с контекстной информацией.

O>А если сесть и перечислить все либы, с которыми приходилось работать, получится весьма немалый список.
O>Причем каждая из них реализует какую-то особую концепцию, каждую нужно понять и осилить, хотя бы
O>на уровне прототипов. Куда эта дорога ведет ? Почему в новом стандарте нет либы для работы с XML,
O>ведь он используется повсеместно ?
Потому что XML огромен сам по себе, плюс он же не в вакууме, с ним вместе должны идти XSLT, XPath, схемы и прочая. А если мы хотим все это сделать частью языка — создание и поддержка всего этого дела ложится на производителей компиляторов.

O>Но почему-то в том же .NET принято именовать сущности более-менее единообразно (видел в нескольких
O>проектах), а в коде на C++ постоянно приходится видеть нечто в таком стиле:
Наверное, потому что развивалось все очень быстро быстро, все книжки писались в деином стиле и на базе огромной библиотеки сформировалась некая "экосистема". Такое под силу только корпорациям за деньги. В остальном же — вот был Си и С++: в обеих основополагающих книжках используется нотация с подчеркиваниями и маленькими буквами. С какого бодуна та же MFC написана мелкософтом с верблюжьей нотацией? Для единообразия с WinAPI? А там почему так? Чтоб символы в объектниках были покороче? В общем, большие игроки, которые и должны задавать тон, действуют вразнобой. В случае же C#/Java большой игрок ровно один, а остальные просто принимают правила игры.

O>(На мой вкус. Кому-то не понравится, но по крайней мере выполнено в едином стиле).
Кто ж спорит. Ну вот в бусте приняты правила именования, например, там все единообразно.

O>>>Наплодили меташаблоны с концептами, списками типов и кортежами, вместо того, чтобы вызвать
O>>>add_ref, поставить блокировку и вернуть shared_ptr.
J>>не понял, какая связь?

O>Я к тому, что некоторые существующие концепции программирования в C++ эволюционировали в нечто
O>настолько сложное и запредельное для понимания обычными людьми, что сильно потеряли, на мой взгляд,
O>в практическом отношении. Особенно в коллективной разработке, когда квалификация программистов
O>может значительно отличаться. Мне нравится, когда шаблоны используются как в STL или бустовских
O>смартпоинтерах, или как обертки для COM-интерфейсов в ATL, но когда из них делают что-то,
O>понятное лишь гуру метапрограммирования — это перебор.
Все гуру-фичи нужны только разработчикам библиотек, по большому счету. Для нормальных прикладников все остается на простом уровне либо становится еще проще, типа того же цикла foreach, универсального синтаксиса инициализации, auto для автоматического выведения типа... Это все облегчает жизнь именно "простым" программистам.

O>>>Очень много платформенных "заточек" вроде #pragma, __declspec и #ifdef _X64.
J>>Вообще-то возможность заточки под платформу — это фича языка

O>Если заточек становится слишком много, значит язык не справляется со своей задачей.
Очень расплывчатый критерий, имхо. Что значит "слишком много"? Сколько их должно быть, учитывая огромное количество существующих архитектур? Более того, как без declspec ты сможешь обеспечить сопряжение своей программы с несколькими сишными, паскалевскими и фортрановскими библиотеками одновременно?

К>В качестве примеров "из другой песочницы" — Code Conventions for the Java Programming Language и Style Guide for Python Code.

Я тебе и на Си с десяток таких насобираю.

Это часть языка? Нет.
Код, не соответствующий этим соглашениям в "других песочницах", отвергается компиляторами? Нет.

Вот в хаскеле это часть языка — типы всегда с большой буквы. А то, что ты показываешь — это просто рекомендации, их в любом языке навалом. Что их делает выделенными? То, что их написали создатели языков? Ну так на Си и С++ есть книжки от создателей языков (написанные в практически одинаковом стиле, кстати) — кто мешал пользоваться их стандартами? В юниксовом мире в основном и пользуются, кстати, хотя графика что в X Window, что в WinAPI, написала в совершенно других соглашениях. Почему? Зачем нарушили сложившийся стиль стандартных сишной и плюсовой библиотек и книг? Кто знает. Может, экономили таблицу символов в объектниках

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

F>Отсутствие многопоточности.

import threading

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

F>>Отсутствие многопоточности.
A>

A>import threading
A>

отличная шутка ©

это недомногопоточность из-за того, что существует GIL..
в свежих релизах (не помню какой версии) напридумывали разных извратов для некоторого ускорения, но всё равно уныло.. поможет только:

import multiprocessing

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

L>Я привел пример с выбором между var и явной декларацией типа.

OK, давай разберем этот пример.

Итак на входе мы имеем язык в котором определение неизменяемой переменной имеет синтаксис (упрощенно):

def varName = expression;

а изменяемой

mutable varName = expression;

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

Теперь кто-то захотел использовать в своих программах синтаксис:

var varName = expression;

как замену синтаксиса с mutable.

Он создает макрос:

macro Var(expr1, expr2)
  syntax("var", expr1, "=", expr2)
{
  <[ mutable $expr1 = $expr2;
}

И спокойно пользуется новым синтаксисом в программе.

Может ли он как-то перенести свой новый синтаксис в основной язык? Очевидно — нет.
Что же он может сделать? Он может предложить свое решение разработчикам языка. Для этого достаточно создать сообщение на одном из форумов которые они читают и приложить к сообщению свой чудо-макрос вводящий этот синтаксис.

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

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

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

L>Хотя я уже знаю ответ. Вы просто опять съедете на то, что нет такой проблемы.

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

При этом ты выдаешь дичайшие алогизмы которые раздражают окружающих.

L>Собственно, как было с ненужностью "отладки" макросов, когда ты на публике с пеной у рта уверял, что средств получения кода, сгенерированного макросом нет за ненадобностью, а в личной переписке, надев маску "ты кого угодно достанешь", признал, что средства-таки есть.

Это уже какой-то совсем другой вопрос... видимо. Я не знаю что ты вкладываешь в понятие "отладки" (в кавычках). Средства отладки макросов несомненно есть и я никогда не говорил об их ненужности (особенно с пеной у рта). Так что ты просто в очередной раз лжешь.

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

VD>>Случаев использования полно.

L>Опять как и год назад сошлешься на компилятор?

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

VD>>Но ты от вопроса то не уходит.

L>А это и не уход от вопроса. Собеседник в качестве аргумента сослался на практику, вот пусть и уточнит, что за практику он имеет в виду.

Собеседник тебе русским языком четко и доходчиво объяснил прицип того почему не возникает проблем. Ты же начал молоть чепуху на что он тебе и сказал, что это домыслы которые на практике не существуют. В принципе он мог и не говорить про практику, так как твои слова являются домыслами, а стало быть опровергать их не имеет смысла.

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

VD>>А то у тебя и так логиках хромает как у блондинки. Сосредоточься на одной проблеме. Так будет проще не ошибиться.

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

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

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

F>в свежих релизах
в 3.2

нормально всё работает. для скриптового языка.
хотите быстроты — пишите на C++\C#

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

A>нормально всё работает. для скриптового языка.
A>хотите быстроты — пишите на C++\C#

а не было разговора за быстроту, был разговор за многопоточность, которой фактически нету..
есть GIL => нет многопоточности..

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

F>есть GIL => нет многопоточности..

никакой связи.
всё прекрасно работает в разных потоках

6. Рефлексия. Сейчас своей у скалы нет, используется жавовская. Не умеет как минимум одну очень важную вещь: вызывать методы (включая конструкторы), задавая значения параметров по имени параметра (не позиционно "p1: Any, p2: Any", а "Map(pName: String, pValue: Any)"). Из-за этого тот же squeryl при материализации создаёт экземпляр entity-класса (реализованного как immutable case class) с помощью дефолтного конструктора (каковой требуется объявлять во всех entity-классах), а после инжектит значения полей. Из-за этого невозможно сделать такую полезную вещь, как проверку инвариантов в теле класса (т.е. в теле основного конструктора).

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

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

F>>>Отсутствие многопоточности.
A>>

A>>import threading
A>>

F>отличная шутка ©

F>это недомногопоточность из-за того, что существует GIL..

import numpy, threading
class Worker(threading.Thread):
    def __init__(self, ws):
        self.ws = ws
        threading.Thread.__init__(self)
    def run(self):
        while True:
            numpy.sin(self.ws)

workers = []
data = numpy.arange(0, 1500, 0.0001)
for x in range(8):
    workers.append(Worker(data))
    workers[-1].start()

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

К>А покажи неривиальную валидаци, не вписывающуюся в JSR-303?

А в Spring MVC можно к параметру контроллера страницы (т.е. к GET-параметру HTTP-запроса) прикрутить этот самый JSR303-валидатор, и спринг его зацепит? Если да, тогда данная претензия снимается.

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

J>А почему я должен к вашим сообщениям относиться несерьезно?

Это был мой ответ на вопрос что мне не нравится в языке.
Мне показалось, что Вы пытаетесь меня в чем-то разубедить. Нет ?
В общем-то, я соглашусь почти со всем, что Вы написали, но ведь
проблемы от этого не исчезнут.

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

K> def run(self):
K> while True:
K> numpy.sin(self.ws)
Ага. И вот тут оно в нативной функции и считает параллельно. Заменим на простой while True: pass и получим один процессор.

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

F>>>и выглядит оно вполне логично..
Z>>

можно посмотреть на эту логику?

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

Это причина, а не логика. Логика подсказывает, что следующие вызовы должны быть эквивалентны, но это не так:

make_list(42)
make_list(42, [])

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

DR>.NET вообще плохая платформа для вычислений, но в Немерле производительность сильно зависит ещё и от того, инлайнятся ли функции, оптимизируется ли хвостовая рекурсия, во что разворачивается использование туплов, и какой код генерируется макросами (особенно foreach). Чисто личный опыт.

Это в любом языке есть. Более того, если есть более одного компилятора, то у каждого могут быть свои особенности.

Я не понимаю где здесь именно непредсказуемость?

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

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

J>>А почему я должен к вашим сообщениям относиться несерьезно?

O>Это был мой ответ на вопрос что мне не нравится в языке.
O>Мне показалось, что Вы пытаетесь меня в чем-то разубедить. Нет ?
O>В общем-то, я соглашусь почти со всем, что Вы написали, но ведь
O>проблемы от этого не исчезнут.
Если вы согласны почти со всем, то это значит, что вы согласны, что почти все претензии не относятся к собственно языку.
Проблемы от этого не изчезнут, это да, но это проблемы не языка.

Я ведь не на всё возражал, что вы указали, а только на то, что к языку не относится.
Это значит, что всё остальное упомянутое я признаю за проблемы самого языка, типа отсутствия частичных специализаций функций и прочего.

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

F>>есть GIL => нет многопоточности..
A>никакой связи.

ты понимаешь вообще зачем нужен GIL?.
он нужен, чтобы данные объектов (__dict__) не разрушались при доступе из разных потоков.. поэтому и нужен глобальный лок..

A>всё прекрасно работает в разных потоках

это псевдопотоки.. потоки в одном системном потоке..
это быстрее, чем всё делать только на процессах, но медленнее, если бы были нормальные потоки..

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

L>>Я привел пример с выбором между var и явной декларацией типа.

VD>OK, давай разберем этот пример.

VD>Итак на входе мы имеем язык в котором определение неизменяемой переменной имеет синтаксис (упрощенно):
VD>

VD>def varName = expression;
VD>

VD>а изменяемой
VD>

VD>mutable varName = expression;
VD>

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

VD>Теперь кто-то захотел использовать в своих программах синтаксис:
VD>

VD>var varName = expression;
VD>

VD>как замену синтаксиса с mutable.

VD>Он создает макрос:
VD>

VD>macro Var(expr1, expr2)
VD>  syntax("var", expr1, "=", expr2)
VD>{
VD>  <[ mutable $expr1 = $expr2;
VD>}
VD>

VD>И спокойно пользуется новым синтаксисом в программе.

VD>Может ли он как-то перенести свой новый синтаксис в основной язык? Очевидно — нет.
VD>Что же он может сделать? Он может предложить свое решение разработчикам языка. Для этого достаточно создать сообщение на одном из форумов которые они читают и приложить к сообщению свой чудо-макрос вводящий этот синтаксис.

VD>Разработчики выслушают товарища предлагающего расширение и обдумают нужно ли такое расширение вообще и если нужно, то стоит ли поместить его в стандартную библиотеку макросов, или в отдельную библиотеку (чтобы им могли пользоваться те кто захочет, но чтобы он не был доступен по умолчанию).

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

VD>В итоге данный макрос не попадет в стандартную библиотеку, но пользователь сможет использовать свой макрос и передавать его другим людям которые выразят желание его использовать. Все что нужно для того чтобы использовать в проекте этот макрос — это приложить к проекту соответствующую ДЛЛ. Если его проекты попадут в чужие руки, они будут прекрасно работать, так как ДЛЛ будет в их составе.

К чему все это? Я тебе специально вопрос выделил жирным. Выбор var/декларация типа — исключительно иллюстрация того, что изменение синтаксиса — не такая тривиальная задача. Дабы тема опять не съехала в сторону, повторюсь, что речь не о технической стороне дела, а о концептуальной.

L>>Хотя я уже знаю ответ. Вы просто опять съедете на то, что нет такой проблемы.

VD>Ну, дак это потому что так оно и есть. Ты выдумал себе проблемы и теперь пытаешься доблестно с ними сражаться.

Я вижу проблему в приведенном примере, я вижу на примерах nikov-а, что и в шарпе полно нелогичностей и неоднозначностей. Какие еще мне могуть понадобиться подтверждения того, что проблема реальна?

VD>При этом ты выдаешь дичайшие алогизмы которые раздражают окружающих.

Алогичность — это обвинять оппонента в алогичности, не приводя пример того, где именно была запечена алогичность.

L>>Собственно, как было с ненужностью "отладки" макросов, когда ты на публике с пеной у рта уверял, что средств получения кода, сгенерированного макросом нет за ненадобностью, а в личной переписке, надев маску "ты кого угодно достанешь", признал, что средства-таки есть.

VD>Это уже какой-то совсем другой вопрос... видимо. Я не знаю что ты вкладываешь в понятие "отладки" (в кавычках). Средства отладки макросов несомненно есть и я никогда не говорил об их ненужности (особенно с пеной у рта). Так что ты просто в очередной раз лжешь.

Доказательства моей "лжи" ты можешь увидеть в истории переписки в скайпе. К сожалению, я не могу ее процитировать, т.к. недавно переставлял систему.

VD>Ну, да попытка подменить тему уже сама по себе свидетельствует о сливе и попытке перевести разговор в демагогическую форму. Если эта попытка неосознанная, предлагаю ее остановить.

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

VD>>>Случаев использования полно.

L>>Опять как и год назад сошлешься на компилятор?

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

Спасибо.

VD>>>Но ты от вопроса то не уходит.

L>>А это и не уход от вопроса. Собеседник в качестве аргумента сослался на практику, вот пусть и уточнит, что за практику он имеет в виду.

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

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

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

Я бы назвал их сомнениями.

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

VD>>>А то у тебя и так логиках хромает как у блондинки. Сосредоточься на одной проблеме. Так будет проще не ошибиться.

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

VD>Да я конструктивен. Если я вижу проблему в чей-то логике, и вижу (в добавок) что человек, чья логика хромает на обе ноги, в добавок начинает перескакивать с темы на тему, то я и говорю об этом. Уж извини.

В начале темы я писал, к чему сведется эта "дискуссия". Собственно к тому она и скатилась.

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

F>это псевдопотоки.. потоки в одном системном потоке..

я не знаю, может вы говорите про какую-то одну версию питона для какой-то ОС,
но у меня на винде питон нормально работает в нескольких системных потоках, и использует системные потоки для своих потоков,
см. \Python\thread_nt.h

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

F>>это псевдопотоки.. потоки в одном системном потоке..
A>я не знаю, может вы говорите про какую-то одну версию питона для какой-то ОС,
A>но у меня на винде питон нормально работает в нескольких системных потоках, и использует системные потоки для своих потоков,
A>см. \Python\thread_nt.h

не, падажжи.. ты хочешь сказать, что у тебя питон без GIL-а?. и данные не разрушаются?.
дай погонять, а?.

ЗЫЖ можешь посмотреть на другие реализации питона, которые пытались обойтить эту проблему.. не просто же так шутки ради авторы CPython придумали несколько вывертов для обхода gil-а..

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

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

F>>>это псевдопотоки.. потоки в одном системном потоке..
A>>я не знаю, может вы говорите про какую-то одну версию питона для какой-то ОС,
A>>но у меня на винде питон нормально работает в нескольких системных потоках, и использует системные потоки для своих потоков,
A>>см. \Python\thread_nt.h

F>не, падажжи.. ты хочешь сказать, что у тебя питон без GIL-а?. и данные не разрушаются?.

c GIL'ом. только он не мешает ни разу %)

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

A>c GIL'ом. только он не мешает ни разу %)

В высоконагруженном веб-приложении будет мешать и очень сильно.

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

F>>ну если сложные типы передаются по ссылке и сигнатура метода создаётся лишь однажды при объявлении/импорте, то логично, что список создаётся на момент объявления функции и живёт там продолжительное время..
Z>Это причина, а не логика. Логика подсказывает, что следующие вызовы должны быть эквивалентны, но это не так:
Z>

Z>make_list(42)
Z>make_list(42, [])
Z>

а снаружи они эквивалентны

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

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

F>а снаружи они эквивалентны

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

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

def make_list(element, head=[])
    head << element
end

print make_list(42)
print make_list(42)

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

A>>всё прекрасно работает в разных потоках
F>это псевдопотоки.. потоки в одном системном потоке..
Нет, там реальные потоки. Просто глобальная блокировка никуда не исчезает.

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

D>Здравствуйте, Курилка, Вы писали:

К>>А покажи неривиальную валидаци, не вписывающуюся в JSR-303?

D>А в Spring MVC можно к параметру контроллера страницы (т.е. к GET-параметру HTTP-запроса) прикрутить этот самый JSR303-валидатор, и спринг его зацепит? Если да, тогда данная претензия снимается.

Ну вешаешь @Valid на параметр просто.
Но это опять же демонстрация заморочности построения функционала фреймворка на аннотациях, о чём ты выше писал.

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

L>К чему все это? Я тебе специально вопрос выделил жирным. Выбор var/декларация типа — исключительно иллюстрация того, что изменение синтаксиса — не такая тривиальная задача. Дабы тема опять не съехала в сторону, повторюсь, что речь не о технической стороне дела, а о концептуальной.

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

L>Я вижу проблему в приведенном примере, я вижу на примерах nikov-а, что и в шарпе полно нелогичностей и неоднозначностей. Какие еще мне могуть понадобиться подтверждения того, что проблема реальна?

Ладно. Я наблюдаю очередной приступ клинического фанатазирования с твоей стороны. Мне это уже право надоело.

В примерах, Никова, кстати, очень редко появляются примеры именно синтаксических аномалий. Все они связаны с кривым дизайном C# авторы которого предпочли совместимость с С-ишными принципами прямому дизайну. Учитывая, что все эти ошибки сделаны еще в самых первых версиях я вообще не понимаю причем тут расширяемость.

Основная же часть этюдов Никова — это семантические этюды. С синтаксическими расширен они никак не связаны.

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

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

Вот, буквально на днях пришлось писать совершенно дурацкий код для преобразования Tuple<DerivedClass, string> в Tuple<BaseClass, string>. То же самое для immutable списка (я использовал FSharpList<T> из C#).
Ну и как уже заметили, отсутствие краткого синтаксиса и pattern matching для этих типов.

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

VD>Это в любом языке есть. Более того, если есть более одного компилятора, то у каждого могут быть свои особенности.
VD>Я не понимаю где здесь именно непредсказуемость?

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

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

F>не, падажжи.. ты хочешь сказать, что у тебя питон без GIL-а?. и данные не разрушаются?.
F>дай погонять, а?.

Нет он прав, тот же модуль threading создает вполне полноценные системные потоки.
Но интерпретатор их постоянно блокирует из-за GIL, в результате особенно на SMP все работает еще медленнее чем
было бы в одном потоке. Исключение сишные библиотеки которые могут сразу отпускать GIL если не обращаются к интерпретатору,
что и было продемонстрировано на примере numpy.

На вскидку:
1. Нет поддержки двоичной системы — int a = 0110010b написать нельзя
2. Неявное приведение char* -> bool, double -> int
3. template <double> — не работает, ровно как и например template <std::string>
4. Долго компилируется и линкуется
5. Нет проверки переполнения, типа как в C#: checked { a = b * c; }
6. Нельзя расширить enum объявленный в базовом классе в производном классе

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

FR>было бы в одном потоке. Исключение сишные библиотеки которые могут сразу отпускать GIL если не обращаются к интерпретатору,
FR>что и было продемонстрировано на примере numpy.

знаю, только про системные потоки моя лажа, которую развеял Cyberax..

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

С>Это не ерунда, а трудно вылавливаемые баги в будующем. У нас по умолчанию W4 и работаем без варнингов.

Какой здесь может быть баг?:

class X {
    int const i_;
public:
    X(int i) : i_ (i) {}
}; // warning C4512: 'X' : assignment operator could not be generated

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

A>если ваш код не компилится с /W4 — правьте ваш код.

Как править следующий код, выбрасывать const?:

class X {
    int const i_;
public:
    X(int i) : i_ (i) {}
}; // warning C4512: 'X' : assignment operator could not be generated

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

O>>>Отсутствие двоичного стандарта.
J>>Посмотрел бы я на этот стандарт, который бы удовлетворил и 64-битовым билдам, и 8-битным микроконтроллерам

O>А мне бы хватило стандарта для одной определенной платформы (Windows) — схема расширения имен,
O>объектные файлы, передача объектов/исключений между модулями и тому подобное.
O>Чтобы можно было гарантировать совместимость интерфейсов C++ между теми же dll, собранными
O>разными компиляторами. Может быть, в таких громадинах как COM тогда и не было бы необходимости.

Дык для Windows есть считай стандартизированый ABI — MSVC.
Другой вопрос что следуют ему не все.

O>Куда эта дорога ведет?
К сохранению принципа "платишь только за то, что реально используешь". И это для С++ краеугольный камень

O>>>Отсутствие единого глобального соглашения о скобках, отступах и именах.
J>>Это должно быть частью языка? Типа не правильный отступ или скобка не на той строчке — и код не должен компилироваться?

O>Не правда ли, все это гораздо приятнее читалось бы так:
Не, ужасно читалось бы.

Куда приятнее будет:

bool AcquireCompletionToken (ThreadHandle& handle)
{
    if (handle.GetOwnerThread != PerfThreadId (s_resourcePool->GetThisThread ()))
        return false;

    return PerfThreadAcqToken (handle.GetStorage ());
}

Вот и какой стиль надо принимать за "единственно правильный" (тм)?

O>Я к тому, что некоторые существующие концепции программирования в C++ эволюционировали в нечто
O>настолько сложное и запредельное для понимания обычными людьми, что сильно потеряли, на мой взгляд,
O>в практическом отношении.
Это по мне означает что эти концепции надо пересматривать в сторону упрощения.

O>Мне нравится, когда шаблоны используются как в STL или бустовских смартпоинтерах, или как обертки для COM-интерфейсов в ATL, но когда из них делают что-то, понятное лишь гуру метапрограммирования — это перебор.
А, ты про это. Ну, ИМХО творчество укушенных Александреску нравится только таким же укушенным. И по хорошему такой код надо на помоечку, авторам скипидарную клизму и пусть переписывают заново, без извратов.

O>>>Очень много платформенных "заточек" вроде #pragma, __declspec и #ifdef _X64.
J>>Вообще-то возможность заточки под платформу — это фича языка

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

D>Позвольте представить: говно, просто говно. Я не могу придумать ничего, что бы мне в нём нравилось.
Сурово!

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

Ytz>1. Нет поддержки двоичной системы — int a = 0110010b написать нельзя
мгу ошибаться, но вроде как в С++0х это пофиксили.

Ytz>3. template <double> — не работает, ровно как и например template <std::string>
Можно пример, а то я что то не совсем понял что тут имеется в виду.

Ytz>5. Нет проверки переполнения, типа как в C#: checked { a = b * c; }
реализуется через перегрузку операторов.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Ytz>6. Нельзя расширить enum объявленный в базовом классе в производном классе

Не надо такого делать никогда и нигде. И уж тем более не надо приводить базовый класс к производному.

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

I>Какой здесь может быть баг?:

I>

I>class X {
I>    int const i_;
I>public:
I>    X(int i) : i_ (i) {}
I>}; // warning C4512: 'X' : assignment operator could not be generated
I>

Там ж написано: не могу сгенерить operator=
Потому как i_ константное.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

I>Как править следующий код, выбрасывать const?:

I>

I>class X {
I>    int const i_;
I>public:
I>    X(int i) : i_ (i) {}
private:
    X& operator= (const X&);
I>}; // warning C4512: 'X' : assignment operator could not be generated
I>

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

Ytz>>3. template <double> — не работает, ровно как и например template <std::string>
CC>Можно пример, а то я что то не совсем понял что тут имеется в виду.

template <int Value>
void foo()
{
    ... // Ok
}

template <double Value>
void foo()
{
    ... // Error
}

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

Ytz>

Ytz>template <int Value>
Ytz>void foo()
Ytz>{
Ytz>    ... // Ok
Ytz>}

Ytz>template <double Value>
Ytz>void foo()
Ytz>{
Ytz>    ... // Error
Ytz>}

Ytz>

А чего именно ты этим хочешь добиться?
Чтоб вызов foo<0.5>() обламывался при компиляции?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

CC>А чего именно ты этим хочешь добиться?
CC>Чтоб вызов foo<0.5>() обламывался при компиляции?

Почему он должен обламываться?

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

I>Как править следующий код, выбрасывать const?:

I>

I>class X {
I>    int const i_;
I>public:
I>    X(int i) : i_ (i) {}
I>}; // warning C4512: 'X' : assignment operator could not be generated
I>

вы текст сообщения читали?

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

Нет статической проверки типов. Да и типов по большому счёту нет. Один object с наклейками для проверок в рантайме.

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

CC>>А чего именно ты этим хочешь добиться?
CC>>Чтоб вызов foo<0.5>() обламывался при компиляции?

Ytz>Почему он должен обламываться?
Ну я так понял выделенное

Ytz>

Ytz>template <int Value>
Ytz>void foo()
Ytz>{
Ytz>    ... // Ok
Ytz>}

Ytz>template <double Value>
Ytz>void foo()
Ytz>{
Ytz>    ... // Error
Ytz>Ytz>}
Ytz>

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, dimgel, Вы писали:
D>1. Многабукаф. Нупростодоужасамногабукаф.
Как же тогда люди на коболе писали? По сравнению с коболом в яве почти нет букав.

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

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

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

J>Если вы согласны почти со всем, то это значит, что вы согласны, что почти все претензии не относятся к собственно языку.
J>...

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

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

O>>Куда эта дорога ведет?
CC>К сохранению принципа "платишь только за то, что реально используешь". И это для С++ краеугольный камень

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

O>>Не правда ли, все это гораздо приятнее читалось бы так:
CC>Не, ужасно читалось бы.

CC>Куда приятнее будет:

CC>

CC>bool AcquireCompletionToken (ThreadHandle& handle)
CC>{
CC>    if (handle.GetOwnerThread != PerfThreadId (s_resourcePool->GetThisThread ()))
CC>        return false;

CC>    return PerfThreadAcqToken (handle.GetStorage ());
CC>}
CC>

CC>

CC>Вот и какой стиль надо принимать за "единственно правильный" (тм)?

Так тоже симпатично.

O>>>>Очень много платформенных "заточек" вроде #pragma, __declspec и #ifdef _X64.
J>>>Вообще-то возможность заточки под платформу — это фича языка

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

По крайней мере, если бы эти "заточки" описывались декларативно, в каких-нибудь .platform-файлах,
которые бы потом линковались вместе с объектными файлами, синтаксис от этого только выиграл бы.

Аналогичный тред про С++
http://rsdn.ru/forum/cpp/2995737.aspx

Повторю себя насчёт того, что сейчас актуально:

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

Совместимость целочисленных, логических и символьных типов, а в случае нулевой константы — ещё и указателей:

int main()
{
  int * p1 = false, * p2 = '\0';
  int i1 = true, i2 = 'X';
  unsigned u = -1;
  char c = 22;
}

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

O>>>Куда эта дорога ведет?
CC>>К сохранению принципа "платишь только за то, что реально используешь". И это для С++ краеугольный камень
O>Не вижу связи.
O>В стандартную библиотеку можно впихнуть хоть тысячу контейнеров и алгоритмов, все равно в
O>исполняемый модуль будут включены только те, которые используются в коде программы.

Нее. Не так.
Как уже верно заметил jazzer

с ним вместе должны идти XSLT, XPath, схемы и прочая

Это уже неслабо утяжеляет реализацию XML. Как в плане разработки стандартной библиотеки, которую пишет производитель компилятора (и к тому же тестирует под все платформы, которые поддерживает компилятор) так и в плане того, что вся эта бодяга имеет шансы влинковаться в бинарь.

O>Так тоже симпатично.
Повторюсь

Вот и какой стиль надо принимать за "единственно правильный" (тм)?

CC>>Ну как бы нельзя внести в системный язык фичи всех потенциально поддерживаемых платформ. Они ж зачастую друг другу ортогональны.
O>По крайней мере, если бы эти "заточки" описывались декларативно, в каких-нибудь .platform-файлах,
O>которые бы потом линковались вместе с объектными файлами, синтаксис от этого только выиграл бы.

Я не представляю себе как это сделать так, чтоб не получить путаницы больше чем уже есть.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

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

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

A>>>>А еще:
A>>>>0) нельзя использовать русские буквы в именах переменных и функций

С>>>А это зачем? сделать 1С из С++ ?

A>>Ложная связка. Java по твоему 1С?

С>Разве кто-то этим пользуется?

Я не знаю, может и пользуются.
Ну так ответь на вопрос — если пользуются, значит Ява стала 1С?

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

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

CC>Нее. Не так.
CC>Как уже верно заметил jazzer
CC>

CC>с ним вместе должны идти XSLT, XPath, схемы и прочая

CC>Это уже неслабо утяжеляет реализацию XML. Как в плане разработки стандартной библиотеки, которую пишет производитель компилятора (и к тому же тестирует под все платформы, которые поддерживает компилятор) так и в плане того, что вся эта бодяга имеет шансы влинковаться в бинарь.

Я вижу только одну причину — разработка качественной библиотеки для работы с XML сама по себе является
очень нехилой задачей, а реализация на уровне стандарта С++ и универсализации для разных компиляторов
запредельно сложнее.
По поводу того, что лишний код попадет в исполняемый модуль — сильно сомневаюсь.
Даже если "вхолостую" линковаться с .lib-файлом, ничего от него в exe или dll не остается.

O>>Так тоже симпатично.
CC>Повторюсь
CC>

CC>Вот и какой стиль надо принимать за "единственно правильный" (тм)?

Пусть будет один из вариантов, приведенных выше.
Я говорил вообще не о каком-то конкретном стиле, а о том, что в С++ почему-то принято в
каждой конторе заводить свой фирменный coding style, который затрагивает все и вся — от скобок до
пробела между for и скобкой. Тогда как в более "скромных" языках вроде Javascript эти
вопросы давно решили и большинство следует центральной конвенции, которая вроде бы всех устраивает.

CC>>>Ну как бы нельзя внести в системный язык фичи всех потенциально поддерживаемых платформ. Они ж зачастую друг другу ортогональны.
O>>По крайней мере, если бы эти "заточки" описывались декларативно, в каких-нибудь .platform-файлах,
O>>которые бы потом линковались вместе с объектными файлами, синтаксис от этого только выиграл бы.

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

А def-файлы ? Там, по сути, то же самое.

D>1. Многабукаф. Нупростодоужасамногабукаф.
Никто не заставляет, можно писать коротко

D>2. Не люблю, когда злоупотребляют аннотациями: они хуже проверяются типизатором. В жаве почти все фреймворки работают на аннотациях. Это вот отчаянное желание превратить всё на свете в POJO с аннотациями бесит. Взять тот же Spring MVC.
Никто не заставляет, вполне можно писать и без аннотаций. В простых случаях они действительно удобнее, в сложных берете какой-нибудь AbstractFormController и вперёд.
D>нетривиальную валидацию параметров, как и нетривиальную обработку ошибок, хрен прикрутишь;
Да ладно.

D>отладить эту AOP-хрень практически невозможно;
Да легко.

D>IDE никаких подсказок не возможностям не даёт (базового класса нет, виртуальные методы подсмотреть негде, а аннотации я хз какие в каком случае применимы)
В STS есть поддержка аннотаций для WebMVC

D>Аналогичные претензии к Tapestry, а вот Wicket рулит.
Это в общем не к языку претензии

D>3. После знакомства с ФП стало резко не хватать методов map(), filter() и т.п. на коллекциях.
http://jfunctions.sourceforge.net
Сыровато, документация только в javadoc, пока отсутствует в публичных репозиториях, но пользоваться вполне можно.

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

L>>К чему все это? Я тебе специально вопрос выделил жирным. Выбор var/декларация типа — исключительно иллюстрация того, что изменение синтаксиса — не такая тривиальная задача. Дабы тема опять не съехала в сторону, повторюсь, что речь не о технической стороне дела, а о концептуальной.

VD>Да нет в этом выборе ничего особенного. Здесь опять же речь идет о клинически пугливых теоретиках и практиках.

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

Будем продолжать в том же духе, или все-таки перейдем к нормальной беседе? Предлагаю второе, если не возражаешь.

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

Да я и не оспариваю это, конечно выбор и ответственность лежит исключительно на "конкретной группе людей". Так и есть.
Я ставлю под сомнние то, что человек, не занимающейся проектированием языков, в состоянии адекватно внести изменения в синтаксис существующего языка. Под "адекватностью" я тут имею в виду что внесенное изменение не будет "конфликтовать" с другими концепциями языка и не будет с течением времени выглядеть как нелогичная нелепица. Основанием для этих сомнений служит а) личный опыт написания (и развития) программ, генерирующих код, и б) многочисленные неадекватности и нелогичности, найденые тем же nikov-ом в шарпе и многими другими — в C++.

L>>Я вижу проблему в приведенном примере, я вижу на примерах nikov-а, что и в шарпе полно нелогичностей и неоднозначностей. Какие еще мне могуть понадобиться подтверждения того, что проблема реальна?

VD>Ладно. Я наблюдаю очередной приступ клинического фанатазирования с твоей стороны. Мне это уже право надоело.

Если бы такую фразу написал тебе я, то ты несмомненно посчитал бы это сливом.

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

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

VD>В примерах, Никова, кстати, очень редко появляются примеры именно синтаксических аномалий. Все они связаны с кривым дизайном C# авторы которого предпочли совместимость с С-ишными принципами прямому дизайну.

С С-шными принципы? Это с какими?

VD>Учитывая, что все эти ошибки сделаны еще в самых первых версиях я вообще не понимаю причем тут расширяемость.

Собственно мы и пришли к той точке, о которой я писал много-много постов назад. Точка называется "авторы шарпа — эээ ... допускают ошибки", а мы — нет. Эх, nikov-а на вас нет.

VD>Основная же часть этюдов Никова — это семантические этюды. С синтаксическими расширен они никак не связаны.

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

"Бредовая мантра о вреде макросов" существует только в твоей голове. Я уже уточнил, что именно я имел в виду, когда писал, что метапрограммирование — не нужно. Да, я изначально выбрал неудачную формулировку, признаю свою ошибку.

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

CC>>>А чего именно ты этим хочешь добиться?
CC>>>Чтоб вызов foo<0.5>() обламывался при компиляции?

Ytz>>Почему он должен обламываться?
CC>Ну я так понял выделенное

На всякий случай — это и так не скомпилируется. Дело в том, что int может быть константным параметром шаблона, а вот например double — нет, что на мой взгляд не логично

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

T>Нет статической проверки типов. Да и типов по большому счёту нет. Один object с наклейками для проверок в рантайме.

это фича.

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

Ytz>На всякий случай — это и так не скомпилируется. Дело в том, что int может быть константным параметром шаблона, а вот например double — нет, что на мой взгляд не логично

А, тьфу
Я просто твою начальную фразу

3. template <double> — не работает, ровно как и например template <std::string>

воспринял как инстанциацию template <class TYPE> ...
А пример ещё больше запутал

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

O>По поводу того, что лишний код попадет в исполняемый модуль — сильно сомневаюсь.
O>Даже если "вхолостую" линковаться с .lib-файлом, ничего от него в exe или dll не остается.
Ну скажем если мне не надо например валидация но где то в парсере есть вызов в каком то if который в моём случае никогда не срабатывает то весь код будет подсосан в объектник.
А делать реализацию XML например параметризуемой темплейтами во время компиляции это будет тот ещё ахтунг.

O>Я говорил вообще не о каком-то конкретном стиле, а о том, что в С++ почему-то принято в
O>каждой конторе заводить свой фирменный coding style, который затрагивает все и вся — от скобок до
O>пробела между for и скобкой.
По историческим причинам.

CC>>Я не представляю себе как это сделать так, чтоб не получить путаницы больше чем уже есть.
O>А def-файлы ? Там, по сути, то же самое.
Def файлы вообще никак к языку не относятся. Это специфика для linker.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

A>>А еще:
A>>0) нельзя использовать русские буквы в именах переменных и функций
J>Можно любые, вот цитата из стандарта (старого):
J>

J>identifier:
J>  nondigit
J>  identifier nondigit
J>  identifier digit

J>nondigit: one of
J>  universal-character-name
J>  _ a b c d e f g h i j k l m
J>  n o p q r s t u v w x y z
J>  A B C D E F G H I J K L M
J>  N O P Q R S T U V W X Y Z

J>hex-quad:
J>  hexadecimal-digit hexadecimal-digit hexadecimal-digit hexadecimal-digit

J>universal-character-name:
J>  \u hex-quad
J>  \U hex-quad hex-quad
J>

J>так что все вопросы к конкретному редактору — по старому стандарту он обязан просто превращать юникодные символы в \uXXXX в момент сохранения файла на диск (и обратно при загрузке).
J>Кстати, если вызов компилятора завернуть в элементарный скрипт, который любые уникодные символы будет превращать в universal-character-name и потом звать компилятор — вообще никаких усилий от редактора не потребуется.

С ужасом представил, как это будет выглядеть при отладке.

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

J>В новом стандарте еще проще:
J>

J>identifier-nondigit:
J>  nondigit
J>  universal-character-name
J>  other implementation-defined characters
J>

J>но universal-character-name никуда не делся, так что скрипт будет работать и с кодом, соответствующим новому стандарту.

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

A>>1) нельзя сделать operator[](int index1, int index2)
J>это да, арность, приоритеты и прочая менять нельзя. Это, кстати, дает стабильность синтаксиса, в отличие от языков, в которых это можно. Потому что сейчас a[1,2] эквивалентно a[2], потому что оператор запятая. И это не зависит от типа а. А если разрешить такое, как у тебя, то в зависимости от типа а может быть как оператор запятая + вызов унарной версии, так и вызов бинарной версии.

Экая однако ересь.

Вы что-же батенька, хотите все функции с двумя аргументами запретить? Там же тоже в середине есть запятая.

Например strcmp( s1,s2 );

A>>2) и вообще переопределенных операторов как-то мало
J>В сымсле — мало? 46 операторов (все, кроме четырёх ". .* :: ?:") — это мало? Или ты к тому, что нельзя новых наопределять? Так это палка о двух концах, так как, определяя новый оператор, его нужно каким-то образом включить в систему существующих операторов в смысле приоритета и ассоциативности — немаленькая нагрузка на компилятор, не говоря уже о возникающих неоднозначностях: a**b — это новый оператор ** или a*(*b), как сейчас? Но лучше, конечно, 5 звёздочек

Ну вот простейшая же вещь. Строки можно сравнить и по длинне и по алфавиту.
И то и другое — оператор "больше". Как предлагаете выйти из ситуации?

A>>3) нельзя return x,y ;
J>

J>return boost::make_tuple(x,y);
J>

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

A>>4) нет безымянных функций и нельзя сделать вот так "функция( { тут какое-нибудь выражение } )"
J>можно в C++0x (VC и GCC уже поддерживают)

Это как бы несколько другой язык.

A>>5) нельзя поймать исключение SegFault и продолжить работу
J>оно за пределами языка, так что надо пользоваться внеязыковыми средствами, доступными в библиотеках.

Ну а почему оно "за пределами языка"? Должно быть "в пределах". (топаю ножкой)

A>>6) В STL нет контейнера "граф"
J>А так же Map/Reduce, youtube video search, переводчика с японского на корейский и еще миллиона структур и алгоритмов. Библиотеки на что? Boost.Graph, например.

Да как тебе сказать... STL это УЖЕ библиотека.

T>>Нет статической проверки типов. Да и типов по большому счёту нет. Один object с наклейками для проверок в рантайме.

A>это фича.

Это нерелевантно. Вопрос был "что не нравится", а не "назовите всё кроме фич". Но даже если потролить, мы, наверное, по-разному понимаем фичи.

Полиморфизм, замыкания, ФВП, юникодные строки, list comprehension — это фичи. Они позволяют делать то, что иначе было бы в разной степени некрасивым "многабукф".

Отсутствие типов и статической их проверки позволяет делать то же самое, что "обычные" полиморфизм, вывод типов, кодогенерация или шаблоны плюс разной степени трудноуловимые баги и существенно затрудняют оптимизации. Я не могу назвать это фичей. Это отсутствие фичи и свиду симпатичный (любое говно можно преподнести как конфету) костыль взамен. Для прототипов — самое то! Для боевого кода хочется побольше уверенности и поменьше накладных расходов. Видимо, поэтому существенная масса разрабов колются, плакают но продолжают жрать С++.

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

... (много букф)

это называется "динамическая типизация" и это фича.
то что вы хотите от языка с динамической типизацией чтоб он был как язык со статической типизацией — означает что вы выбрали не тот язык, и не понимаете почему он так спроектирован.

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

Мыши кололись и плакали, но продолжали жрать кактус

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

U>>Мы про систему типов шарпа или про проектирование языка с нуля?
WH>Один хрен там магия жуткая понадобится.
WH>Причем на ровном месте. Просто по тому что тебе так захотелось.

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

Поэтому, проверка контракта NotNull вполне решаема на зависимых типах без всяких монад Maybe, просто лишь объявление такого типа и использование его во всех вычислениях.

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

A>очевидно надо сделать класс noncopyable или самому реализовать оператор присваивания

Тогда вместо ошибки компиляции с точным указанием строки получим менее внятную ошибку компоновки:

class X {
    int const i_;
public:
    X(int i) : i_ (i) {}

    void f(X const& x)
    {
        *this = x;
    }
private:
    X& operator=(X const&);
};

И главное, я все же не понимаю, от каких таких багов предупреждение C4512 призвано уберечь.

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

CC>Там ж написано: не могу сгенерить operator=

Это же не баг. Ты из контекста не выпадай: здесь

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

L>Да я и не оспариваю это, конечно выбор и ответственность лежит исключительно на "конкретной группе людей". Так и есть.
L>Я ставлю под сомнние то, что человек, не занимающейся проектированием языков, в состоянии адекватно внести изменения в синтаксис существующего языка. Под "адекватностью" я тут имею в виду что внесенное изменение не будет "конфликтовать" с другими концепциями языка и не будет с течением времени выглядеть как нелогичная нелепица. Основанием для этих сомнений служит а) личный опыт написания (и развития) программ, генерирующих код, и б) многочисленные неадекватности и нелогичности, найденые тем же nikov-ом в шарпе и многими другими — в C++.

L>>>Я вижу проблему в приведенном примере, я вижу на примерах nikov-а, что и в шарпе полно нелогичностей и неоднозначностей. Какие еще мне могуть понадобиться подтверждения того, что проблема реальна?

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

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

L>"Бредовая мантра о вреде макросов" существует только в твоей голове. Я уже уточнил, что именно я имел в виду, когда писал, что метапрограммирование — не нужно. Да, я изначально выбрал неудачную формулировку, признаю свою ошибку.

Есть руби, в котором метапрограммирование это неотъемлемая часть. Практически каждый серьезный широкоиспользуемый плагин для RoR широко использует кодогенерацию (зачастую текстовую) и свой edsl.

Практически все плагины которые не придумали (придумали плохой) edsl или не справились с кодогенерацией просто непопулярны. Для рельс практически нет платных плагинов, их разрабатывает community. Никакой катастрофы не произошло, популярность у языка и фреймворка прекрасные.

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

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

J>>так что все вопросы к конкретному редактору — по старому стандарту он обязан просто превращать юникодные символы в \uXXXX в момент сохранения файла на диск (и обратно при загрузке).
J>>Кстати, если вызов компилятора завернуть в элементарный скрипт, который любые уникодные символы будет превращать в universal-character-name и потом звать компилятор — вообще никаких усилий от редактора не потребуется.

A>С ужасом представил, как это будет выглядеть при отладке.

ой, да. Дебагер — наше все

ну да дебагер тоже можно заточить это преобразование делать, пр крайней мере gdb7 и дальше — там можно на Питоне фильтрацию написать. Если уж так позарез нужны русские идентификаторы.

A>Нельзя так пугать. Лучше бы ты транслит посоветовал.
A>Или английский учить, как тут многие "выучившие" советуют.
Ессно, английский. Русский (и в виде транслита тоже) выглядит крайне неуклюже из-за того, что в русском языке есть склонения, спряжения, и род.
Сравни "I.love(Olga);" и "Я.любить(Ольга);"

J>>В новом стандарте еще проще:
J>>

J>>  other implementation-defined characters
J>>

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

A>Вы что-же батенька, хотите все функции с двумя аргументами запретить? Там же тоже в середине есть запятая.

A>Например strcmp( s1,s2 );

Очень смешно. Грамматику почитай, что ли.

  postfix-expression [ expression ]
  postfix-expression ( expression-list opt )

expression-list:
  assignment-expression
  expression-list , assignment-expression // разделитель аргументов

expression:
  assignment-expression
  expression , assignment-expression // оператор запятая

A>Ну вот простейшая же вещь. Строки можно сравнить и по длинне и по алфавиту.
A>И то и другое — оператор "больше". Как предлагаете выйти из ситуации?
Флудим?

A>>>3) нельзя return x,y ;
J>>

J>>return boost::make_tuple(x,y);
J>>

A>Ты бы мне еще посоветовал структуру завести. Или вернуть через выходные параметры.
Будешь продолжать бессмысленный флуд — посоветую.
A>Ты не видишь, насколько эта запись длиннее необходимой?
Насколько?

A>>>4) нет безымянных функций и нельзя сделать вот так "функция( { тут какое-нибудь выражение } )"
J>>можно в C++0x (VC и GCC уже поддерживают)

A>Это как бы несколько другой язык.

С чего бы вдруг другой? Причем компиляторы _уже_ поддерживают. Тебе шашечки или ехать? Или просто пофлудить охота, видимо.

A>>>5) нельзя поймать исключение SegFault и продолжить работу
J>>оно за пределами языка, так что надо пользоваться внеязыковыми средствами, доступными в библиотеках.

A>Ну а почему оно "за пределами языка"? Должно быть "в пределах". (топаю ножкой)

A>>>6) В STL нет контейнера "граф"
J>>А так же Map/Reduce, youtube video search, переводчика с японского на корейский и еще миллиона структур и алгоритмов. Библиотеки на что? Boost.Graph, например.

A>Да как тебе сказать... STL это УЖЕ библиотека.
Я на этот бред не буду отвечать, хорошо? В общем-то, и на предыдущий не надо было.
Будет желание серьезно что-то обсудить, а не просто позубоскалить и поупражняться в 10-пальцевой слепой печати — заходи, а иначе — не надо, плиз, сходи в КСВ лучше.

Здравствуйте, Слава, Вы писали:
С>C++ невозможно отличить создание временнoгo обьекта от вызова функции:

С>int a = foo(B(x)); — что здесь B(x) ?

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

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

Z>Есть руби, в котором метапрограммирование это неотъемлемая часть. Практически каждый серьезный широкоиспользуемый плагин для RoR широко использует кодогенерацию (зачастую текстовую) и свой edsl.

Z>Практически все плагины которые не придумали (придумали плохой) edsl или не справились с кодогенерацией просто непопулярны. Для рельс практически нет платных плагинов, их разрабатывает community. Никакой катастрофы не произошло, популярность у языка и фреймворка прекрасные.

Z>К сожалению, рубийный подход прямо не работает. Не все, что так легко делается в руби легко сделать в nemerle (обратное тоже верно).

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

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

С>>C++ невозможно отличить создание временнoгo обьекта от вызова функции:
С>>int a = foo(B(x)); — что здесь B(x) ?

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

При чём тут студенческие лабораторные? Даже в стандартной библиотеке можно найти подобные примеры, типа back_inserter/back_insert_iterator.

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

CC>Дык для Windows есть считай стандартизированый ABI — MSVC.

Хотелось, бы но именно бинарного даже в пределах MSVC для C++ нету.

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

CC>А чего именно ты этим хочешь добиться?
CC>Чтоб вызов foo<0.5>() обламывался при компиляции?

D не обламывается http://www.digitalmars.com/d/2.0/templates-revisited.html

import std.stdio;

template factorial(double n) if (n > 1.0)
{
  const factorial = n * factorial!(n-1);
}

template factorial(double n) if (n <= 1.0)
{
  const factorial = 1.0;
}


void main()
{
  writeln(factorial!(4));
}

Конечно при этом надо учитывать особенности плавающих чисел.

1. Невозможность отвязать instance method от этого instance. Т.е. если я могу писать someInstance.someMethod(arg1, ..., argn), то я хочу иметь возможность писать и SomeClass.someMethod(someInstance, arg1, ..., argn). Это чтобы в Array.map и т.п. передавать отвязанные функции.
2. Слабая динамика у конструкторов. Я не могу вызывать конструктор с заранее неизвестным числом аргументов. Для функции написать someFunc.apply(null, args) можно, а вот создать экземпляр var cls : Class = ..., new cls(args) где args — массив аргументов конструктора — нельзя. Приходится писать методы с фиксированным числом аргументов. Такие конструкторы парсеры внешних данных позволили бы сократить. Ну и в конфиг внешний уже далеко не все можно положить.
3. Номинативная типизация интерфейсов. Хочу структурную. И сахар для создания новых интерфейсов на базе существующих с переопределением и добавлением полей. Основное применение этой штуки — подписка и отписка от глобальной модели данных в локальных модулях. Внутри модуля подписка/отписка происходит с оберткой, после завершения работы модуля отписка происходит в одном месте. Это позволяет не особо задумываться о lifetime management внутри модуля.

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

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

С>>Это не ерунда, а трудно вылавливаемые баги в будующем. У нас по умолчанию W4 и работаем без варнингов.

I>Какой здесь может быть баг?:

I>

I>class X {
I>    int const i_;
I>public:
I>    X(int i) : i_ (i) {}
I>}; // warning C4512: 'X' : assignment operator could not be generated
I>

Модифицируем пример. Можно?

struct aa
{
    int* b;
    aa(int a)
    {
        b = new int(a);
    }
    ~aa()
    {
        delete b;
        b = 0;
    }
};

class X {
     aa const i_;
public:
    X(int i) : i_ (i) {}

};

void main() 
{
    X x(5);
    X y(x); //утечка памяти. А компилятор предупреждал....
    int a =0;

}

значит нельзя в copy constructor вызывать operator= - компилятор же сказал - не могу сгенерировать. Такой обьект должен быть non cpoyble

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

O>>>>Отсутствие единого глобального соглашения о скобках, отступах и именах.
J>>>Это должно быть частью языка? Типа не правильный отступ или скобка не на той строчке — и код не должен компилироваться?

К>>В качестве примеров "из другой песочницы" — Code Conventions for the Java Programming Language и Style Guide for Python Code.

J>Я тебе и на Си с десяток таких насобираю.

В том то и дело, что с десяток. А вот для Java это единственные Code Conventions.

J>Это часть языка? Нет.
J>Код, не соответствующий этим соглашениям в "других песочницах", отвергается компиляторами? Нет.

А это не важно, я не помню видел ли я Java код написанный как-то по другому.

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

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

CC>>А чего именно ты этим хочешь добиться?
CC>>Чтоб вызов foo<0.5>() обламывался при компиляции?
FR>Конечно при этом надо учитывать особенности плавающих чисел.
Вот из-за этих особенностей в С++ этого и нет — признали слишком опасным
Тут в рантайме у людей через одного проблемы с плавающей точкой, какой уж там компайл-тайм.

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

С>struct aa
С>{
С>    int* b;
С>    aa(int a)
С>    {
С>        b = new int(a);
С>    }
С>    ~aa()
С>    {
С>        delete b;
С>        b = 0;
С>    }
С>};

Этого достаточно, смотри:

int main() 
{
    aa x(5);
    aa y(x); //утечка памяти. И даже компилятор не предупреждает...
}

Мой класс тут ни при чем, баг в твоем.

PS. Возвращаемое значение функции main — int, а не void.

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

0. Сверхнизкая скорость развития.
1. Примитивные типы, которые не наследуются от Object. Из за того что оптимизации по памяти вынесены на уровень типов получается геморрой.
2. Отсутствие перегрузки операторов. Ведет к появлению монстров типа BigInteger.
3. Отсутствие явного синтаксиса для immutable типов.
4. Недоделанные генерики которые прикрутили с учетом обратной совместимости.
5. Отсутствие короткого синтаксиса для замыканий. Фактически не дает пользоваться функциональщиной.

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

FR>>Конечно при этом надо учитывать особенности плавающих чисел.
J>Вот из-за этих особенностей в С++ этого и нет — признали слишком опасным

Не вижу опасностей больших чем те уже есть.

J>Тут в рантайме у людей через одного проблемы с плавающей точкой, какой уж там компайл-тайм.

В компайл-тайм как раз проще будет, ошибка сразу проявится.

И если уж поддерживаешь Compile Time Function Execution (CTFE) (C++0x constexpr)
то и поддержка плавающих чисел и строк в параметрах шаблонов логична.

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

ОК.

Я писал, что предупреждения 4 -го уровня уберегаю от трудноуловимых багов. Так о чём же здесь компилятор предупреждает? Согласен, что в оригинальном коде бага нет.

class X {
     int const i_;
public:
    X(int i) : i_ (i) {}
};

Но в будущем кто — нибудь вдруг захочет написать что-то такое:

X a(5);
X b(6);

a = b;

Компилятор здесь даст по рукам. Автор кода посмотрит на код, увидит, что operator= не определён и определит его как-нибудь так:
Я утрирую....

{
    memcpy(this,&other,sizeof(X));
}

А если бы класс был бы non copybale, то пользователь бы уже пересмотрел бы свою точку зрения и поменял бы свой дизайн.

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

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

С>А если бы класс был бы non copybale, то пользователь бы уже пересмотрел бы свою точку зрения и поменял бы свой дизайн.

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

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

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

С>>А если бы класс был бы non copybale, то пользователь бы уже пересмотрел бы свою точку зрения и поменял бы свой дизайн.

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

ХЗ, может быть const сидит глубоко в базах, а быдлокодер просто не просмотрел. A non copyable — типа декларация. кроме того, кроме закрытия оператора присвания, ему ещё и имплементацию не пишут, что правда приведёт к ошибке линковки, что быдлокодеру в принципе тоже будет непонятно, но он точно не сможет так использовать класс. Кроме того операторы — невиртуальные, что тоже ограничение, правда не сильное. Короче если прислушаться к предупреждению, и закрыть оператор присваивания явно, то толучаем декларацию, что класс не копируемый, и затрудняем быдлокодеру жизнь, если он решит пойти по пути ломания архитектуры.

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

С>ХЗ, может быть const сидит глубоко в базах, а быдлокодер просто не просмотрел. A non copyable — типа декларация. кроме того, кроме закрытия оператора присвания, ему ещё и имплементацию не пишут, что правда приведёт к ошибке линковки, что быдлокодеру в принципе тоже будет непонятно, но он точно не сможет так использовать класс. Кроме того операторы — невиртуальные, что тоже ограничение, правда не сильное. Короче если прислушаться к предупреждению, и закрыть оператор присваивания явно, то толучаем декларацию, что класс не копируемый, и затрудняем быдлокодеру жизнь, если он решит пойти по пути ломания архитектуры.

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

PS. Да кстати, "он точно" "сможет так использовать класс". Ну просто использует memcpy.

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

1. Компиляции.... После Python это просто вымораживает, особенно, когда доводишь проект, созданный "гением от Александреску"
2. Шаблоны. Точнее, не шаблоны, а то, что их можно применять не в мирных целях (особенно смешать с макросами). В итоге, иногда приходится тратить куеву хучу времени на поиск какой-нибудь функции, объявление и определение которой выло сгенерировано по шаблонам с макросами.
3. Типизированность — нельзя взять и тупо сказать log() << some_variable, если эта переменная имеет тип, взятый из каких-то через 5 двор заинлайненых хедеров из третьего переименованного неймспейса. Да если этот тип даже и является в конце-концов каким-нибудь "стандартным" списком со вполне себе "стандартным" типом элементов.

Все это проявляется, когда смешиваешь работу в Python и С++.

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

Ytz>>5. Нет проверки переполнения, типа как в C#: checked { a = b * c; }
CC>реализуется через перегрузку операторов.

Этот checked можно на уровне модуля контролировать опциями компилятора.

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

FR>В компайл-тайм как раз проще будет, ошибка сразу проявится.

а что считать ошибкой? f<1e10> и f<1e10-1e-10> — это один и тот же тип? Зависит от того, с какой точностью ведутся вычисления, правда? а f<0.9999999999999> и f<0.9999999999998> и f<1.0/3*3>? При том, что битность регистров сопроцессора обычно другая и не совпадает ни с double, ни с long double? Плюс, разные процессоры по-разному считают, даже при одной и той же битности. Хуже того, один и тот же компилятор, собранный с разными ключами компиляции, влияющими на работу с плавающей запятой, может считать эти инстанцирования как идентичными, так и различными. А если еще вспомнить про разные варианты НаНов, знаки нуля

Оно тебе надо?

FR>И если уж поддерживаешь Compile Time Function Execution (CTFE) (C++0x constexpr)
FR>то и поддержка плавающих чисел и строк в параметрах шаблонов логична.
строки — это вообще объекты. И то, и другое сейчас поддерживается через template<float*> и template<char*> . И там проблем с уникальностью нет, указатель один на все. А если очень хочется пометапрограммировать, рассматривая строки как последовательности символов, то к твоим услугам boost::mpl::string.

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

inline double pi() { return 3.1415926; }
template<double(*)()> struct C {};
C<&pi> c;

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

J>а что считать ошибкой? f<1e10> и f<1e10-1e-10> — это один и тот же тип? Зависит от того, с какой точностью ведутся вычисления, правда? а f<0.9999999999999> и f<0.9999999999998> и f<1.0/3*3>? При том, что битность регистров сопроцессора обычно другая и не совпадает ни с double, ни с long double? Плюс, разные процессоры по-разному считают, даже при одной и той же битности. Хуже того, один и тот же компилятор, собранный с разными ключами компиляции, влияющими на работу с плавающей запятой, может считать эти инстанцирования как идентичными, так и различными. А если еще вспомнить про разные варианты НаНов, знаки нуля

Оно тебе надо?

Ну при желании можно было бы стандартизировать compile-time вычисления с плавающими точками.
Хотя согласен для C++ то, что ты написал выше проблема, шаблон практически всегда определяет тип.
В D нет, в большинстве случаев шаблон выдает нечто константное без определения нового типа, в том же примере выше

template factorial(double n) if (n > 1.0)
{
  const factorial = n * factorial!(n-1);
}

template factorial(double n) if (n <= 1.0)
{
  const factorial = 1.0;
}

результатом инициации шаблона будет число типа const double.

J>строки — это вообще объекты. И то, и другое сейчас поддерживается через template<float*> и template<char*> . И там проблем с уникальностью нет, указатель один на все. А если очень хочется пометапрограммировать, рассматривая строки как последовательности символов, то к твоим услугам boost::mpl::string.

Неудобно и медленно по сравнению с D'шными строками параметрами шаблонов + CTFE.

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

J>inline double pi() { return 3.1415926; }
J>template<double(*)()> struct C {};
J>C<&pi> c;
J>

Угу как всегда в C++ шаблонах все окольными путями.
В общем по теме топика для C++ требуется Templates Revisited

Ф>Есстественно, что имеется ввиду язык, на котором вы специализируетесь, т.е. если вы пишете на ЯП "А", но раз в неделю вам приходится написать 10 строчек на ЯП "Б", то не надо писать о "Б".

Ф>Пожалуйста, выносите в заголовок ответа название языка.

Ф>Очень надеюсь, что ветка не скатися в холливар.

Пишу на многих.

PHP

О его недостатках сказано столько, что лучше не повторяться. Например: http://wiki.rsdn.ru/php-defects.ashx

Python

Слегка кастрированные возможности ФП (например, отсутсвие многострочных лямбд)
Наличие разыменования, но отсутствие ПМ
Фича языка, которую надо знать, а я не знаю Присваивание объекта не копирует объект, а присваивает ссылку на объект. Из-за этого можно нарваться на явные и неявные глюки, когда модифицируешь один объект, а изменяется другой. Из-за этого относительно часто надо делать copy.copy()
Significant whitespace — зло Не всегда, но бывает

Javascript

Слабая типизация
Ошибка исполнения тупо убивает исполнение всех скриптов на странице
Прочее, что есть в "Javascript: The Good Parts" Крокфорда

Java

Многословность
Скука смертная. Хочется ФП и какой-то "живости"
Хочется ПМ
Из-за дикого количества даже стандартных библиотек, если с Java плотно не работаешь, то поиск нужного тебе способа что-то сделать может превратиться в адъ

Erlang

По сути есть только одна IDE — Erlide. Но Eclipse не нравится, хочется IDEA или на худой конец Netbeans. Но жить можно
Если файл уже module.erl, зачем еще раз указывать -module(module) в заголовке файла?
Хочется компонентность/модульность по типу java. Чтобы было не плоское/глобальное пространство имен
Хочется побольше библитек — как в Питоне/Java/.NET. Такого количества нет, но уже сейчас есть синдром NIH или просто незнание, что такие проекты уже есть (5 способов парсить JSON, 3 проекта по соединению с ruby и т.д. и т.п.)

... << RSDN@Home 1.2.0 alpha 5 rev. 1498>>

От:	Философ	http://vk.com/id10256428
Дата:	22.04.11 21:22
Оценка:

	От:	Abyx
	Дата:	22.04.11 22:02
	Оценка:	+1

От:	Философ	http://vk.com/id10256428
Дата:	22.04.11 22:09
Оценка:

	От:	Abyx
	Дата:	22.04.11 22:30
	Оценка:	1 (1) -1

От:	Qbit86	https://twitter.com/qbit86
Дата:	22.04.11 23:33
Оценка:	+1

	От:	Roman Odaisky
	Дата:	23.04.11 08:41
	Оценка:	+2

	От:	любой
	Дата:	23.04.11 11:13
	Оценка:	1 (1)

От:	okman	https://searchinform.ru/
Дата:	23.04.11 18:33
Оценка:

От:	dimgel	https://github.com/dimgel
Дата:	23.04.11 18:49
Оценка:

От:	Don Reba	https://stackoverflow.com/users/49329/don-reba
Дата:	24.04.11 01:19
Оценка:

От:	VladD2	www.nemerle.org
Дата:	24.04.11 02:35
Оценка:

От:	Курилка	http://kirya.narod.ru/
Дата:	24.04.11 06:51
Оценка:

От:	jazzer	Skype: enerjazzer
Дата:	24.04.11 07:02
Оценка:	+2

От:	nikov	http://www.linkedin.com/in/nikov
Дата:	24.04.11 17:38
Оценка:

От:	Ytz	https://github.com/mtrempoltsev
Дата:	24.04.11 18:10
Оценка:

От:	Mamut	http://dmitriid.com
Дата:	29.04.11 08:08
Оценка:

От:	DemAS	http://demas.me
Дата:	17.05.11 17:56
Оценка: