🚀 go-pugleaf

On Sat, 03 Nov 2007 10:47:38 +0100, Hoobert wrote:

> Natkąłem się na takie coś: www.fefe.de/c++/c++-talk.pdf W sumie nic
> nowego, ale kilka rzeczy dość fajnie pokazanych jest. Jak dla mnie
> przykład z foo->bar w części "C++ is hard to read" jest dość wymowny.

1. Warm-up. 'Błąd' kompilatora (tzn. brak zwijania templatów). Chyba jest 
planowane załatanie
2. Ever Changing Style. Pierwsze się chyba nadal stosuje do zwykłych petli 
a drugie do iteratorów.
3. C++ is hard to parse. Kompilatory (m. innymi używany przez autora g++) 
mają zabezpiecznie np, do 100 iteracji
4. C++ is hard to parse. Każdy język zapisany ciagłym kodem i 
niezalecanymi własciwościami jest nieczytelny. A czytelności nieczytalnego 
algorytmu język nie poprawi...
5. C++ is hard to parse. (foo) + a*b. cos(ab) powinno być równoważen 
a*b*c*o*s. A nie jest ;)
6. C++ is hard to write. Rozpacz, że cin kowertuje się do void *. Wynika z 
założeń kompatybilności z C. Kompatybilność z C jest potrzebna (chyba, że 
ktoś kocha pisać wrappery).
7. Iterators and their Containers. Don’t know anything about the container.
a) Co jeśli nie są związane z kontenerem tylko iterują między np. 1 a 6 
(dlaczego nie)?
b) Co jeśli mamy merge_iterator(begin1, end1, begin2, end2) który iteruje 
między begin1 aż do end1 (wyłącznie) a potem od begin2 do end2?
8. Bounds Checking. Szkoda, że programista może wybrać szybki nóż, którym 
może się pokaleczyć. Najlepiej mu go zabrać ;)
9. Virtual functions in con/destructor. Można prosić o rozwiązanie 
problemu bez odwoływania się do 'nieprzyzwoitej wiedzy' obiektu potomnego 
o rodzicu?

class A
{
protected:
  int x;
  int y;
public:
  virtual int
  a()
  {
    return 0;
  }
  virtual int
  b()
  {
    return 0;
  }
  A()
  {
    x = a();
    y = b();
  }
}

class B : public A
{
public:
  virtual int
  a()
  {
    return y; //Ops. A nie jest gotowe...
  }
}

Klasa B ma gwarancje w ten sposób, że obiekt A jest gotowy.

9. Virtual functions in con/destructor. Jak wyżej. Ponieważ klasa potomna 
używa klasy nadrzędnej jest niszczona jako pierwsza. A potem chcemy 
wywołać funkcję zniszczonego obiektu :)
Circullar Dependences to zawsze problem ale autor powinien zaprezentować 
jakieś sensowne wyjście jak krytykuje (bo istnieje).

10. C++ is hard to write. Tak. Najlepiej przy wywołaniu każdej funkcji 
podajmy typy parametrów. Jakimś dziwnym trafem języki ewoluują w 
przeciwnym kierunku.

11. C++ is hard to write. O using namespace whatever;. Zapomnieli dopisać 
but shouldn't.

12. C++ is hard to write. Tak zapomnijmy o polimorfizmie. Patrz ostatnie 
zdanie 10.

13. Zdania mówiące wszystko:
Obviously, there could be preprocessor tricks.
Those are in C, too, and I like C, so I’m not bashing them here.
I do agree that they need some bashing.

13. C++ makes auditing painful. Na temat audytu referencji:
int test(int &tmp);

int test2() {
  int i;
  return test((const int)i);
}

Jak jest int test(int tmp); to nie wyrzuci błędu

Nie przepadam za C++ - cześciowo z powodów wymienionych w tekście. Ale nie 
sądze, żeby dużo z wymienionych powodów dało się wyeliminować bez 
dodatkowych narzutów czasowych (także dla przypadków skrajnych które 
prawie nigdy nie występują).

Pozdrawiam
-- 
I've probably left my head... somewhere. Please wait untill I find it.
Homepage (pl_PL): http://uzytkownik.jogger.pl/
(GNU/)Linux User: #425935 (see http://counter.li.org/)