http://www.stroustrup.com/P0977-remember-the-vasa.pd
f

do góry

On 2019-01-12 11:46, g...@g...com wrote:
> http://www.stroustrup.com/P0977-remember-the-vasa.pd
f

Prozne zale (o min 10 lat za pozno...).

PS:
Tymczasem n/w smaczki w C/C++ wciaz maja sie dobrze:

int main()
{
int x = 8;
int y = sizeof(x++);
// no wiec ile w tym miejscu wynosi sobie x ?
}

AK

do góry

x == 9; y == 4;
Co w tym tajemniczego?!?

do góry

On Saturday, January 12, 2019 at 7:37:22 PM UTC+1, s...@g...com wrote:
> x == 9; y == 4;
> Co w tym tajemniczego?!?

No właśnie nie, wyrażenie będące argumentem sizeof nie jest
wyliczane (nie jest w ogóle kompilowane).

Ale nie ma obaw, taki kod nie pojawia się poza usenetem. :)

w.

do góry

W dniu 2019-01-12 o 20:48, Wojciech Muła pisze:
>
> No właśnie nie, wyrażenie będące argumentem sizeof nie jest
> wyliczane (nie jest w ogóle kompilowane).
>

Skoro nie jest kompilowane, to dlaczego np. tu jest błąd:

int x = 8;
int y = sizeof(x+);

pozdr
--
A S

do góry

On 2019-01-12 20:48, Wojciech Muła wrote:
> On Saturday, January 12, 2019 at 7:37:22 PM UTC+1, s...@g...com wrote:
>> x == 9; y == 4;
>> Co w tym tajemniczego?!?
>
> No właśnie nie, wyrażenie będące argumentem sizeof nie jest
> wyliczane (nie jest w ogóle kompilowane).

No wiec?
Dlaczego parser C/C++ taki cus dopuszcza?
sizeof to zwykly operator (a nie funkca), wiec nie ma
przeszkod aby (nawet w gramatyce) taka restrykce zawrzec

> Ale nie ma obaw, taki kod nie pojawia się poza usenetem. :)

Tak :)? Zdziwil bys sie.

AK

do góry

On 2019-01-12 20:48, Wojciech Muła wrote:
> On Saturday, January 12, 2019 at 7:37:22 PM UTC+1, s...@g...com wrote:
>> x == 9; y == 4;
>> Co w tym tajemniczego?!?
>
> No właśnie nie, wyrażenie będące argumentem sizeof nie jest
> wyliczane (nie jest w ogóle kompilowane).

Co to znaczy, ze nie jest kompilowane?
Kompilowane jest (parsowanie itd).
Nie jest jedynie _generowany_ kod wyrazenia podlegajacego sizeof.
Zamiast niego (wlacznie z sizeof) jest po prostu na etapie
generacji kodu (a nawet mozna juz na etapie parsingu) wstawiana stała.

PS: Poza tym nie ma tak wesolo (jak to zwykle w C:).
Ja zawsze jest wyjatek (zrzeszta tu logiczny).
Dla tablic dynamicznych (C99) (np. char tab[*]) sizeof jest wyliczany
"on runtime".

AK

do góry

On 2019-01-12 19:37, s...@g...com wrote:
> x == 9; y == 4;
> Co w tym tajemniczego?!?

To se chopie wpierw sprawdz, czy na pewno 9.

PS: No i widac jak dla dloni, ze nawet dla zaprzysieglych
Ayatollahow i wieloletnich developerow C/C++ to wciaz zagadka ;)

AK

do góry

On Sunday, January 13, 2019 at 12:01:20 PM UTC+1, AK wrote:
> On 2019-01-12 20:48, Wojciech Muła wrote:
> > On Saturday, January 12, 2019 at 7:37:22 PM UTC+1, s...@g...com wrote:
> >> x == 9; y == 4;
> >> Co w tym tajemniczego?!?
> >
> > No właśnie nie, wyrażenie będące argumentem sizeof nie jest
> > wyliczane (nie jest w ogóle kompilowane).
>
> No wiec?
> Dlaczego parser C/C++ taki cus dopuszcza?

Przecież gramatyka właśnie dopuszcza, żeby argumentem
operatora było **wyrażenie**. Bez tego nie byłbyś
w stanie w plain C odczytać rozmiaru pola struktury.
A tak piszesz sizeof((Typ*)0->pole) [przykład z praktyki,
nie usenetu].

> sizeof to zwykly operator (a nie funkca), wiec nie ma
> przeszkod aby (nawet w gramatyce) taka restrykce zawrzec

Jak pokazałem, takie ograniczenie byłoby bez sensu.
W C++ odczyt typu wyrażenia umożliwia też decltype, które
jest w wielu kontekstach niezbędne.

w.

do góry

On 2019-01-13 13:19, Wojciech Muła wrote:
> On Sunday, January 13, 2019 at 12:01:20 PM UTC+1, AK wrote:
>> On 2019-01-12 20:48, Wojciech Muła wrote:
>>> On Saturday, January 12, 2019 at 7:37:22 PM UTC+1, s...@g...com wrote:
>>>> x == 9; y == 4;
>>>> Co w tym tajemniczego?!?
>>>
>>> No właśnie nie, wyrażenie będące argumentem sizeof nie jest
>>> wyliczane (nie jest w ogóle kompilowane).
>>
>> No wiec?
>> Dlaczego parser C/C++ taki cus dopuszcza?
>
> Przecież gramatyka właśnie dopuszcza, żeby argumentem
> operatora było **wyrażenie**. Bez tego nie byłbyś
> w stanie w plain C odczytać rozmiaru pola struktury.

E tam.
Przy deklaracji tablic wymagane jest const_expr (ktore jest
podsetem expr) i wszytsko gra.
_Nic_ nie stoi na przeszkodzie, aby dla sizeof tez bylo
subexpr (nie dopuszczajace operatorow pre-in-fixowych).

>> sizeof to zwykly operator (a nie funkca), wiec nie ma
>> przeszkod aby (nawet w gramatyce) taka restrykce zawrzec
>
> Jak pokazałem, takie ograniczenie byłoby bez sensu.

Nie. Jest jak najbardziej sensowne.
Problemem sa zapewne (jak zwykle) zaszlosci.

AK

do góry