Программируете ли вы на Паскале?

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

А я привёл пример, где они семантически очень разные, один контролирует лайфтайм объекта, другой нет. Итого: семантически они разные, даже если в некоторых случаях похожи. Референс - это алиас имени с наверченным расширением лайфтайма в определённых случаях, было бы странно, если алиас на пойнтер был бы семантически отличен от самого пойнтера.

A a;
A *p1 = new A;
A *p2 = &a;
Ф *з3 = new B[N];

вот еще один пример где аж три пойнтера и все семанитически разные. И?

У Вас с логикой таки беда-беда…

Референс - это алиас имени

И тут же, внимание:

с наверченным расширением лайфтайма в определённых случаях

«определённые случаи» - это исключительно «unnamed temporaries bound to the references». Шах и мат. Да, и ещё Вы implicit conversions забыли упомянуть допускающиеся при binding to the const-ref.

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

1,2 - не, обычно просто время меряю, масштабируя если надо и предприняв меры чтобы компилятор не выкинул код 3 - да 4 - да, графики не рисую 5 - редко

приведите пример математического кода.

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

Всякие умные указатели это дорогое удовольствие вообще то,

это только поточно безопасные дорогие, но я всё-таки про ссылки которые хороши тем что безопасны и быстры по умолчанию и за этим следит компилятор, а указательные и прочие УБ лежат большой когнитивной нагузкой на программисте. И самое главное - неопределённость наличия УБ, особенно если потенцальный источник УБ «размазан» по алгоритму; я пару раз натыкался на споры матерых плюсовиков, которые не могли определить есть ли в данном куске кода УБ, т.е. может быть совсем не одназначной задачкой, стандарт гигантский и мутный

1,2 - не, обычно просто время меряю, масштабируя если надо и предприняв меры чтобы компилятор не выкинул код 3 - да 4 - да, графики не рисую 5 - редко

спасибо, принято

сугубо математического, формульного вида функции которые сгружаются в оде солвер (если это моделирование), а массивы обычно в один уровень косвенности ( обработка сигналов)

сравните

... data[i].a*data[i].b+data[i].c ...

с

cell_t &C = data[i];
... C.a*C.b+C.c ...

только поточно безопасные дорогие

WTF «дорогие» в Вашем понимании? В моем понимании вот это

std::shared_ptr<A> ptr.reset(...); 
// или
std::shared_ptr<A> ptr = ...;

значительно дороже чем вот это

A* ptr = ...

потому что там лишние манипуляции со счетчиком как минимум. Я бы не стал бездумно пихать такое во все места. Где то это бывает оправдано конечно, чаще нет.

любой reference - это pointer присыпанный сахарком сверху

Я об этом и говорю, но товасчь категорически не согласен - у него в референсах только стековые значения, в пойнтерах только значения с кучи, и никак одно с другим не бьется… видимо религия такая.

Тут еще некая терминологическая путаница похоже - у zurg «ссылка» - это умный указатель, а «указатель» - это голый пойнтер. Если я ничего не напутал.

сравните ... data[i].a*data[i].b+data[i].c ...

с cell_t &C = data[i];

... C.a*C.b+C.c ...

А в случае

cell_t * P = &data[i];

мы могли бы попытаться вычислить ещё и

P[-1].a * P[0].b + P[+1].c 

Это только если data простой вектор, но так да.

Шах и мат.

Вы о чём?

любой reference - это pointer присыпанный сахарком сверху

В том-то и дело, что нет. А то многие доходят то того, что и массив в си - это «пойнтер, присыпанный сахарком».

у него в референсах только стековые значения, в пойнтерах только значения с кучи

Упрлс? Из пальца высосанное заявление.

Урлс на что? На Ваш идиотский пример?

Программируете ли вы на Паскале? (комментарий)

Шах и мат.

Вы о чём?

Если у чего-то есть имя наличие или отсутствие внешних references на lifetime этого нечто ну никак не влияют. Перечитайте что Вы заявили.

ПыСы. Немножко удивлён что разжёвывать приходится.

Если у чего-то есть имя наличие или отсутствие внешних references на lifetime этого нечто ну никак не влияют

А если нет, то влияет. Из чего вытекает очень большое семантическое отличие от пойнтеров. К чему эти разжёвывания?

Я гляжу, тут с основами логики уже проблемы пошли. Из одного примера никак не вытекает идиотское утверждение «у него в референсах только стековые значения, в пойнтерах только значения с кучи».

Все представленные Вами тут примеры этому критерию отвечают.

Пытаться аргументировать разницу между пойнтерами и референсами положив в них объекты с разным размещением и потом еще то то про логику говорить это конечно сильно…

