...nawet jesli by bylo trudno/niewygodnie to zrobic
na etapie gramatyki, to zawsze mozna to zrobic na etapie
semantyki (analizujac juz gotowe ast).

AK

do góry

On Sunday, January 13, 2019 at 5:34:26 PM UTC+1, AK wrote:
> 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).

Nie rozumiem w czym te operatory przeszkadzają.

w.

do góry

On 2019-01-14 09:37, Wojciech Muła wrote:
> On Sunday, January 13, 2019 at 5:34:26 PM UTC+1, AK wrote:
>> 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).
>
> Nie rozumiem w czym te operatory przeszkadzają.

No bez jaj. Przeszkadzaja, gdyz tak wlasciwie nie dzialaja
w sizeof, a jedynie wprowadzaja w blad/konfuzje (8 zamiast 9)
developerow.
Nie powinny byc w sizeof dopuszczalne, tak jak nie jest
dopuszczalne dowolne wyrazenie (a jedynie consts expr) w
deklaracji rozmiaru tablicy, czy w dyrektywach preprocesora

AK

do góry

On 2019-01-14 10:06, AK wrote:
> No bez jaj. Przeszkadzaja, gdyz tak wlasciwie nie dzialaja
> w sizeof, a jedynie wprowadzaja w blad/konfuzje (8 zamiast 9)
> developerow.
> Nie powinny byc w sizeof dopuszczalne, tak jak nie jest
> dopuszczalne dowolne wyrazenie (a jedynie consts expr) w
> deklaracji rozmiaru tablicy, czy w dyrektywach preprocesora

Mozna by to wprowadzic juz na poziomie gramatyki np. tak:

Jest (ANSI-C/C99):

/* (6.5.3) */
unary_expression :
postfix_expression ${action Actions.token0} |
'++' unary_expression ${action Actions.prefix_increment_expression} |
'--' unary_expression ${action Actions.prefix_decrement_expression} |
/* unary_operator cast_expression */
'&' cast_expression ${action Actions.address_expression} |
'*' cast_expression ${action Actions.indirection_expression} |
'+' cast_expression ${action Actions.unary_plus_expression} |
'-' cast_expression ${action Actions.unary_minus_expression} |
'~' cast_expression ${action Actions.bitwise_NOT_expression} |
'!' cast_expression ${action Actions.logical_NOT_expression} |
'sizeof' unary_expression ${action Actions.sizeof_expression} |
'sizeof' '(' type_name ')' ${action Actions.sizeof_type_expression} ;

Moglo by byc w rodzaju:

/* (6.5.3) */
sizeof_expression :
postfix_expression ${action Actions.token0} |
/* unary_operator cast_expression */
'&' cast_expression ${action Actions.address_expression} |
'*' cast_expression ${action Actions.indirection_expression} |
'+' cast_expression ${action Actions.unary_plus_expression} |
'-' cast_expression ${action Actions.unary_minus_expression} |
'~' cast_expression ${action Actions.bitwise_NOT_expression} |
'!' cast_expression ${action Actions.logical_NOT_expression} |
'sizeof' sizeof_expression ${action Actions.sizeof_expression} |
'sizeof' '(' type_name ')' ${action Actions.sizeof_type_expression} ;

/* (6.5.3) */
unary_expression :
sizeof_expression ${action Actions.token0} |
'++' unary_expression ${action Actions.prefix_increment_expression} |
'--' unary_expression ${action Actions.prefix_decrement_expression} ;

PS: Noi?
PS1: Nie wiem czy by to nie zabuzylo priorytetu operatorow (nie chce mi
sie sprawdzac, ale na 90% nie), ale nawet gdyby, to zawsze to mozna
uskutecznic semantycznie (juz w AST).

AK

do góry

W dniu poniedziałek, 14 stycznia 2019 10:07:01 UTC+1 użytkownik AK napisał:
> On 2019-01-14 09:37, Wojciech Muła wrote:
> > On Sunday, January 13, 2019 at 5:34:26 PM UTC+1, AK wrote:
> >> 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).
> >
> > Nie rozumiem w czym te operatory przeszkadzają.
>
> No bez jaj. Przeszkadzaja, gdyz tak wlasciwie nie dzialaja
> w sizeof, a jedynie wprowadzaja w blad/konfuzje (8 zamiast 9)
> developerow.
> Nie powinny byc w sizeof dopuszczalne, tak jak nie jest
> dopuszczalne dowolne wyrazenie (a jedynie consts expr) w
> deklaracji rozmiaru tablicy, czy w dyrektywach preprocesora

To nie język wprowadza konfuzję developerów, tylko użycie go.
I jeszcze nie wymyślono takiego języka, w którym nie dałoby się
wprowadzać czytelnika w konfuzję.

Ja nie mam problemu z tym, żę sizeof(i++) jest dopuszczalne w języku,
ale +1 na code review bym za to nie dał.

Weźmy nawet mniej egzotyczny przykład:

int add(int a, int b) {
return a - b;
}

Jeśli ktoś by miał twierdzić, że "C to kiepski język, bo umożliwia
pisanie głupot tego rodzaju", to ja mogę tylko załamać ręce.

do góry

On 2019-01-14 10:49, g...@g...com wrote:
>
> To nie język wprowadza konfuzję developerów, tylko użycie go.

Jesli jezyk dozwala na jawny idiotyzm to wprowadza konfucje.
Tak jak sam krzywy mlotek wprowadza rzezbiarza w konfuzje,
a nie uzycie go w "krzywy sposob".

