Текущий Стандарт С++ и перспективы его развития

Цитата Flex Ferrum @ 30.07.17, 09:43

И это не макросы. Это именно что модификация AST. AST in, AST out.

Ну так нормальные макросы(а не препроцессор) этим и должны заниматься.

О! Они наконец то выложили это!
https://youtu.be/6nsyX37nsRs

Цитата Flex Ferrum @ 30.07.17, 09:43

И это не макросы. Это именно что модификация AST. AST in, AST out.

В нормальных современных языках это называется макросы. А в плюсах да, макросы - это препроцессор.

Цитата Flex Ferrum @ 30.07.17, 09:43

И это не макросы. Это именно что модификация AST. AST in, AST out.

Макросы в расте - примерно то же самое

Столкнулся с любопытным ограничением Стандарта. Нужно явно вызвать деструктор объекта, чей класс определён в области видимости пространства имён, отличного от текущего, и там же заtypedef-ен. Оказывается, без using этого достичь нельзя, что с моей точки зрения является дефектом Стандарта.
Конкретная задача возникла следующим образом. Потребовалось уметь создавать потоки ввода/вывода на файлах, открытыми кастомным образом посредством ОС API. Стандартных средств для этого пока нет, хотя потуги в направлении std::filesystem вроде бы наличествуют. На данный момент остаётся только пользоваться расширениями STL под конкретную платформу. Под WinAPI это к примеру некий подобный код:

    HANDLE        file;
    FILE         *fFile;
    std::filebuf  inFile
    int           handle;
 
    file = CreateFile(pat.second.c_str(), GENERIC_READ | FILE_WRITE_ATTRIBUTES, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_FLAG_SEQUENTIAL_SCAN, NULL))
    if (file == INVALID_HANDLE_VALUE) /* ... */
 
    /* этот костыль нужен, т.к. создать inFile прям тут по месту невозможно: он нужен за пределами этой области видимости, поэтому создан ранее дефолтовым конструктором */
    /* можно было бы – и нужно было бы – использовать std::filebuf::open() вместо конструктора, если бы он был, однако увы, расширение STL поддерживается только конструктором */
    inFile.~filebuf();         // ошибка компиляции
    new(&inFile) std::filebuf(fFile = fdopen(handle = _open_osfhandle(reinterpret_cast<intptr_t>(file), _O_RDONLY), "rb"));

Если не использовать using std::filebuf; где-нибудь выше, то тут компилятор не находит имени filebuf, т.к. в области видимости inFile есть только полностью квалифицированное basic_filebuf<char>, а filebuf найден не будет, и любые попытки внести std:: в это выражение нарушают синтаксис явного вызова деструктора. Зато с использованием using этот самый filebuf прекрасно находится.
Кто что думает по сему поводу? Дефект али нет?

Сообщение отредактировано: Qraizer - 08.11.17, 19:19

Цитата Qraizer @ 08.11.17, 19:09

Нужно явно вызвать деструктор объекта, чей класс определён в области видимости пространства имён, отличного от текущего, и там же заtypedef-ен. Оказывается, без using этого достичь нельзя, что с моей точки зрения является дефектом Стандарта.

Покажи плс синтетический вариант. По твоему куску кода непонятно.

Присоединяюсь к комментатору выше.

А что тут непонятного? std он везде std, std::basic_filebuf<> вполне себе стандартен и везде одинаковый, его typedef basic_filebuf<char> filebuf; известен ещё в C++98. Ну нате.

namespace N
{
  struct MyClass { ~MyClass() {} };
 
  typedef MyClass A;
}
 
void f()
{
  N::A a;
 
  a.~MyClass();         // имя находится, т.к. имена классов вносятся в их область видимости
  a.~A();               // имя не находится, т.к. при обработке операций . и -> (а также :: внутри скопа классов), компилятор наружу, в область видимости окаймляющего пространства имён, не выходит
  a.N::A::~A();         // был неправ, сразу не сообразил, но вот так достучаться можно...
  a.N::~A();            // ...а вот так нельзя
}

Итак, дефект или не дефект? Прежде чем определиться с ответом, предлагаю домашнее задание: почему компилится третья строчка?

Сообщение отредактировано: Qraizer - 09.11.17, 03:32

Упрощенный вариант

struct MyClass {};
 
int main() {
  MyClass c;
  c.::~MyClass();        // почему не компилиться эта строчка?
  c.MyClass::~MyClass(); // а эта строчка норм
  return 0;
}

А что если в Си добавить конструкцию, чтобы стали допустимы записи вида:

#defines
 A B
 C 42
 ...
 P Q
#enddef // или enddefs

?
Это сократило бы исходники, и читать немножко легче стало бы...

Небольшой список вкусняшек из нового стандарта.
https://usingstdcpp.org/2018/03/18/jacksonv...impression=true

Цитата Славян @ 11.03.18, 14:39

А что если в Си добавить конструкцию, чтобы стали допустимы записи вида:

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

Цитата Славян @ 11.03.18, 14:39

А что если в Си добавить конструкцию, чтобы стали допустимы записи вида:

Цитата Mr.Delphist @ 19.03.18, 21:29

Это настолько сахар для синтаксиса, что прямо ой.

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

Цитата amk @ 19.03.18, 23:57

кусок текста, который непонятно что означает (если не видно скобок)

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

Цитата amk @ 19.03.18, 23:57

это ничего нового не даёт

Прямо ж написано!:

Цитата Славян @ 11.03.18, 14:39

Это сократило бы исходники, и читать немножко легче стало бы...

Цитата Славян @ 20.03.18, 01:22

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

Ну если ты в комментариях бессмыслицу пишешь, то конечно.

Цитата Славян @ 20.03.18, 01:22

Прямо ж написано!:

Добавление двух дополнительных строк текста конечно же сильно сокращает исходники.

У тебя что, каждая единица трансляции в чистом Си начинается с пары страниц макроопределений?
Да и поздно уже такое изменение вносить. Вот в году 1970-м возможно его и приняли бы.