А если нет, то влияет.

Бесит когда передёргивать начинают. Напомню:

Референс - это алиас имени с наверченным расширением лайфтайма

Обосрались - обтекайте.

положив в них объекты с разным размещением

Ну не мог же я в пойнтер положить непосредственно сам объект! Семантика разная-с.

Референс - это алиас имени с наверченным расширением лайфтайма

Ну и в чём я тут не прав? Не во всех случаях лайфтайм расширяется, я уже говорил об этом ранее, но механизм присутствует для некоторых случаев (окей, для одного случая, раз уж с логикой проблемы). Мы вообще тут обсуждаем, равны ли семантически пойнтеры и референсы.

Обосрались - обтекайте.

Попробуйте отвечать по существу, будет продуктивнее, чем какашками кидаться.

Референс - это алиас имени с наверченным расширением лайфтайма

Ну и в чём я тут не прав?

Reference алиасом имени не является. Какое имя алиасит «i» в const int& i = 0;?

Ну не мог же я в пойнтер положить непосредственно сам объект!

A a;
A * ptr = &a;

О том и речь что фсе могут почему то, а Вы в пойнтеры только из кучи что то класть умеете - семантика у Вас такая видимо… бывает, сочувствую. Не всем гугл одинаково полезен.

Понаехали в паскалевскую тему и нагадили тут своими Си и Си-пи-пи, фи.

Было б мало отличий – не портил бы Bjarne Stroustrup свой язык ссылками.

Сссылки и указатели на один и тот же объект:

#include <iostream>
#include <typeinfo>

int main(){
	std::ostream e{nullptr};
	std::istream i{nullptr};
	std::ostream *pe{&e}, &re{e};
	
	try { 	auto pi { dynamic_cast<std::istream*>(pe) };
	 	if (nullptr == pi)
			 std::cerr << "Failed pointer" "\n";
	}
	catch (std::bad_cast e ){
		std::cerr << e.what() << "(Catched pointer)" "\n";
	}

	try { 	auto &ri { dynamic_cast<std::istream&>(re)};
		// warning: the compiler can assume that the address of 'ri' will never be NULL
		if ( nullptr ==  &ri)
			 std::cerr << "Failed reference" "\n";
	}
	catch (std::bad_cast e ){
		std::cerr << e.what() << "(Catched reference)" "\n";
	}
}

Failed pointer
std::bad_cast(Catched reference)

Осспади, ну пожалуйста, раз так больше нравится:

    const A* a1 = &A{};
    const A& a2 = A{};

Разницы в семантике настолько нет, что первая строчка даже не компилится современным компилятором.

Так компилится?

using A = int;
//enum class A{};
//using A = int (*)();
void b()
{
	const A* a1 = &static_cast<const A&>(A{});
	const A& a2 { A{} };
	A&& a3{};
	const A* a4{&a3};
}

Кто-нибудь в курсе, в pascal’е можно использовать команды оболочки, например, как в C++?

system("ls");

Если для линукса и прочих юниксов — fpSystem().

Если нужно кроссплатформенно, есть класс TProcess и функции ExecuteProcess() и RunCommand(), но они все сложнее.

Если для линукса и прочих юниксов — fpSystem().

Какой-нибудь дополнительный модуль для этого нужно подключать?

гугль говорит

uses Unix;

что за чудесная новомодная штука эти поисковики! и появились совсем недавно, не все ими пользоваться умеют

Очень рад, что вы умеете.

После добавления строки

Uses crt, unix;

стало выводиться предупреждение:

/usr/bin/ld.bfd: warning: link.res contains output sections; did you forget -T?

link.res syntax error, or «did you forget -T?»

There was a bug in GNU LD 2.19 that caused it to crash when processing FPC-generated linker scripts. This bug has been fixed in GNU LD 2.19.1.

At the same time, LD has been modified to emit a warning of the form

       /usr/bin/ld: warning: link.res contains output sections; did you forget -T?

FPC 3.1.1 and later by default generate a different kind of linker script that no longer triggers this warning. Unfortunately, this is only possible by making use of functionality that is unavailable before GNU LD 2.19. Earlier versions therefore now complain about a syntax error in link.res. The new -X9 compiler command line parameter can, however, be used to generate linker scripts that are compatible with pre-2.19 linker versions.

Their is no way to remove the -T warning with earlier FPC versions, but it should not result in any problems.

https://www.freepascal.org/faq.var#unix-ld219

Я теперь буду гуглить за тебя всё? 🙂

Я теперь буду гуглить за тебя всё?

В предложении опечатка — вместо вопросительного знака должна быть точка?

virtuos86@lor:~$ BL @Mischutka