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

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

Которые и сейчас замечательно эмулируются (хотя, конечно, родные концепты были бы удобнее).

Я пишу на работе очень много шаблонов, так вот у меня добрая половина текста каждого шаблона — это проверка параметров и ругань через BOOST_MPL_ASSERT_MSG (http://www.boost.org/libs/mpl/doc/refmanual/assert-msg.html), если что не так. Вывод компилятора становится очень даже читабельным (цепочка звездочек очень хорошо видна и нет проблем ее подсветить/отфильтровать, если ты пропускаешь ругань компилятора через какой-нть процессор, как это делаю я, и/или как-то раскрашиваешь), ибо в нем теперь содержится человеческое описание ошибки (по ссылке есть пример такой ошибки).

Более того, когда этот шаблонный код (и не только шаблонный) генерится макросом, то в проверки можно вставить непосредственно и имена, которые пришли в макрос в виде параметров — тем самым сообщения компилятора становятся совсем замечательными.

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

You will always get what you always got
  If you always do  what you always did

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

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

Все-таки надо было их добавить, хотя бы в урезанном виде, в том же D тоже не осилили всего того, что предлагалось в C++0x,
но в результате все-равно очень мощная и симпатичная (практически развитие в сторону паттерн матчинга для шаблонов)
штучка получилась:

http://www.digitalmars.com/d/2.0/concepts.html
http://www.digitalmars.com/d/2.0/cpp0x.html#concepts

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

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

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

FR>Все-таки надо было их добавить, хотя бы в урезанном виде, в том же D тоже не осилили всего того, что предлагалось в C++0x,
FR>но в результате все-равно очень мощная и симпатичная (практически развитие в сторону паттерн матчинга для шаблонов)
FR>штучка получилась:

FR>http://www.digitalmars.com/d/2.0/concepts.html
FR>http://www.digitalmars.com/d/2.0/cpp0x.html#concepts

Так может, и добавят в результате.
Эту же версию зарубили из-за того, что она неудобна в использовании.
Может, примут нечто похожее на D.

В конце концов, Уолтер Брайт — член плюсового комитета...

You will always get what you always got
  If you always do  what you always did

BulatZiganshin,

BZ>во-первых, это и есть в моём понимании RAII для Haskell.
BZ>во-вторых, посмотри на стандартный bracket — он защищён от исключений
Да, спасибо, я подумал про это спустя некоторое время.

BZ>ну и главное — мы говорим о continuations, где это как раз нельзя использовать. почитай про монаду Cont.
Да, спасибо, сам догадался (тов. Klapaucius навёл на правильные мысли).

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

BZ>а, я понял, вы под системными тредами понимаете сделанные без continuations? тошда ответ такой — семантика другая. разберитесь наконец в существе вопроса вместо теоретических рассуждений о неизвестном вам предмете

Мощное заявление. Стоило бы подкрепить фактами, особенно рассуждая о семантике нереализованной и неизвестной вам библиотеки потоков. :)

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

FR>

FR>tst: for(int i = 0; i < 10; ++i)
FR>{
FR>    while(true)
FR>    {
FR>        break tst; // выходим из for
FR>    }    
FR>}

FR>

Чем это лучше того что уже есть?

for(int i = 0; i < 10; ++i)
{
    while(true)
    {
        goto tst; // выходим из for
    }    
}
tst: 
  // далее...

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

_>Чем это лучше того что уже есть?

1. тем, что имя циклу логично давать в его начале, а не конце. сравни к примеру:

{
 ....
}
void f() // да-да, друзья, предыдущие 3 страницы кода были описание функции f. а вы что думали?

2. тем что кроме break, continue и может ещё какие слова могут ссылаться на ту же метку

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



_>Чем это лучше того что уже есть?

Тем же чем break лучше goto.

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

J>А самое главное, чтобы была бы свободная возможность работать с таким полем, как с любым другим полем.
А ничего, что это "всего лишь навсего" нарушение инкапсуляции? Думается что нынешняя ситуация и идеологически и семантически корректная.
За инициализацию объекта должен отвечать сам объект, а не кто-то там.

J>Программист должен самостоятельно обеспечить валидность объекта этот момент, <skip>
— добавив ему конструктор по умолчанию! Кстати, компилятор именно это и говорит

Здравствуйте, BulatZiganshin и FR

Ну вы даёте... Вы, наверно, смерти желаете С++? Я за молодостью лет не застал язык PL/1, но пишут, что он умер от того, что в нем слишком много всего было.

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

Автор: _nn_
Дата: 06.07.10

?

Название после цикла? Тут нет проблем. Цикл на три страницы — вот это проблема.
Много вложенных циклов? Так избавьтесь от них. Сделайте функцию, а в ней return. Сделайте ее inline.

Ну а в редких случаях (типа обработки n-мерных массивов) поставьте goto. И комментарии. Один оператор goto в пределах функции 50 — 100 строк не испортит вашу карму. И да не падёт на вас проклятье Дийкстры.

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

_>Ну вы даёте... Вы, наверно, смерти желаете С++? Я за молодостью лет не застал язык PL/1, но пишут, что он умер от того, что в нем слишком много всего было.

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

