Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #32329 > unrolled thread

Stroustrup o C++

Back to article view | Back to pl.comp.programming

Contents

  Stroustrup o C++ godek.maciek@gmail.com - 2019-01-12 02:46 -0800
    Re: Stroustrup o C++ AK <nobody@nowhere.net> - 2019-01-12 17:52 +0100
      Re: Stroustrup o C++ szykcech@gmail.com - 2019-01-12 10:37 -0800
        Re: Stroustrup o C++ Wojciech Muła <wojtek.mula@gmail.com> - 2019-01-12 11:48 -0800
          Re: Stroustrup o C++ A S <asta@evbox.pl> - 2019-01-13 06:13 +0100
          Re: Stroustrup o C++ AK <nobody@nowhere.net> - 2019-01-13 12:01 +0100
            Re: Stroustrup o C++ Wojciech Muła <wojtek.mula@gmail.com> - 2019-01-13 04:19 -0800
              Re: Stroustrup o C++ AK <nobody@nowhere.net> - 2019-01-13 17:34 +0100
                Re: Stroustrup o C++ AK <nobody@nowhere.net> - 2019-01-13 17:36 +0100
                Re: Stroustrup o C++ Wojciech Muła <wojtek.mula@gmail.com> - 2019-01-14 00:37 -0800
                  Re: Stroustrup o C++ AK <nobody@nowhere.net> - 2019-01-14 10:06 +0100
                    Re: Stroustrup o C++ AK <nobody@nowhere.net> - 2019-01-14 10:48 +0100
                    Re: Stroustrup o C++ godek.maciek@gmail.com - 2019-01-14 01:49 -0800
                      Re: Stroustrup o C++ AK <nobody@nowhere.net> - 2019-01-14 11:04 +0100
                        Re: Stroustrup o C++ godek.maciek@gmail.com - 2019-01-14 02:41 -0800
                          Re: Stroustrup o C++ AK <nobody@nowhere.net> - 2019-01-14 13:22 +0100
                        Re: Stroustrup o C++ queequeg@trust.no1 (Queequeg) - 2019-01-18 13:05 +0000
                    Re: Stroustrup o C++ Wojciech Muła <wojtek.mula@gmail.com> - 2019-01-14 07:33 -0800
                      Re: Stroustrup o C++ AK <nobody@nowhere.net> - 2019-01-14 17:42 +0100
                        Re: Stroustrup o C++ AK <nobody@nowhere.net> - 2019-01-14 17:48 +0100
                        Re: Stroustrup o C++ Wojciech Muła <wojtek.mula@gmail.com> - 2019-01-14 10:53 -0800
                          Re: Stroustrup o C++ AK <nobody@nowhere.net> - 2019-01-15 15:02 +0100
                            Re: Stroustrup o C++ Wojciech Muła <wojtek.mula@gmail.com> - 2019-01-15 13:56 -0800
                              Re: Stroustrup o C++ AK <nobody@nowhere.net> - 2019-01-16 00:36 +0100
                                Re: Stroustrup o C++ Wojciech Muła <wojtek.mula@gmail.com> - 2019-01-18 16:08 -0800
                                  Re: Stroustrup o C++ AK <nobody@nowhere.net> - 2019-01-19 02:18 +0100
          Re: Stroustrup o C++ AK <nobody@nowhere.net> - 2019-01-13 12:10 +0100
        Re: Stroustrup o C++ AK <nobody@nowhere.net> - 2019-01-13 12:13 +0100
        Re: Stroustrup o C++ queequeg@trust.no1 (Queequeg) - 2019-01-18 12:50 +0000
      Re: Stroustrup o C++ queequeg@trust.no1 (Queequeg) - 2019-01-18 15:45 +0000
        Re: Stroustrup o C++ Wojciech Muła <wojtek.mula@gmail.com> - 2019-01-18 15:59 -0800
          Re: Stroustrup o C++ queequeg@trust.no1 (Queequeg) - 2019-01-19 11:03 +0000
            Re: Stroustrup o C++ Sebastian Biały <heby@poczta.onet.pl> - 2019-01-19 21:18 +0100
              Re: Stroustrup o C++ fir <profesor.fir@gmail.com> - 2019-01-20 04:04 -0800
                Re: [OT] Stroustrup o C++ Sebastian Biały <heby@poczta.onet.pl> - 2019-01-20 17:05 +0100
                  Re: [OT] Stroustrup o C++ fir <profesor.fir@gmail.com> - 2019-01-20 10:25 -0800
                    Re: [OT] Stroustrup o C++ queequeg@trust.no1 (Queequeg) - 2019-01-20 20:56 +0000
                  Re: [OT] Stroustrup o C++ queequeg@trust.no1 (Queequeg) - 2019-01-20 20:54 +0000
                    Re: [OT] Stroustrup o C++ fir <profesor.fir@gmail.com> - 2019-01-20 13:40 -0800
              Re: Stroustrup o C++ queequeg@trust.no1 (Queequeg) - 2019-01-20 20:49 +0000
                Re: Stroustrup o C++ Sebastian Biały <heby@poczta.onet.pl> - 2019-01-20 22:55 +0100
                  Re: Stroustrup o C++ queequeg@trust.no1 (Queequeg) - 2019-01-21 10:42 +0000
    Re: Stroustrup o C++ Borneq <borneq@antyspam.hidden.pl> - 2019-01-14 16:38 +0100

