и?

ну, техника-то такая же, получается, в стеке все плотненько лежит упаковано, без мусора ))

вот хороший вопрос, UB в данном случае имеет ли негативные последствия?

годная задачка, утащу в копилку вместе с void f(int& r, ...) : UB The contents of the header <cstdarg> are the same as the C standard library header <stdarg.h>, with the following changes: The restrictions that ISO C places on the second parameter to the va_start macro in header <stdarg.h> are different in this International Standard. The parameter parmN is the rightmost parameter in the variable parameter list of the function definition (the one just before the ...).219 If the parameter parmN is a pack expansion (17.5.3) or an entity resulting from a lambda capture (8.1.5), the program is ill-formed, no diagnostic required. If the parameter parmN is of a reference type, or of a type that is not compatible with the type that results when passing an argument for which there is no parameter, the behavior is undefined.

кстати, а каким компилятором можно поймать бабах? а то у меня пока не получается https://wandbox.org/permlink/Kt1X5FN3YW8Lq0iy

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

MSVC не компилирует

ах а под гцц не сталкивались?

ээээ а на массивы распространяется правило про эквивалентность одноэлементного массива и переменной?

Распространяется, но разадресовывать элемент массива (того эквивалентного) всё равно нельзя

Распространяется, но разадресовывать элемент массива (того эквивалентного) всё равно нельзя

забавно... https://godbolt.org/z/Cqy-sx

забавно... https://godbolt.org/z/Cqy-sx

кто знает как в listbox сделать CUEBANNER ?

в MSVC 1? )

Constexpr переменные не на стеке хранятся поэтому msvc 1 выдавал

разадресация с автоматическим приведением к адресу на первый элемент.

Так, а какая логика в C++ за запретом каста T(*)[N] к T(*)[]?

а в случае с int arr[] = {1, 2, 3} имеет ли компилятор право вообще положить сами константы где-то в другом месте, а на стеке оставить только собственно только указатель на сам массив?

а в случае с int arr[] = {1, 2, 3} имеет ли компилятор право вообще положить сами константы где-то в другом месте, а на стеке оставить только собственно только указатель на сам массив?

потому что мне кажется, это решение исходит из предположения что arr == &arr что для меня не очевидно https://wandbox.org/permlink/4ayhDhIy7lOGs3P0 , однако выполняется на практике

потеря размерности

Constexpr переменные не на стеке хранятся поэтому msvc 1 выдавал

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

Причём здесь то, где хранится constexpr, если сам массив там не constexpr? Адрессная арифметика в constexpr должна работать (правда ещё не везде нормально работает - gcc слишком много лишнего позволяет, например). Иначе как string_view в constexpr использовать и прочее?

Причём здесь то, где хранится constexpr, если сам массив там не constexpr? Адрессная арифметика в constexpr должна работать (правда ещё не везде нормально работает - gcc слишком много лишнего позволяет, например). Иначе как string_view в constexpr использовать и прочее?

Ну тогда выходит бага в MSVC? Не работает арифметика указателей в constexpr

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

это верно, но от этого переменная не должна быть

http://llvm.org/foundation/relicensing/

чо там, опять какие-то зашкварные CoC расщемляющие ущемленных и ставящие палки в колеса нормальным разработчикам, или просто рядовое бурление бюрократии?

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

собственно вопрос, в чём бомба новости про LLVM то?

*прячу банхаммер за спину*

если первое, то вот draft http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf

если первое, то вот draft http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf

годная задачка, утащу в копилку вместе с void f(int& r, ...) у нас ещё недавно всплывал майндфак на тему, почему успешно работает такое чудо const char *input = "1 2 3 abcdef"; char data[30]; int x,y,z; sscanf(input, "%d %d %d %s", &x, &y, &z, &data);

https://cmake.org/cmake/help/v3.13/prop_tgt/VS_DOTNET_TARGET_FRAMEWORK_VERSION.html

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

дык sscanf и парсит строчку как fscanf FILE

соль была в не-сразу-очевидном buf == &buf для массива на стеке