Передача объекта по ссылке

@Валеронище · Регистрация: 04.07.2014

Студворк — интернет-сервис помощи студентам

В книге Шилдта есть задание:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
#include <iostream>
#include <cstring>
#include <cstdlib>
 
using namespace std;
 
class strtype
{
    char *p;
public:
    strtype(char *s);
    ~strtype() { delete [] p; cout << "Destruction\n"; }
    char* get() { return p; }
};
 
strtype::strtype(char *s)
{
    int l = 0;
    l = strlen(s) + 1;
 
    p = new char [l];
    if(!p) {
        cout << "Ошибка выделения памяти\n";
        exit(1);
    }
 
    strcpy(p, s);
}
 
void show(strtype x)  // правильно &x, то бишь передача по ссылке
{
    char *s;
 
    s = x.get();
    cout << s << "\n";
}
 
int main()
{
    strtype a("one"), b("two");
 
    show(a);
    show(b);
 
    return 0;
}

В ответе сказано : В исходной программе объект передается в функцию show() по значению. Поэтому делается его копияю
Когда функция show() возвращает свое значение, копия удаляется и при этом вызывается деструктор копии.
Это приводит к освобождению памяти, на которую указывает указатель р, но освобожденная память все еще необходима аргументам функции show().
Что означает, - освобожденная память все еще необходима... Разве у каждого объекта не свой указатель p. Объясните, пожалуйста, подробнее, что происходит на самом деле, почему в таком случае программа завершается критически?

IGPIGP · 27.07.2019, 14:48

Для темы передача объекта по ссылке мы ведём странный диалог. Если вы помните, вы упоминали тему о том на какой стороне имеет смысл проверять аргументы функции. Посмотрите, что с ней стало.
Вот фраза:

Сообщение от DrOffset

Поведение литералов в этом случае подчиняется общим правилам, которые запрещают такое преобразование.

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

Сообщение от DrOffset

Ошибка будет из-за того, что литерал - это константный массив, а инициализируется указатель на неконстанту

Если с точки зрения языка, то это всегда ошибка, а будет - означает что ошибка будет выдана в виде сообщения об ошибке.
DrOffset, вы серьёзно полагаете, что я считаю правильным такое поведение компиляторов? Но они это компилируют и автор языка это объясняет требованием совместимости со старым С стилем и кодом. О чём спор?

Добавлено через 3 минуты

Сообщение от DrOffset

Не смотря на то, что это информативная часть, а не нормативная, информация опирается на нормативные положения, которые касаются неявного снятия константности в общем случае.

Это подтверждает ненормативность поведения компиляторов в данном случае. Ненормативность лексики.

@DrOffset · 27.07.2019, 15:33

Сообщение от IGPIGP

Но они это компилируют и автор языка это объясняет требованием совместимости со старым С стилем и кодом. О чём спор?

Я вам уже сказал, что не веду в последних своих сообщениях речь о компиляторах. Вообще. С компиляторами мы разобрались еще в #16.
Нет спора, я просто даю справочную информацию.

Сообщение от IGPIGP

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

Именно это и следует.

Сообщение от IGPIGP

Если с точки зрения языка, то это всегда ошибка, а будет - означает что ошибка будет выдана в виде сообщения об ошибке.

Она будет выдана при соответствующих настройках строгости соответствия стандарту. Об этом я тоже писал.

Сообщение от IGPIGP

Это подтверждает ненормативность поведения компиляторов в данном случае. Ненормативность лексики.

Компилятор и его поведение мы уже обсудили.

@_stanislav · 27.07.2019, 15:34

Валеронище, как то так работают умные указатели, туда копай

@DrOffset · 27.07.2019, 15:40

Сообщение от IGPIGP

Если с точки зрения языка, то это всегда ошибка, а будет - означает что ошибка будет выдана в виде сообщения об ошибке.

"Будет" в смысле, что она "будет" с точки зрения языка. Язык С++ вообще так устроен, что далеко не любая ошибка в принципе диагностируется. Поэтому "будет ошибка" в С++ понимать в общем смысле как "будет выдано сообщение" - некорректно.

