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

J>Недостатки описанных подходов:
J>В первых двух вариантах, память для вынесенного по указателю поля объекта оказывается в стороне от участка
J>памяти с самим объектом, что при обращении к полю создает проблемы с кэшированием. Дополнительно, появляются
J>проблемы с фрагментацией памяти. Понятно, что лучше один большой учаток памяти на объект и поле в нем, чем два
J>отдельных.

J>Во всех вариантах, которые мне приходят в голову, есть еще один недостаток — весь доступ к вынесенному полю
J>идет через указатель.

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

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

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

>>Я, собственно, потому и удивился, что он как-то невнятно изъясняется.
BZ>в смысле?

Вот это: "compile-time dynamic typing". Было бы еще понятно, если бы "compile-time duck typing" написали. А вообще это называется structural typing.

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

D>Ну так выход — не использовать локальные объекты, подлежащие уничтожению, в таких блоках.

Ну конечно. Крайне полезное нововведение для C++ получается.

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

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

Сразу скажу что мне не хватает странного
Точнее не то чтобы не хватает, но я бы использовал в паре мест такую фичу: было бы круто делать switch на enum, который выдавал бы ошибку компиляции, если case'ами покрыты не все значения enum. Какой нибудь strict_switch.

typedef enum {One, Two, Three} MyEnum_type;
MyEnum_type value;
strict_switch(value)
{
case One:
     //.... 
     break;
case Two:
     //....
}  // <-------- error, case Three not handled

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

L>Сразу скажу что мне не хватает странного
L>Точнее не то чтобы не хватает, но я бы использовал в паре мест такую фичу: было бы круто делать switch на enum, который выдавал бы ошибку компиляции, если case'ами покрыты не все значения enum. Какой нибудь strict_switch.

Я наверно уже всех подзадолбал но в D есть:

enum MyEnum_type { One, Two, Three };

void main()
{
    
    MyEnum_type value;
    
    final switch(value)
    {
    case MyEnum_type.One:
         //.... 
         break;
    
    case MyEnum_type.Two:
         //....
    } 
}

Не скомпилируется с такой ошибкой:

fghhghj.d(8): Error: enum member Three not represented in final switch

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

K>Ну конечно. Крайне полезное нововведение для C++ получается.

Да. Позволяющее написать например библиотеку легковесных потоков, а-ля Эрланг, распределяющиеся между несколькими реальными тредами.

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

D>Да. Позволяющее написать например библиотеку легковесных потоков, а-ля Эрланг, распределяющиеся между несколькими реальными тредами.

Библиотеку потрясающе полезных легковестных потоков, внутри которых нельзя использовать RAII. Отличная идея.

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

D>написать библиотеку легковесных потоков.

Для этого, кстати, полноценные продолжения и не нужны.

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

K>Библиотеку потрясающе полезных легковестных потоков, внутри которых нельзя использовать RAII. Отличная идея.

Разумеется, внутри потоков можно использовать RAII.

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

C>1. break [what]; continue [what];
C>возможность делать break(и continue) из любого скоупа, а не только цикла. Плюс параметризировать.
C>число говорит сколько скоупов оборвать, а назавание цыкла говорит какой первый встречающийся цикл оборвать. Через запятую перечисление последовательных обрывов.

Именованные блоки, вот такие:

if(x>0) IfPositiveX 
{
  while(i != 10) MainIndexLoop
  {
    for(k=0; k<100; k++) PrepareSpecialDataLoop 
    {
      // ...
      // вот так
      if(condition1) break MainIndexLoop;
      // ...
      // или даже так
      if(condition2) break IfPositiveX;
    }
  }
}

Заодно код станет понятнее

Может наоборот ? Что убрать из языка?

К огромному моему сожалению , убрать из языка намного сложнее (на порядки) чем добавить. И почти не реально убрать что то не теряя совместимость.

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

K>>Библиотеку потрясающе полезных легковестных потоков, внутри которых нельзя использовать RAII. Отличная идея.

D>Разумеется, внутри потоков можно использовать RAII.

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

BulatZiganshin,

МС>>Там, ЕМНИП, не простой текстовый препроцессор, а полноценная компайл-тайм логика. в D есть отголосок — компайл-тайм функции.

BZ>новое — это хорошо разрекламированное старое синтаксические макросы хорошо известны с 60-х, как и их недостатки

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

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

Если речь идёт об отладке сгенерированного кода, то нужен аналог macroexpand-1 (которого кстати нет в C++ и не придвидится). А ходить по шагам в макросе в общем случае (мне кажется) не получится, поскольку самих шагов нет: ведь макрос может строить не только тела функций, а например типы, сами функции вместе с сигнатурами, и вещи типа infixl/infixr. То есть декларативный код, который сгенерирован макросом, вряд ли может быть проверен пошагово, даже если это супер-пупер дебаггер.

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

Однако в последнее время здесь (то есть в исследовании свойств метапрограмм с побочными эффектами) наметился прогресс:
Shifting the Stage: Staging with Delimited Control, работа 2009 года. (Олег Киселёв форева).

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

BulatZiganshin,

K>>>А как совмещать продолжения и RAII?

VD>>GC

BZ>gc не заменяет raii, поскольку не гарантирует вызов деструктора в детерминированный момент времени

RAII не нужен:

bracket :: IO a -> (a -> IO b) -> (a -> IO c) -> IO c
bracket acquire release action = 
  do handle <- acquire
     result <- action handle
     release handle
     return result

и не нужны никакие гарантии никаких мусорщиков. Только FCO

Klapaucius,

VD>>GC

K>Ну ладно, отказались мы от детерминированного освобождения памяти. Тут я не против. Ну а как быть с детерминированным освобождением остальных ресурсов? Продолжения делают любое детерминированное освобождение невозможным — т.е. любой аналог using тоже работать не будет.

Кстати, а флаг isDisposed перед release не поможет? (для bracket, using и аналогов)

Lazy Cjow Rhrr,

LCR>Кстати, а флаг isDisposed перед release не поможет? (для bracket, using и аналогов)

Поможет, но при условии, что этот флаг не будет захватываться в продолжение. Мда.

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

LCR>RAII не нужен:
LCR>

LCR>bracket :: IO a -> (a -> IO b) -> (a -> IO c) -> IO c
LCR>bracket acquire release action = 
LCR>  do handle <- acquire
LCR>     result <- action handle
LCR>     release handle
LCR>     return result
LCR>

LCR>и не нужны никакие гарантии никаких мусорщиков. Только FCO

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

ну и главное — мы говорим о continuations, где это как раз нельзя использовать. почитай про монаду Cont

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

BZ>в continuations использовать RAII нельзя. а потоки — это только частный случай их применения, поэтому там RAII использовать тоже нельзя, если только вы нне собираетесь делать отдельный анализатор того, как используется библиотека :)

Т.е. например в системных тредах нельзя использовать RAII? А если можно — почему нельзя использовать в пользовательских потоках, сделанных на продолжениях и обладающей такой же семантикой?

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

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

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

D>Т.е. например в системных тредах нельзя использовать RAII? А если можно — почему нельзя использовать в пользовательских потоках, сделанных на продолжениях и обладающей такой же семантикой?

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

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

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

>Т.е. например в системных тредах нельзя использовать RAII? А если можно — почему нельзя использовать в пользовательских потоках, сделанных на продолжениях и обладающей такой же семантикой?

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