На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
Модераторы: Qraizer, Hsilgos
Страницы: (77) « Первая ... 72 73 [74] 75 76 ... Последняя »  ( Перейти к последнему сообщению )  
> Текущий Стандарт С++ и перспективы его развития
    Цитата Flex Ferrum @
    И это не макросы. Это именно что модификация AST. AST in, AST out.

    Ну так нормальные макросы(а не препроцессор) этим и должны заниматься.
      О! Они наконец то выложили это!
      https://youtu.be/6nsyX37nsRs
        Цитата Flex Ferrum @
        И это не макросы. Это именно что модификация AST. AST in, AST out.
        В нормальных современных языках это называется макросы. А в плюсах да, макросы - это препроцессор.
          Цитата Flex Ferrum @
          И это не макросы. Это именно что модификация AST. AST in, AST out.

          Макросы в расте - примерно то же самое :)
            Столкнулся с любопытным ограничением Стандарта. Нужно явно вызвать деструктор объекта, чей класс определён в области видимости пространства имён, отличного от текущего, и там же заtypedef-ен. Оказывается, без using этого достичь нельзя, что с моей точки зрения является дефектом Стандарта.
            Конкретная задача возникла следующим образом. Потребовалось уметь создавать потоки ввода/вывода на файлах, открытыми кастомным образом посредством ОС API. Стандартных средств для этого пока нет, хотя потуги в направлении std::filesystem вроде бы наличествуют. На данный момент остаётся только пользоваться расширениями STL под конкретную платформу. Под WinAPI это к примеру некий подобный код:
            ExpandedWrap disabled
                  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 -
              Цитата Qraizer @
              Нужно явно вызвать деструктор объекта, чей класс определён в области видимости пространства имён, отличного от текущего, и там же заtypedef-ен. Оказывается, без using этого достичь нельзя, что с моей точки зрения является дефектом Стандарта.

              Покажи плс синтетический вариант. По твоему куску кода непонятно.
                Присоединяюсь к комментатору выше.
                  А что тут непонятного? std он везде std, std::basic_filebuf<> вполне себе стандартен и везде одинаковый, его typedef basic_filebuf<char> filebuf; известен ещё в C++98. Ну нате.
                  ExpandedWrap disabled
                    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 -
                    Упрощенный вариант :lol:

                    ExpandedWrap disabled
                      struct MyClass {};
                       
                      int main() {
                        MyClass c;
                        c.::~MyClass();        // почему не компилиться эта строчка?
                        c.MyClass::~MyClass(); // а эта строчка норм
                        return 0;
                      }
                      А что если в Си добавить конструкцию, чтобы стали допустимы записи вида:
                      ExpandedWrap disabled
                        #defines
                         A B
                         C 42
                         ...
                         P Q
                        #enddef // или enddefs
                      ? :unsure:
                      Это сократило бы исходники, и читать немножко легче стало бы... :oops:
                        Небольшой список вкусняшек из нового стандарта.
                        https://usingstdcpp.org/2018/03/18/jacksonv...impression=true
                          Цитата Славян @
                          А что если в Си добавить конструкцию, чтобы стали допустимы записи вида:

                          Это настолько сахар для синтаксиса, что прямо ой. Плюс не забываем про многострочные макросы с переносом строки \
                            Цитата Славян @
                            А что если в Си добавить конструкцию, чтобы стали допустимы записи вида:
                            Цитата Mr.Delphist @
                            Это настолько сахар для синтаксиса, что прямо ой.
                            Кроме того, что это ничего нового не даёт, такая запись ещё и несколько сбивает с толку - получается кусок текста, который непонятно что означает (если не видно скобок)
                              Цитата amk @
                              кусок текста, который непонятно что означает (если не видно скобок)
                              Многострочный комментарий обладает абсолютно таким же "изъяном", - однако, он существует и успешно используется! <_<

                              Цитата amk @
                              это ничего нового не даёт
                              Прямо ж написано!:
                              Цитата Славян @
                              Это сократило бы исходники, и читать немножко легче стало бы...
                                Цитата Славян @
                                Многострочный комментарий обладает абсолютно таким же "изъяном", - однако, он существует и успешно используется!
                                Ну если ты в комментариях бессмыслицу пишешь, то конечно.
                                Цитата Славян @
                                Прямо ж написано!:
                                Добавление двух дополнительных строк текста конечно же сильно сокращает исходники.

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


                                Рейтинг@Mail.ru
                                [ Script execution time: 0,0947 ]   [ 17 queries used ]   [ Generated: 19.03.24, 03:40 GMT ]