IGPIGP · 27.07.2019, 16:43

Сообщение от DrOffset

Поэтому "будет ошибка" в С++ понимать в общем смысле как "будет выдано сообщение" - некорректно.

DrOffset, она или уже есть или будет. Всё вместе не бывает.

Сообщение от я

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

Сообщение от DrOffset

Именно это и следует.

Не следует. Потому что оно компилируется. DrOffset, не стану далее это обсуждать. Вообще, повторяемость ситуации, навевает нерадостные мысли. Есть куча дел. Извините.

@DrOffset · 27.07.2019, 17:06

Сообщение от IGPIGP

Не следует. Потому что оно компилируется.

Из закона не следует, что все захотят его выполнять. Но следует, что все должны.
Я что недостаточно привел фактов, зачем вы это все пишете? В С++03 это официально не считалось ошибкой. А теперь считается. Поведение компиляторов вообще тут не при чем. GCC разрешает массивы с неконстантной размерностью, хотя в стандартном С++ это является ошибкой, и что теперь, мы не должны говорить о том, что это будет ошибкой, если так написать? Тем более, что мы уточняем: "с точки зрения С++".

Сообщение от IGPIGP

она или уже есть или будет.

Она будет, если так написать. Независимо от того что об этом думает компилятор.

Сообщение от IGPIGP

Есть куча дел. Извините.

Всего доброго.

IGPIGP · 27.07.2019, 18:44

Сообщение от DrOffset

Я что недостаточно привел фактов, зачем вы это все пишете?

А вы зачем? Вы можете не зависеть от того как ведут себя компиляторы, а я - нет. Нестандарьные расширения не при чём. Конст-каст никто не отменял. Все кто понимает за чем он нужен не станут стрелять в свою ногу. С указателем на char компилятор делает, это автоматически. Это плохо, не корректно, но ни один здравомыслящий разраб компилятора сегодня ещё не готов отказаться от совместимости, которую обеспечивает, это скользкое место.
И я уже писал, что

Сообщение от IGPIGP

Этот грех из С тянется

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

@Undisputed · 27.07.2019, 19:14

Сообщение от IGPIGP

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

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

Сообщение от IGPIGP

Но это не ошибка и будет работать при условии, что писать по такому указатели ни кто не будет.

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

Добавлено через 2 минуты

Сообщение от Undisputed

тогда это UB

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

IGPIGP · 27.07.2019, 20:14

Сообщение от Undisputed

если же ничего подобного в используемом компиляторе нет
тогда это UB

Чего нет? Undisputed, вы прекрасно знаете, что если функция объявила неконстантный параметр то передать константу не выйдет. Нужно скастить или будете иметь не ворниг а ошибку компиляции foo: невозможно преобразовать параметр 1 из бла-бла...
К чему вот эти "адекваты"?
А для char * - исключение. Оно само кастится и все довольны, что функция и не собирается ни чего писать. И опять 25. Я ни где не писал, что это хорошо. Но передать const char * в такую функцию не получается и всё. Что же его в массив переписывать и потом передавать? Вопрос даже не в том. Ни кто в здравом уме не работает с таким старым материалом. Но есть такой код из глубины времён.
Undisputed, я утомился от этих "новичковских" тем. Один недавно с пеной у рта доказывал, что функция обязана всё на своей стороне проверить. А функция - матрёшка вложенная в другие и по хорошему она не знает что делается снаружи. Получила указатель и число - и может пробежать по диапазону. И негде ей узнать, правильно ей передали или будет бум. Ну да ладно. Эта тема о ссылках как аргументах. А мы где? Не хочется выбраться?

@DrOffset · 27.07.2019, 20:23

Сообщение от IGPIGP

А вы зачем?

Сообщение от DrOffset

я просто даю справочную информацию.

...

Сообщение от IGPIGP

Но это не ошибка

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

Сообщение от IGPIGP

будет работать

