Oberon space

Не похоже:

8.1.8 Pointer types

All pointers in Rust are explicit first-class values. They can be copied, stored into data structures, and returned from functions. There are four varieties of pointer in Rust:
Managed pointers (@)

These point to managed heap allocations (or "boxes") in the task-local, managed heap. Managed pointers are written @content, for example @int means a managed pointer to a managed box containing an integer. Copying a managed pointer is a "shallow" operation: it involves only copying the pointer itself (as well as any reference-count or GC-barriers required by the managed heap). Dropping a managed pointer does not necessarily release the box it points to; the lifecycles of managed boxes are subject to an unspecified garbage collection algorithm.
Owning pointers (~)

These point to owned heap allocations (or "boxes") in the shared, inter-task heap. Each owned box has a single owning pointer; pointer and pointee retain a 1:1 relationship at all times. Owning pointers are written ~content, for example ~int means an owning pointer to an owned box containing an integer. Copying an owned box is a "deep" operation: it involves allocating a new owned box and copying the contents of the old box into the new box. Releasing an owning pointer immediately releases its corresponding owned box.
Borrowed pointers (&)

These point to memory owned by some other value. Borrowed pointers arise by (automatic) conversion from owning pointers, managed pointers, or by applying the borrowing operator & to some other value, including lvalues, rvalues or temporaries. Borrowed pointers are written &content, or in some cases &f/content for some lifetime-variable f, for example &int means a borrowed pointer to an integer. Copying a borrowed pointer is a "shallow" operation: it involves only copying the pointer itself. Releasing a borrowed pointer typically has no effect on the value it points to, with the exception of temporary values, which are released when the last borrowed pointer to them is released.
Raw pointers (*)

Raw pointers are pointers without safety or liveness guarantees. Raw pointers are written *content, for example *int means a raw pointer to an integer. Copying or dropping a raw pointer is has no effect on the lifecycle of any other value. Dereferencing a raw pointer or converting it to any other pointer type is an unsafe operation. Raw pointers are generally discouraged in Rust code; they exist to support interoperability with foreign code, and writing performance-critical or low-level functions.

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

const — указатель не изменяемый, инициализация по месту объявления или в качестве аргумента функции;
no_addr — запрещает применение операции получения адреса к указателю; Используется для повышения возможностей оптимизатора.
auto_deref — упоминание идентификатора указателя равнозначно его разыменованию на месте "(*p)". Включает в себя no_addr. Для установки значения самого указателя используется специальный синтаксис (ключевое слово let, инициализация при объявлении в С++, аргумент функции);
fragile — "ломкий". Указатель на данные подлежащие скорому удалению. Семантика перемещения в С++;
not_null — гарантированно указывает на данные, проверка времени компиляции;
null_guard — проверка на неравенство нулевому указателю во время исполнения (в аргументах функций, при присвоении указателей без атрибута null_guard или not_null).

Теперь составим известные нам типы указателей из Ады, Паскаля, Оберона и С++ (pointer — просто указатель):

1) Указатель, к которому нельзя применить операцию взятия адреса:
typedef no_addr pointer ptr;
int x;
int ptr px = &x; // px = @x
&px // error
*px = 7; // можно оптимизировать до x = 7, px выбросить вообще
2) Автоматически разыменовываемый указатель
typedef auto_deref pointer ref;
int x;
int ref px; // px = @???
px = 1; // possible run-time crash
let px = &x; // px = @x
px = 1; // x = 1
3) Гарантированно указывающий на что-либо указатель
typedef not_null pointer ptr;
int x, y;
int ptr p; // compile time error
int ptr p = &x; // p = @x
p = &y; // p = @y
*p = 1; // y = 1
4) Гарантированно ненулевой указатель, проверка времени исполнения
typedef null_guard pointer ptr;

void Test (int ptr p) {}
iTest(nullptr); // run-time error
5) Семантика перемещения — функция принимает аргументом указатель на объект, который будет следом удалён
typedef fragile pointer ptr;
void Test (TObject ptr obj) {}
int *p = new int();
Test(p);
delete p;
6) VAR-параметр Оберона, Паскаля, Ады
typedef const auto_deref not_null pointer var;
procedure Test (var x: integer);
Test(1); // compile-time error
Test(x); // ok
Test(p^); // ok if p is pointer to integer
7) not null аргумент Ады, проверка времени исполнения
typedef not_null pointer ptr;
procedure Test (x: ptr integer);
Test(nil); // compile-time error
Test(@x); // ok
Test(p); // ok
8) Классические ссылки в С++
typedef const not_null auto_deref pointer &;
Примечание: возможность иметь ссылки на константы или возвращаемые по значению объекты есть синтаксический сахар, который можно с тем же успехом применить к любым пользовательским указателям в новой модели:

const int* p = 1; // p = @c1, c1 is const int, c1 = 1
TObject Test () {}
TObject* obj = Test(); // obj = @local1, local1 is TObject, @local1 передаётся функции теневым аргументом
Что думаете, господа?

Соберётся, если писалось с использованием общей части языка (в большей степени равняются на Delphi). В VirtualPascal есть режим Делфи (не полный) и в FreePascal тоже. Я переносил свои программы между тремя. А суть в следующем: PACKED для структур во всех трёх обеспечивает alignas(1), STDCALL/CDECL/THISCALL и т.д. — правильное соглашение о вызове для функций. Паскаль не приветствует сложных кодирований расширений, вроде __xxxxx(yyy(__zzz)), поэтому есть определённое единообразие.

Это просто констатация факта, а не нападки на С++.

Если перевести на русский: до 2011 года в С++ выравнивания не было (как и массы других вещей). А как следствие, в 99% существующего кода не используется. Хорошо, что добавили, но никого не волнует скорость выхода стандартов С++. Важно, сколько лет функциональности не было и когда она появилась.

Нужно написать системный модуль с процедурой: PtrToInt. Для любой конечной платформы понадобится изменить только её.

Очень повеселило, спасибо.

valexey_u, десятилетия и тонны софта до версии С++11х, так что это не показатель. То же самое и с новыми типами вроде int32_least_t, они нигде не используются, а нужно, чтобы весь код был с их применением.

Возможно специалисты прояснят мне мои смутные сомнения.
Тезис заключается в следующем: ANSI C++ ни разу не кроссплатформенен. Фактически, даже простейшие вещи, вроде соглашения о вызове или экспорта/импорта функций и переменных из динамических модулей нет. Без них нельзя, фактически, ничего. Сюда же отнесём пути в заголовочных файлах (include "путь, специфичный для ОС"), выравнивание данных (как описать универсально структуру с точностью до байта).

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

По поводу юниковых утилит для сборки. Разве не рудимент, что большинство из них не хочет понимать пути с пробелами/русскими символами? Или это только в окружении Windows такая проблема? У меня отваливаются самые разные программы на С++ при неудобном для них местоположении, даже Notepad++.

В юниксах отказались от реестра, но в результате имеем реестр в виде переменных окружения, необходимость прописываться в них, альтернативные пути папок с бинарниками и заведомую зависимость одной утилиты от прописанных в таком «реестре» десятка других программ. При переносе на Окна приходится каждую прописать в системный PATH, иначе что-то отваливается.

Можно возразить, что альтернативы нет: либо централизованный общий реестр, либо ручное редактирование переменных окружения. Но реестр понадёжнее будет, на мой взгляд. В реестре если ключу "git" соответствует конкретный путь, то повторная установка его попросту перепишет. С переменными окружения хуже. Дубликаты путей к папкам, пути с различным регистром.