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

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

__>

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

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

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

C>1. break [what]; continue [what];

Очень редко есть такая необходимость при современном подходе писать множество мелких функций, а тем более при наличии lambda expression.

C>2. ключевое слово loop (или любое другое имеющее такую же функциональность)

Не нужно, уже есть {}

C>3. goto case; как в C#

Не нужно. switch практически используется очень редко.


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

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

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

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

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



C>>2. ключевое слово loop (или любое другое имеющее такую же функциональность)

GN>Не нужно, уже есть {}

какая связь?

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

C>Скажу чего мне нехватает

Этот список больно поход на описание возможностей Ada

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

BZ>compile-time dynamic typing

Мне одному кажется, что это оксюморон?

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

BZ>>compile-time dynamic typing

K>Мне одному кажется, что это оксюморон?

compile-time dynamic typing of types. я вроде описал в чём он заключается

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

__>>

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

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

Это, скорее, свидетельство того, что было бы желательно, если бы компилятор вычислял все, что можно вычислить на этапе компиляции. Т.е. если все данные для ф-и hash известны на этапе компиляции, как в данном случае — она на этом этапе и вычисляется. Если данные не известны — на этапе выполнения. А в чем удобство вводить разные сорта ф-ий для этапа компиляции и выполнения не понятно.

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

C> или расскажите чего нехватает вам.

1. Нормальных локальных функций.
2. Блоки-как-выражения.
3. Продолжения (вроде POSIX setcontext/getcontext, только не такие уродливые)

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

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

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

K>Это, скорее, свидетельство того, что было бы желательно, если бы компилятор вычислял все, что можно вычислить на этапе компиляции. Т.е. если все данные для ф-и hash известны на этапе компиляции, как в данном случае — она на этом этапе и вычисляется. Если данные не известны — на этапе выполнения.

А что делать с побочными эффектами, которые могут иметь место в процессе выполнения?

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

BZ>я вроде описал в чём он заключается

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

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

S>А что делать с побочными эффектами, которые могут иметь место в процессе выполнения?

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

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

D>3. Продолжения

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

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

C>1. break [what]; continue [what];

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

do statement while ( expression ) ;

на

do statement while ( expression ) statement

и получаем возможность вместо

    for(;;) {
        . . .
        if ( . . . )
            break;
        . . .
    }

писать

    do {
        . . .
    } while ( . . . ) {
        . . .
    }

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

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

__>>>

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

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

K>Это, скорее, свидетельство того, что было бы желательно, если бы компилятор вычислял все, что можно вычислить на этапе компиляции. Т.е. если все данные для ф-и hash известны на этапе компиляции, как в данном случае — она на этом этапе и вычисляется. Если данные не известны — на этапе выполнения. А в чем удобство вводить разные сорта ф-ий для этапа компиляции и выполнения не понятно.

У компиляторов не хватает на это мозгов. Приходится помогать ручками.

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

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

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

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

Большинству программистов нафик не брякало использовать boost::mpl и прочую шаблонную магия. Но библиотеками написанными с их помощью пользуются многие с большим удовольствием.

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

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

C>> или расскажите чего нехватает вам.

D>1. Нормальных локальных функций.
вот так ?

int main()
{
  for (int i = 0; i < 4; i++)
  {
    auto eq = [&i]-> bool (int x) 
    { 
      //...
    };
    if (eq(2))
    {
    }
  }
}

D>2. Блоки-как-выражения.
вот так ?

int main()
{
  for (int i = 0; i < 4; i++)
  {
    auto eq = [&]-> bool (int x) 
    { 
       //...
    }(2);
  }
}

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

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

__>>>

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

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

K>Это, скорее, свидетельство того, что было бы желательно, если бы компилятор вычислял все, что можно вычислить на этапе компиляции. Т.е. если все данные для ф-и hash известны на этапе компиляции, как в данном случае — она на этом этапе и вычисляется. Если данные не известны — на этапе выполнения. А в чем удобство вводить разные сорта ф-ий для этапа компиляции и выполнения не понятно.

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

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

M>Функции этапа компиляции

общепринятый термин — метапрограммирование

Здравствуйте, Caracrist,

string s;
ifstream fin("1.txt");
{
/*loop*/ istringstream iss;
/*loop*/ string s2; // эти переменные объявленны тут только для читабельности,
// их реальное место за пределами цикла, но при этом нет никакой причины чтобы они были бы там видны...
  while (getline(fin, s)) // читаем по строкам
  {
    iss.str(s);
    while (iss >> s2) // читаем прочитанную строку по словам
    {
       if (/*some condition*/)
       {
           continue while, while; // :) goto nextLine;
       }
       //...
    }
  nextLine:
  }
}

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

if ( ... )
{
  loop lock_t lock(m_mutex);
  for (;;)
  {
     if (not time to begin changes)
       continue;
  }
}

Было

for (;;)
{
   if (not time to begin changes)
     continue;
   loop lock_t lock(m_mutex);
   // допустим что все изменения в данном цикле должные делаться под одним замком, 
   // однако нет никакой причины закрывать его заранее - и нельзя, т.к. иначе изменения будут под разными замками
   
   // а какие причины держать лок дольше чем надо???
   // если условия взятия лока не должны быть защищены этим локом,
   // их можно безопасно вынести за цикл по тем же самым причинам
}