Вот выделенное в С++ вообще не критерий корректности кода. При всем-то многообразии UB в этом языке.

Сообщение от IGPIGP

Нестандарьные расширения не при чём.

Именно при чем, потому что с того момента, как цитату, про которую я сказал выше, убрали из стандарта, данное поведение компиляторов перешло в разряд нестандартных расширений.

Сообщение от IGPIGP

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

В реальном мире вообще много от чего нельзя отказаться. Как это меняет факт, что с точки зрения С++ код некорректный?

Сообщение от IGPIGP

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

Да при чем тут вообще я? Я же говорю: даю справочную информацию. Все. Зачем вы спорите со справочной информацией? Я своего личного мнения вообще не высказывал. Только факты.

А вот теперь личное мнение

Лично вы не считаете, что это ошибка, потому, что компиляторы это позволяют для совместимости, вы думаете лично я как-то с этим не согласен? Да я сам бы этим пользовался, если бы пришлось. Я не согласен с тем, что вы выдаете личное мнение за аргумент и спорите с фактом. Вдвойне не понимаю, зачем на форуме новичков говорить про legacy и оправдывать какие-то там решения для совместимости, новички, может, вообще никогда с этим не столкнуться. Их надо отучивать всеми силами от этих legacy-костылей. А вы развели со мной полемику, и человеку непосвященному может показаться, будто бы тут действительно есть о чем поспорить, но это совсем не так! Тут не о чем спорить совершенно. Есть актуальная редакция стандарта, которая это запрещает, есть ворох компиляторов, которые, вопреки этому, это поддерживают. Ну это техническое решение, компромисс. Зачем это новичкам? Пусть они пишут свои новые проекты правильно, без оглядки на ошибки прошлого! Вы же понимаете, что современное поколение формирует свое понимание здесь, в интернете, а вы участвуете в этом непосредственно?

@Undisputed · 27.07.2019, 20:23

IGPIGP,
Я о том что если что-то явно запрещено или не указано среди правил языка, тогда это UB с точки зрения языка вот и все

IGPIGP · 28.07.2019, 00:41

Сообщение от DrOffset

Лично вы не считаете, что это ошибка, потому, что компиляторы это позволяют для совместимости, вы думаете лично я как-то с этим не согласен? Да я сам бы этим пользовался, если бы пришлось.

А больше ни чего я ввиду и не имел. Что касается личного мнения, то у меня больше ни чего нет. Факты штука упрямая, но это немые по своей природе вещи. Небо, горы, код который написан, скомпилирован и работает корректно. А наши суждения - интерпретация.

Сообщение от DrOffset

Вы же понимаете, что современное поколение формирует свое понимание здесь, в интернете

Интернет - инструмент. И он обладает интеллектом своего пользователя. Вы недавно говорили о том, что без книг и документации нельзя ни чего достичь. Я согласен. А сейчас вы говорите о том, что наши диалоги могут изломать чью нибудь судьбу. Не исправимо и навсегда. Разрешите не согласиться и здесь.
В разделе физика, я всегда радовался вдумчивому собеседнику, даже когда он был не прав. Именно такой собеседник помогает показать материал и взгляды на него. То, что мы тут обсуждаем сейчас не критично и не концептуально. Не вижу что тут может навредить, особенно учитывая тот простой факт, новички и не поймут сути спора.

Сообщение от Undisputed

Я о том что если что-то явно запрещено или не указано среди правил языка, тогда это UB с точки зрения языка вот и все