_>Вы хотите, чтобы нужно было постоянно держать в голове тысячу особенностей?

нет. я и со времён AT&T 2.0 знаю C++ только частично

_>Название после цикла? Тут нет проблем. Цикл на три страницы — вот это проблема.

я не призываю увеличить C++, просто объясняю человеку общеизвестные вещи из теории ЯП

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

_>Здравствуйте, BulatZiganshin и FR

_>Ну вы даёте... Вы, наверно, смерти желаете С++? Я за молодостью лет не застал язык PL/1, но пишут, что он умер от того, что в нем слишком много всего было.

Я тоже не застал, но говорят что C++ его и так уже догнал

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

Автор: _nn_
Дата: 06.07.10

?

Нет наоборот, чтобы такого не было языку шаблонов не хватает выразительности, чтобы хватало нужно совсем немного добавить, новый стандарт делает правильные, но слишком робкие шаги. Например в том же D в шаблоны уже добавлено практически все что нужно, и писать на шаблонах там на порядок проще чем в C++ и например весь ужас из твоей ссылки заменится простой compile time функцией.

_>Название после цикла? Тут нет проблем. Цикл на три страницы — вот это проблема.
_>Много вложенных циклов? Так избавьтесь от них. Сделайте функцию, а в ней return. Сделайте ее inline.

_>Ну а в редких случаях (типа обработки n-мерных массивов) поставьте goto. И комментарии. Один оператор goto в пределах функции 50 — 100 строк не испортит вашу карму. И да не падёт на вас проклятье Дийкстры.


Выход из цикла в D стиле ничего ни добавляет лишнего, все просто и прозрачно и карма не страдает совсем

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

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

__>>Мне хотя бы constexpr и возможность манипулировать строками (массивами) во времени компиляции.

__>>

__>>const int hash_abc = hash("abc"); // compile time :)
__>>

FR>В D есть http://www.digitalmars.com/d/2.0/function.html#interpretation

Так я как раз с намеком на D
Другое дело, что инструментов для С++ несравнимо больше чем для D, что резко сужает область применения.

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


J>Boost.Optional спасет отца русской демократии. У него нет ни одной из описанных проблем.

Не всегда спасает

struct a : boost::noncopyable
{
    a(int)  {}

    int g() { return 1; }
};

struct use_pointer
{
    use_pointer()
    {
        a_ = new a(1);
    }

    a* a_;
};

struct use_optional
{
    use_optional()
    {
        a_ = ??? // :(
    }

    boost::optional<a> a_;
};

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

__>

__>        a_ = ??? // :(
__>    boost::optional<a> a_;
__>

В смысле? Тут надо in_place_factory юзать (если я правильно помню название)

You will always get what you always got
  If you always do  what you always did

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

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

__>>

__>>        a_ = ??? // :(
__>>    boost::optional<a> a_;
__>>

J>В смысле? Тут надо in_place_factory юзать (если я правильно помню название)

Вопрос как надо юзать?

struct use_optional
{
        use_optional() : a_(boost::in_place(1)) // OK , но надо позже , а не здесь
    {
               a_.какой метод ?

    }

    boost::optional<a> a_;
};

noncopyable в boost::optional

Автор: rusted
Дата: 06.08.08

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

J>>В смысле? Тут надо in_place_factory юзать (если я правильно помню название)

__>Вопрос как надо юзать?

если я правильно помню (под рукой нет документации), у boost::optional просто есть оператор присваивания, который принимает фабрику. Так что в момент присваивания она все там и создаст.
Поправь, если не так.

__>noncopyable в boost::optional

Автор: rusted
Дата: 06.08.08

Есть какие-то специфические проблемы именно с noncopyable?
Я не помню, использовал ли я optional с noncopyable. Может, и есть какие проблемы.

You will always get what you always got
  If you always do  what you always did

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

Оно.
А я уже что только не пробовал.
В документации об этом нифига не написано

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

_>Ну вы даёте... Вы, наверно, смерти желаете С++? Я за молодостью лет не застал язык PL/1, но пишут, что он умер от того, что в нем слишком много всего было.

На самом деле, нет. Он ушёл в прошлое вместе с Большими Машинами (tm). Просто в нём было много такого, что не требовалось в языках а-ля C. Например, механизм определения типа переменной по имени. То есть фич-то было много, но на практике они были скорее странными, чем сильно необходимыми. А так, чего там, есть (были, во всяком случае, сейчас лень искать) компиляторы PL/M и для PC.

P.S.: Хотя... Вот, для IBM zSeries, наверное, есть PL/1, который не подозревает о том, что он уже прошлое.

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

_>>Ну вы даёте... Вы, наверно, смерти желаете С++? Я за молодостью лет не застал язык PL/1, но пишут, что он умер от того, что в нем слишком много всего было.

ГВ>А так, чего там, есть (были, во всяком случае, сейчас лень искать) компиляторы PL/M и для PC.

pl/m к этой избыточности отнощшения как раз не имеет, это язык на уровне C