Это число N. Численное представление адреса в памяти объекта типа T должно быть кратно этому числу N. Мы можем запросить как меньшее, так и большее выравнивание.


Ага.




На некоторых платформах можно огрести Bus error/SIGBUS/SIGSEGV/etc в случае, если попытаться считать данные по невыровненному адресу.
Опять же, на некоторых системах это равносильно AV.
К примеру, RISC процессоры этим "страдают".
У x86 такое ограничение, ЕМНИП, только на атомарные операции(lock префикс перед операцией). Дело в том, что считывание 4-х байт по адресу некратному 4-м - операция, сбивающая процессор(любой) с толку. Просто x86 делает это очень медленно, а некоторые этого делать просто неумеют(и слава Б-гу) и генерируют аппаратное исключение(точно такое же прерывание, просто с предопределённым для него номером). Исключений, к примеру, генерируются ещё в случаях, когда процесс обращается к памяти, которая в свопе(page fault), но их обрабатывает ОС.

Так. Хорошо.
Допустим мы имеем тот самый RISC с кратностью 4. Тогда, чему равны alignof(char), alignof(short), alignof(int)? Думаю, что 4. В таком случае операция: должна разместить var в 4-х байтах. Тогда какой толк от этого всего? Или предполагается, что я должен буду явно указывать допустимую для архитектуры размерность?

bsa, у char на любых платформах выравнивание 1.


Не пойму, зачем так писать? То же самое, что написать

Добавлено через 3 минуты и 29 секунд
Народ, если кому интересно, то вот продолжения обзора:
Стандартная библиотека C++09
Чего НЕ будет в С++09
TR1. Technical Report on C++ Library Extensions

Сюда это копипастить проблематично из-за ограничений форума на максимальную длину сообщения.

Вот именно. Тогда какой смысл в это alignof/alignas? Если можно дай пример, в котором это отображается.

Это сообщение отредактировал(а) bsa - 19.6.2007, 21:45

При чем тут lock? Генерация #AC включается установкой AM в CR0 и AC в EFLAGS

Добавлено @ 22:37

наверное так

хотя тут можно было написать просто long a

Это сообщение отредактировал(а) MAKCim - 19.6.2007, 22:46

Я давно от низкоуровнего программирования отошёл... спасибо за поправку.



Точно не знаю, но вполне возможно, что по стандарту не будет противоречить случай alignof(int) > alignof(long). Это во-первых.

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

хм, это будет по меньшей мере странно
сомневаюсь вообщем

не знаю, мне кажется, что С++ слишком высокоуровневый, чтобы вводить в стандарт такие вещи как выравнивание, другое дело С

Добавлено через 5 минут
archimed7592, 
кстати, typeof() будет в новом стандарте?

только по  другому называться будет.

Во-первых, большое спасибо archimed7592 за качественную работу по переработке материала и отличный обзор  


Ну - как скажите  Выскажу своё отношение ко всему этому делу.


В связи с этим хотелось бы ещё и нормальные тиипобезопасные переменные параметры функций. Поюсню примерный синтаксис и реализацию.


Фактически, objects - какой-нибудь STL-контейнер: container_template<MyClass*>. Можем опционально задать container_template (в том числе и свой):


По умолчанию используется, например, std::vector.

При каждом конкретном вызове компилер генерит один из двух кодов:


Тип контейнера определяем с помощью концепций (если формально удовлетворяет в обе ктаегории - то пожалуй, отнесём к первой).

Неплохо также разрешить такой код:

При этом будет использоваться некоторый стандартный шаблон-обёртка над контейнером, с фактическим хранением указателей, и разыменованиями в нужных местах (front, back, operator [], at, итераторы).

Сам контейнер передаётся, конечно, (в любом случае) по константной ссылке.



Хотелось бы по конкретней узнать: будут ли специальные языковые конструкции для синхронизации (типа блок операций, выполняемых одновременно лишь в одном потоке)? Очень хотелось бы.



Судя по приведённому коду, гляжу и явное включение значений енумов в текущий контекст убрали (что, безусловно, хорошо). Однако, логично было бы ещё что-то типа:



Ещё что-то не заметил упоминания про final/sealed (как для классов, так и для методов). Тоже, нужная вещь.


<чуть позже допишу ещё>