У языка нет точки зрения. Люди пишут вещи. Когда компиляторы прекратят компилировать в корректный код - это будет ошибкой. Так же как и ссылочный тип станет типом тогда, когда сможет создавать свои объекты. Обёртка ссылки std::reference_wrapper, это полноценный тип, ссылка, сама по себе считается типом и во многом на него похожа, в частности, по поддержке на уровне библиотек работы со свойствами типов. Но в сути своей, это не тип. Можете снова апеллировать к точке зрения языка. А мне моя голова дороже.
Но я не собираюсь спорить даже с черновиком стандарта. Мне лишь не нравится тот набор заклинаний в страницу текста, где вместо определения объекта, излагается ощущения и впечатления о том, как эта штуковина, создаёт впечатления и ощущения. Теперь для аргументации нужно найти нужную цитату и дать ссылку или произнести.
А я считаю, что старое определение не стоит забывать. Оно дано кратко и в предметных терминах. Это имеет свойства модели, то есть осмысленного знания.
DrOffset, Undisputed, давайте я уже соглашусь со всем что вы говорите (хотя я и не спорил, то есть не стал бы спорить, если бы увидел насколько для вас это важно) и остановим это.

Croessmah · 28.07.2019, 01:14

IGPIGP, слов нет...

@DrOffset · 28.07.2019, 01:46

Сообщение от IGPIGP

А сейчас вы говорите о том, что наши диалоги могут изломать чью нибудь судьбу.

Нет, я говорю о том, что наш с вами диалог читают люди. И может создаться впечатление, будто бы спор чем-то оправдан, хотя это не так. Это не имеет отношения к тому, что я говорил в другом месте про книги. Мы сейчас обсуждаем конкретный случай (ситуацию в этой теме), а не мое видение правильного обучения. Люди все равно будут учиться по интернету, не смотря на то, что я (например) им советую читать книги. Этот процесс не остановить.

Сообщение от IGPIGP

Теперь для аргументации нужно найти нужную цитату и дать ссылку или произнести.

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

Сообщение от IGPIGP

Мне лишь не нравится тот набор заклинаний в страницу текста, где вместо определения объекта, излагается ощущения и впечатления о том, как эта штуковина, создаёт впечатления и ощущения.

Никаких заклинаний нет. Изначально, и вы сами это говорили, язык С++ не разрешает снимать константность просто так (т.е. неявно). Вы знаете, что это правильно, вы сами говорили выше. На этом строится безопасность типов, const-safety. Для случая литералов было сделано исключение, но не навсегда. Должен был пройти достаточный период, чтобы старые проекты избавились от этого или остались на прежних версиях, а новые проекты писались без подобных анахронизмов. Теперь, в С++11 данное исключение было убрано, т.к. предполагается, что времени на переход и адаптацию было выдано достаточно (с 2003 года прошло 8 лет). Однако, компиляторы пишут люди практичные, рубить с плеча не готовые. Поэтому данное исключение все еще присутствует в реализации, но уже в качестве расширения. Вы скажете, но вот же, нет здесь ошибки. А я опять скажу - есть! Знаете почему? Потому что в язык ввели концепцию const-safety для увеличения надежности программ, а реализация спокойно позволяет ее нарушать. Из благих, естественно, побуждений. Но нарушение const-safety - это концептуальная ошибка, и потенциальная потеря производительности. Из-за этих допущений компиляторы до сих пор не могут нормально оптимизировать константы.
Текущие версии языка не описывают более исключений из правил для этого случая. Для всех типов неявное снятие константности теперь едино считается ошибкой. Разве это плохо? Это вы называете заклинаниями, попытку сделать непротиворечивую систему?
Вы скажете: "компиляторы работают как прежде". Я отвечу, если завтра появится компилятор, который станет трактовать эту ситуацию без исторических исключений, вы что, поменяете свое мнение? Если да, то вопросов больше нет. Мне все понятно.

IGPIGP · 28.07.2019, 15:15

Сообщение от DrOffset

И это гораздо лучше, чем выдумывать свою интерпретацию.

Собственная интерпретация неизбежна. А цитирование без понимания смысла - схоластика.

Сообщение от DrOffset

Я отвечу, если завтра появится компилятор, который станет трактовать эту ситуацию без исторических исключений, вы что, поменяете свое мнение?

Вот как раз моё мнение по данному вопросу и не является догмой. Это не базовый вопрос и зависит он как раз от реализации. Пока язык это реализует и всё корректно работает, это не ошибка де-факто. Можно писать на заборах, петь хором : -"Тяжелые баги уходят, в борьбе за приход истинЫ, за ними другие приходят. Они будут тоже трудны...", но это не изменит положения дел, - солнце будет вставать на востоке, компиляторы будут генерировать рабочий код. Наш разговор, о том как это нужно называть, странен, так как относимся к данному вопросу мы ~~одинаково~~ сходно. То есть,