> I jeszcze nie wymyślono takiego języka, w którym nie dałoby się
> wprowadzać czytelnika w konfuzję.

To prawda.
Jednak kazdy Ci powie, ze Mercedes (choc nie idealny, A-iles_tam
sie przewracal:), jest jednak lepszy od jakiegos Tico.
Podobnie z j.prog. Nnie ma idealnych, ale sa (niekiedy zdecydowanie)
lepsze i (niekiedy zdecydowanie) gorsze.

> Ja nie mam problemu z tym, żę sizeof(i++) jest dopuszczalne w języku,
> ale +1 na code review bym za to nie dał.
>
> Weźmy nawet mniej egzotyczny przykład:
>
> int add(int a, int b) {
> return a - b;
> }

Tu jest falsz swiadomy (add samiast sub)
a tu ? sizeof(i++) co tu trąci falszem?
W dobrej wierze napisana calkiem naturalna konstrukcja.

> Jeśli ktoś by miał twierdzić, że "C to kiepski język, bo umożliwia
> pisanie głupot tego rodzaju", to ja mogę tylko załamać ręce.

To se zalamuj i zyj w ułudzie (wyimaginowanym swiecie nieprodukcyjnej
z jednej strony "czystosci" - List, a z drugiej totalnej tolerancji
na dziadowstwo typu x++ w sizeof).

AK

do góry

W dniu poniedziałek, 14 stycznia 2019 11:04:30 UTC+1 użytkownik AK napisał:

> > To nie język wprowadza konfuzję developerów, tylko użycie go.
>
> Jesli jezyk dozwala na jawny idiotyzm to wprowadza konfucje.
> Tak jak sam krzywy mlotek wprowadza rzezbiarza w konfuzje,
> a nie uzycie go w "krzywy sposob".
>
> > I jeszcze nie wymyślono takiego języka, w którym nie dałoby się
> > wprowadzać czytelnika w konfuzję.
>
> To prawda.
> Jednak kazdy Ci powie, ze Mercedes (choc nie idealny, A-iles_tam
> sie przewracal:), jest jednak lepszy od jakiegos Tico.

Zależy do czego. Mercedesem nie wszędzie zaparkujesz.
I części zamienne są drogie, jak Ci się coś zepsuje.

> Podobnie z j.prog. Nnie ma idealnych, ale sa (niekiedy zdecydowanie)
> lepsze i (niekiedy zdecydowanie) gorsze.
>
> > Ja nie mam problemu z tym, żę sizeof(i++) jest dopuszczalne w języku,
> > ale +1 na code review bym za to nie dał.
> >
> > Weźmy nawet mniej egzotyczny przykład:
> >
> > int add(int a, int b) {
> > return a - b;
> > }
>
> Tu jest falsz swiadomy (add samiast sub)
> a tu ? sizeof(i++) co tu trąci falszem?
> W dobrej wierze napisana calkiem naturalna konstrukcja.

Podaj mi kontekst, w którym ktoś chciałby napisać "sizeof(i++)"

do góry

On 2019-01-14 11:41, g...@g...com wrote:
> Podaj mi kontekst, w którym ktoś chciałby napisać "sizeof(i++)"

Co ma za znaczenie kontekst?
Jesli cus mozna, to takie cus niejeden developer sobie na pewno uzyje.

Np. zamiast chocby tak:

#include <stdlib.h>
#include <stdio.h>

int main()
{
int tab[] = {1, 2, 3, 4, 5, 9999};
// ...
int* ptr = tab;
while ( *ptr != 9999 )
{
printf("%d\n", *ptr);
typeof(ptr) item = malloc(sizeof(*ptr)); ptr++;
// ...
}
}

zrobi tak:

#include <stdlib.h>
#include <stdio.h>

int main()
{
int tab[] = {1, 2, 3, 4, 5, 9999};
// ...
int* ptr = tab;
while ( *ptr != 9999 )
{
printf("%d\n", *ptr);
typeof(ptr) item = malloc(sizeof(*ptr++));
// ...
}
}

bo przecie krocej i ladniej :)
No i mamy klasyczny "zwis"/nieskonczona petle.

AK

do góry

On Monday, January 14, 2019 at 10:07:01 AM UTC+1, AK wrote:
> On 2019-01-14 09:37, Wojciech Muła wrote:
> > On Sunday, January 13, 2019 at 5:34:26 PM UTC+1, AK wrote:
> >> 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).
> >
> > Nie rozumiem w czym te operatory przeszkadzają.
>
> No bez jaj. Przeszkadzaja, gdyz tak wlasciwie nie dzialaja
> w sizeof, a jedynie wprowadzaja w blad/konfuzje (8 zamiast 9)
> developerow.

"... developerów, którzy nie rozumieją jak działa sizeof/decltype/etc."

Jeśli ktoś nie rozumie, że sizeof bierze **typ wyrażenia**
bez liczenia go, to trudno mieć pretensje do języka. O ile
w C to jeszcze Twoja propozycja miałaby sens, to w C++ jest
nie do zaakceptowania, bo można przeciążać operatory. Wyrażenie
"x++" może mieć inny typ niż samo "x".

w.

do góry

W dniu 12.01.2019 o 11:46, g...@g...com pisze:
> http://www.stroustrup.com/P0977-remember-the-vasa.pd
f
>
W dniu 12.01.2019 o 11:46, g...@g...com pisze:>
http://www.stroustrup.com/P0977-remember-the-vasa.pd
f
> A w ogóle gdzie ten przykład na sizeof, bo plik
P0977-remember-the-vasa.pdf to katalog innych dokumentów

do góry