Здравствуйте, BulatZiganshin, Вы писали:
BZ>для того, чтобы у тебя в шаблонах/макросах не появлялось многоэтажных сообщений об ошибках, нужна типизация. те самые концепты. без них что угодно можно подставить куда попало
Которые и сейчас замечательно эмулируются (хотя, конечно, родные концепты были бы удобнее).
Я пишу на работе очень много шаблонов, так вот у меня добрая половина текста каждого шаблона — это проверка параметров и ругань через BOOST_MPL_ASSERT_MSG (http://www.boost.org/libs/mpl/doc/refmanual/assert-msg.html), если что не так. Вывод компилятора становится очень даже читабельным (цепочка звездочек очень хорошо видна и нет проблем ее подсветить/отфильтровать, если ты пропускаешь ругань компилятора через какой-нть процессор, как это делаю я, и/или как-то раскрашиваешь), ибо в нем теперь содержится человеческое описание ошибки (по ссылке есть пример такой ошибки).
Более того, когда этот шаблонный код (и не только шаблонный) генерится макросом, то в проверки можно вставить непосредственно и имена, которые пришли в макрос в виде параметров — тем самым сообщения компилятора становятся совсем замечательными.
Так что иметь концепты, безусловно, было бы здорово, но и без них нормально живется, если приложить к тому усилия.
Здравствуйте, jazzer, Вы писали:
J>Так что иметь концепты, безусловно, было бы здорово, но и без них нормально живется, если приложить к тому усилия.
Все-таки надо было их добавить, хотя бы в урезанном виде, в том же D тоже не осилили всего того, что предлагалось в C++0x,
но в результате все-равно очень мощная и симпатичная (практически развитие в сторону паттерн матчинга для шаблонов)
штучка получилась:
Здравствуйте, 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.
В конце концов, Уолтер Брайт — член плюсового комитета...
BulatZiganshin,
BZ>во-первых, это и есть в моём понимании RAII для Haskell. BZ>во-вторых, посмотри на стандартный bracket — он защищён от исключений
Да, спасибо, я подумал про это спустя некоторое время.
BZ>ну и главное — мы говорим о continuations, где это как раз нельзя использовать. почитай про монаду Cont.
Да, спасибо, сам догадался (тов. Klapaucius навёл на правильные мысли).
Здравствуйте, BulatZiganshin, Вы писали:
BZ>а, я понял, вы под системными тредами понимаете сделанные без continuations? тошда ответ такой — семантика другая. разберитесь наконец в существе вопроса вместо теоретических рассуждений о неизвестном вам предмете
Мощное заявление. Стоило бы подкрепить фактами, особенно рассуждая о семантике нереализованной и неизвестной вам библиотеки потоков. :)
Здравствуйте, jamesq, Вы писали:
J>А самое главное, чтобы была бы свободная возможность работать с таким полем, как с любым другим полем.
А ничего, что это "всего лишь навсего" нарушение инкапсуляции? Думается что нынешняя ситуация и идеологически и семантически корректная.
За инициализацию объекта должен отвечать сам объект, а не кто-то там.
J>Программист должен самостоятельно обеспечить валидность объекта этот момент, <skip>
— добавив ему конструктор по умолчанию! Кстати, компилятор именно это и говорит
Ну вы даёте... Вы, наверно, смерти желаете С++? Я за молодостью лет не застал язык PL/1, но пишут, что он умер от того, что в нем слишком много всего было.
Вы хотите, чтобы нужно было постоянно держать в голове тысячу особенностей?
Вы хотите, чтобы ежедневное программирование по сложности стало каким-то таким
Название после цикла? Тут нет проблем. Цикл на три страницы — вот это проблема.
Много вложенных циклов? Так избавьтесь от них. Сделайте функцию, а в ней 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++ его и так уже догнал
_>Вы хотите, чтобы нужно было постоянно держать в голове тысячу особенностей? _>Вы хотите, чтобы ежедневное программирование по сложности стало каким-то таким
Нет наоборот, чтобы такого не было языку шаблонов не хватает выразительности, чтобы хватало нужно совсем немного добавить, новый стандарт делает правильные, но слишком робкие шаги. Например в том же D в шаблоны уже добавлено практически все что нужно, и писать на шаблонах там на порядок проще чем в C++ и например весь ужас из твоей ссылки заменится простой compile time функцией.
_>Название после цикла? Тут нет проблем. Цикл на три страницы — вот это проблема. _>Много вложенных циклов? Так избавьтесь от них. Сделайте функцию, а в ней return. Сделайте ее inline.
_>Ну а в редких случаях (типа обработки n-мерных массивов) поставьте goto. И комментарии. Один оператор goto в пределах функции 50 — 100 строк не испортит вашу карму. И да не падёт на вас проклятье Дийкстры.
Выход из цикла в D стиле ничего ни добавляет лишнего, все просто и прозрачно и карма не страдает совсем
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, _nn_, Вы писали:
__>>Мне хотя бы constexpr и возможность манипулировать строками (массивами) во времени компиляции.
__>>
__>>const int hash_abc = hash("abc"); // compile time :)
__>>
Здравствуйте, _nn_, Вы писали:
J>>В смысле? Тут надо in_place_factory юзать (если я правильно помню название)
__>Вопрос как надо юзать?
если я правильно помню (под рукой нет документации), у boost::optional просто есть оператор присваивания, который принимает фабрику. Так что в момент присваивания она все там и создаст.
Поправь, если не так.
__>noncopyable в boost::optional
Здравствуйте, dmitry_npi, Вы писали:
_>Ну вы даёте... Вы, наверно, смерти желаете С++? Я за молодостью лет не застал язык PL/1, но пишут, что он умер от того, что в нем слишком много всего было.
На самом деле, нет. Он ушёл в прошлое вместе с Большими Машинами (tm). Просто в нём было много такого, что не требовалось в языках а-ля C. Например, механизм определения типа переменной по имени. То есть фич-то было много, но на практике они были скорее странными, чем сильно необходимыми. А так, чего там, есть (были, во всяком случае, сейчас лень искать) компиляторы PL/M и для PC.
P.S.: Хотя... Вот, для IBM zSeries, наверное, есть PL/1, который не подозревает о том, что он уже прошлое.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
_>>Ну вы даёте... Вы, наверно, смерти желаете С++? Я за молодостью лет не застал язык PL/1, но пишут, что он умер от того, что в нем слишком много всего было.
ГВ>А так, чего там, есть (были, во всяком случае, сейчас лень искать) компиляторы PL/M и для PC.
pl/m к этой избыточности отнощшения как раз не имеет, это язык на уровне C