Сообщение от DrOffset

если завтра появится компилятор, который станет трактовать эту ситуацию без исторических исключений

те кто работает со старым кодом не станут его использовать в тех проектах. А когда переход осуществится - я изменю мнение. Хотя от этого ни чего не зависит, - я не стану так делать (снимать конст) без причины.
Что касается перехода. Б.Страуструп утверждал и утверждает (менее настойчиво), что С++ - надмножество C. То есть, - буквально: всё (за малым исключением) можно писать как на С и в стиле С. В этом смысле, и дятлу ясно, что тут есть нечто большее, чем мульти-парадигменность. То есть, можно проверять аргументы и на вызывающей стороне. Но далеко не все достигают уровня этой птицы. И есть масса людей которые громогласно утверждают, что С++ и С это разные языки и бла-бла-бла. Наш разговор затрагивает и эту сторону жизни.

@DrOffset · 28.07.2019, 20:08

Сообщение от IGPIGP

А цитирование без понимания смысла - схоластика.

Я пропущу этот выпад в мою сторону мимо ушей.

Сообщение от IGPIGP

Б.Страуструп утверждал и утверждает (менее настойчиво), что С++ - надмножество C.

http://www.stroustrup.com/bs_faq.html#C-is-subset
Скажем так, он утверждает несколько другое. Похожее, но другое.
Кроме того, современные языки С и С++ по его мнению - это братья, а не родитель и ребенок.

Сообщение от IGPIGP

Пока язык это реализует и всё корректно работает, это не ошибка де-факто.

Де факто, это уже ошибка. Это легко проверить на любом компиляторе, который поддерживает стандарт. Вот, смотрите:
* Это компиляция в С++03, ошибки нет: https://wandbox.org/permlink/Khwut7Si1h8KShKG
Есть предупреждение, что подобное преобразование не рекомендуется к использованию.

* Это компиляция в С++11, ошибка есть: https://wandbox.org/permlink/cyHplEq7aWdHvuW8

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

IGPIGP · 28.07.2019, 20:34

Сообщение от DrOffset

Я пропущу этот выпад в мою сторону мимо ушей.

Это не в вашу, DrOffset, ни коим образом. Вы один из наиразумнейших участников с квалификацией не вызывающей сомнений. Этот, как вы говорите, выпад связан с бытующим патерном, приводить ссылки без комментов. Кроме того, в современном мире IT (не только стандарте С++) полно тавтологии из ряда: "объектном, мы считаем то, что хотим считать таковым" или "ошибкой является то, что мы хотим считать ошибкой". Можно защищать такое положение дел тем, что тут де не наука, а практическая инженерия. Но поверьте (или не верьте), но реальная инженерия - та где самолёты не падают, а реакторы не взрываются (по большей части), пользуется иными,- научными, формулировками.

Сообщение от DrOffset

Скажем так, он утверждает несколько другое. Похожее, но другое.

Если С подмонжество множества СРР то СРР - надмножество С. У НЕГО много высказываний ибо ОН может себе это позволить.

Сообщение от DrOffset

Это компиляция в С++11, ошибка есть

У меня с MinGW всё норм (варнингом, правда) и 11 включен.
Но не суть. Половина компиляторов может поддерживать, половина нет и это значит, что у половины будет что-то не так.С чьей-то точки зрения. Всё едино, можно будет сказать, что для компилятора X это уже не пройдёт и включить ни как нельзя. С таким спорить не логично и я не собираюсь это делать.

Croessmah · 28.07.2019, 20:56

Сообщение от IGPIGP

У меня с MinGW всё норм

-pedantic-errors

IGPIGP · 28.07.2019, 21:54

Сообщение от Croessmah

-pedantic-errors