Ничего не заметил ещё про столь обещаемые #push, #pop - для регулирования области видимости макросов.


Ещё - когда же мы получим инклюд без препроцессора?! Чтобы нормально разруливался дабл-инклюд (без лишних макросов + директив или же тем более компилерозависимых прагм). Чтобы после хейдера, в которым кто-то забыл закрывающую фигурную скобку поставить мы не видели непонятные ошибки в каждом третьем исходнике. И пр.

Вообще хотелось бы определить понятие "заголовочного файла". Ввести хейдер-компилер (отдельная утила или спецопция компилера - неважно), который бы генерил бы по хейдеру бинарный файл, оптимизированный (для данного компилера) для дальнейшей работы (будем его называть бинари-хейдером). Вообщем то обычные прекомпилед-хейдеры, ничего радикально нового. Для шаблонов - также генерится внутренний код (внашем бинари-хейдере), для методов с реализаций внутри объявления класса - сразу генерится файл объектного кода.

Встаёт проблема с порядком компиляции (или как сие назвать) заголовков. Лучшем решением (не единственным, впрочем) вижу всё-таки введения понятия сборки/проекта/etc.. Встроенная минимал билд-система в некотором роде. Но в разумном виде. Можно проще поступить - задать конкретное правило полчения имени бинари-заголовка из обычного. Но это отдельно подумать надо...

Необходимость понятия сборки - также из-за желания иметь аналог internal из шарпа. Плюс его же применять к нэймспейсам (+классам, енумам и пр., хотя это не так нужно - но для симетрии).

Ещё интересно было бы увидеть (но не так, чтоб прям сильно) ООП-шные енумы, так сказать. Типо енумов в Яве или вэриантов в Немерле.

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

честно говоря, для меня выглядит дико как-то...




тут +1.


тут по каждому пункту тоже +1.




а тут никакие стандарты уже не помогут. Слишком поздно. Раньше надо было (если вообще надо было) думать. У каждой ide своя система проектов, в Unix уже давным-давно с этим все выяснено, написано кучу утилит и программ, MS все равно плюнет на эту часть стандарта. Имхо, с этим заморачиваться просто бесполезно.

Помогут. Если разумно делать. Я ж не говорю про всю билд систему. А минимум. Более того - необязательно хранить в одном файле, можно разрулить по ходу по параметрам команд-лайна. В яве при компайле одного класса, скажем, если надо, скомпиляться все зависимые. Однако билд-системой это вряд ли можно назвать. Билд-система - это ant. С различными правилами, задачами и пр...


Вряд ли. Из серьёзных билд-систем MS поддерживает на сегодня 3 (!). Мэйкфайлы, файлы проектов (они работает как из гуи студии, так и команд-лайном) и нафиг не нужный MSBUILD.


Почему? Тем более, с каким-нибудь boost::any - по-моему очень неплохо получается  На сегодня многие используют возврат ссылки на самого себя из метода или оператора. Первое (скажем QString::arg) выглядит не супер, второе (например, boost::format) чуть лучше, но идеальней был бы обычный список параметров переменной длины. Просто сишные варарги в плюсах как-то не лепятся 

Не верю я. Даже если сделать разумно. Никто лишний раз ради переделки под будущий стандарт не будет переделывать мэйк-файлы, билд-системы и т.д. под новый стандарт.


для меня пока дико. Для тебя - нет. Это же все имхо.

Их не надо будет переделывать.

Что нам нужно:
1. Обеспечить среду для работы internal.
2. Разруливать зависимые друг от друга заголовки.

Для первого нужно знать - "свой" данный хедйер или нет. Тупой вариант - три варианта инклюда. Например:


Для второго - два варианта:
1. Иметь взаимооднозначное (но компилерозавсисимое) соответствие хейдер -- бинари-хейдер. Например: "class1.hpp" -> "class1.bhpp", "class1.h" -> "class1.bh". При нахождение инклюда и не нахождение соответствующего бинари-хейдера - тупо генерить его.
2. Передавать список хейдеров в команд-лайн. ИМХО даже хуже будет. Соответствия тяжелей задавать, лучше иметь неявные.

По-моему, всё реально.

А чем они принципиально отличаются? кроме путей?

Насчет бинари-хедеров - я бы за... но. Дороже, сложнее и дольше выйдет, как мне кажется. Спорить особо не буду - не пробовал ;).