Page 1 of 3  [1] 2 3  Next page →

#32329 — Stroustrup o C++

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

[toc] | [next] | [standalone]

#32330

On 2019-01-12 11:46, godek.maciek@gmail.com wrote:
> http://www.stroustrup.com/P0977-remember-the-vasa.pdf

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

[toc] | [prev] | [next] | [standalone]

#32331

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

[toc] | [prev] | [next] | [standalone]

#32332

On Saturday, January 12, 2019 at 7:37:22 PM UTC+1, szyk...@gmail.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.

[toc] | [prev] | [next] | [standalone]

#32335

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

[toc] | [prev] | [next] | [standalone]

#32336

On 2019-01-12 20:48, Wojciech Muła wrote:
> On Saturday, January 12, 2019 at 7:37:22 PM UTC+1, szyk...@gmail.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

[toc] | [prev] | [next] | [standalone]

#32339

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, szyk...@gmail.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.

[toc] | [prev] | [next] | [standalone]

#32340

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, szyk...@gmail.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

[toc] | [prev] | [next] | [standalone]

#32341

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

AK

[toc] | [prev] | [next] | [standalone]

#32346

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.

[toc] | [prev] | [next] | [standalone]

#32348

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

[toc] | [prev] | [next] | [standalone]

#32351

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

[toc] | [prev] | [next] | [standalone]

#32352

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.

[toc] | [prev] | [next] | [standalone]

#32353

On 2019-01-14 10:49, godek.maciek@gmail.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

[toc] | [prev] | [next] | [standalone]

#32354

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++)"

[toc] | [prev] | [next] | [standalone]

#32355

On 2019-01-14 11:41, godek.maciek@gmail.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

[toc] | [prev] | [next] | [standalone]

#32395

AK <nobody@nowhere.net> wrote:

> Jednak kazdy Ci powie, ze Mercedes (choc nie idealny, A-iles_tam
> sie przewracal:), jest jednak lepszy od jakiegos Tico.

Zależy w jakich kategoriach go oceniasz. Jeśli szukasz samochodu, który 
będzie tani (w zakupie i w eksploatacji), to 10-letnie, małolitrażowe Tico 
będzie lepsze od wypasionego Mercedesa.

Wybór między Mercedesem i Tico to sztuka kompromisu tak samo, jak wybór 
języka programowania.

> Podobnie z j.prog. Nnie ma idealnych, ale sa (niekiedy zdecydowanie)
> lepsze i (niekiedy zdecydowanie) gorsze.

Wg mnie, jeśli poruszamy się wśród "mainstreamowych" języków, to zależy to 
głównie od konkretnego zastosowania.

Gdy musiałem zrobić webserwis, to mimo zerowego doświadczenia z C# 
wybrałem właśnie ten język, zamiast trzymać się C++, w którym piszę 
najwięcej. 

-- 
https://www.youtube.com/watch?v=9lSzL1DqQn0

[toc] | [prev] | [next] | [standalone]

#32356

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.

[toc] | [prev] | [next] | [standalone]

#32358

On 2019-01-14 16:33, Wojciech Muła wrote:
> 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."

Bo trudno zrozumiec idiotyzm tego sizeofowego wyjatku.

> Jeśli ktoś nie rozumie, że sizeof bierze **typ wyrażenia**
> bez liczenia go, to trudno mieć pretensje do języka.

Mozna, zwlaszcza ze (jak pokazalem) mozna go _bardzo latwo_ uniknac
przez gramatyke.
Bo ++ (-- itp) w sizeof nie maja _najmniejszego sensu_.
Dlatego powinny byc zwyczajnie zabronione.

> 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".

Tak?. No cos podobnego!?
Bo mi sie zawsze wydawalo, ze taki ++ to posiada obligatoryjne
sygnatury:
Klasa& Klasa::operator++(); // dla ++x
Klasa  Klasa::operator++(); // dla x++

AK

[toc] | [prev] | [next] | [standalone]

#32359

On 2019-01-14 17:42, AK wrote:
> Klasa  Klasa::operator++(); // dla x++
oczywiscie:
Klasa  Klasa::operator++(int); // dla x++

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | pl.comp.programming

csiph-web