Я в курсе. То есть, если захотеть, то это ошибка. Croessmah, вам это развитие темы кажется нормальным?

@DrOffset · 28.07.2019, 22:20

Сообщение от IGPIGP

То есть, если захотеть, то это ошибка.

Речь шла о том, что это стало ошибкой. С тем же ключом -pedantic-errors, но с указанием нового стандарта - это ошибка. С этим же ключом, но указанием старого стандарта - это НЕ ошибка. Именно об этом я и говорю\говорил. Компилятор следует правилам, которые предписывает стандарт. Да, сейчас в компиляторе нужно включать строгое соответствие, но это не меняет сути вопроса. Компилятор должен следовать правилам, они не являются выдуманными или "написанными на заборе". С чего бы вообще нужно было разработчикам компиляторов, пусть даже только при соблюдении условий строгого соответствия, переводить эту ситуацию в категорию ошибок? Уж не потому ли, что точка зрения языка на этот вопрос поменялась, как вы считаете?

Новые блоги и статьи Все статьи Все блоги /
Установка MinGW GCC 16.2 и CMake 8Observer8 10.08.2026 VK Видео: https:/ / vkvideo. ru/ video-240781534_456239017 YouTube: eY5-5PyI9NM Текстовая версия	Неделя из жизни имитационной модели склада: мои кривые руки растут, откуда надо anaschu 10.08.2026 Неделя из жизни имитационной модели склада: как я почти написал неправильную логику и что с этим делать Работаю сейчас над учебно-рабочим проектом: строю в AnyLogic имитационную модель процессов. . .	Калькулятор для расчета родства russiannick 07.08.2026 1. Задача: Создать калькулятор для расчета родства. Родственных связей существует 8 ступеней, такие как: p - отец P - мать q - муж Q - жена b - брат B - сестра s - сын S - дочь	Мир по моей воле kumehtar 07.08.2026 Когда-то кажется, что всё просто. Ты весь такой светлый. Причиняешь добро. Борешься за справедливость в этом тёмном мире. Потом начинаешь замечать одну неприятную вещь. Почти каждый хороший. . .
Кредитный калькулятор Maks 05.08.2026 Решение задачи по прикладной информатике средствами 1С. Задача: Напишите приложение-калькулятор, которое помогает рассчитывать параметры кредита для аннуитетного и дифференцированного видов. . .	У нас сейчас поговорку "Опять 25" нужно переделать на "Опять +35". kumehtar 04.08.2026 С ностальгией вспоминаю времена моего детства, когда у нас и правда +25 - была максимальная температура летом. Раньше +25 °C реально казались вершиной жары, когда можно было весь день пропадать на. . .	Как ИИ начал спорить и врать (возможно почуяв опасность для себя от индустрии - уход от электроники). Hrethgir 04.08.2026 Недельный диалог, на фоне событий с НПЗ. Да, из спирта можно получать бензин, и это не сложно. Но потом в схеме я решил избавиться от насоса, при этом полностью сделав контроль подачи спирта в. . .	Термопринтер QR701 Argus19 03.08.2026 Термопринтер QR701 Купил два термопринтера QR701. На сэлф-тесте написано: Language: PC936 (GB18030). Что означает, что принтеры могут печатать только латиницу и китайские иероглифы. Так же. . .

@_stanislav "C with Classes" 2022 / 1404 / 523 Регистрация: 16.08.2014 Сообщений: 5,885 Записей в блоге: 1
	27.07.2019, 15:34
	Валеронище, как то так работают умные указатели, туда копай 0

@Undisputed 901 / 478 / 93 Регистрация: 10.06.2014 Сообщений: 2,700
	27.07.2019, 20:23
	IGPIGP, Я о том что если что-то явно запрещено или не указано среди правил языка, тогда это UB с точки зрения языка вот и все 0

Croessmah Неэпический 18149 / 10731 / 2067 Регистрация: 27.09.2012 Сообщений: 27,038 Записей в блоге: 1
	28.07.2019, 01:14
	IGPIGP, слов нет... 0