|
|
 Up |
|
|
  |
Author: Stefan ReutherStefan Reuther Date: Jul 6, 2007 09:44
'n abend,
Felix von Leitner wrote:
> Thus spake Stefan Reuther (stefan.news@arcor.de):
>>C++-spezifisch ist sowas wie
>> typ(foo[riesen_ausdruck])
>>Geht die Zeile z.B. mit '+3' weiter, wird da 'foo[riesen_ausdruck]' nach
>>'typ' gecastet und 3 addiert. Geht die Zeile mit ';' weiter, wird eine
>>neue Arrayvariable eingeführt.
>
> Das ist zwar widerlich, aber das kann man sich angewöhnen, und dann
> sieht man das mit einem Blick.
Du frugst nach Dingen, die eklig zu parsen sind, und sowas ist ächt[tm]
eklig zu parsen, mit "1 Token Lookahead" kommt man da lange nicht mehr hin.
> Ich meine so Sachen wie eine Codezeile,
> die völlig harmlos aussieht, aber bei näherer Betrachtung siehst du
> dann, daß du diese komplette Datei und fünfzehn andere Dateien komplett
> gelesen haben mußt, um diese eine Zeile verstehen zu können.
Man kann fast komplett neue Syntax erfinden. Zum Beispiel Boost.Lambda.
Sowas mit reinem Code-Studium zu erschließen, könnte schwierig werden.
|
| Show full article (7.81Kb) |
|
| | 49 Comments |
|
|
Author: Arnim SommerArnim Sommer Date: Jul 6, 2007 12:06
Stefan Reuther schrieb:
[...]
> Nach einem geeigneten LART wird noch gesucht.
>
- ausdrucken
- kleinschreddern
- in Spiritus auflösen
- als Einlauf verabreichen
- mit einem brennenden Streichholz nachschauen, ob der Schließmuskel noch
funktioniert
A!S
--
In der Kirche singen immer die am lautesten, die falsch singen.
-- Franz Grillparzer
|
| |
|
| | no comments |
|
|
Author: Lothar KimmeringerLothar Kimmeringer Date: Jul 6, 2007 12:28
Andre Bialojahn wrote:
> Blöd nur, dass die Prüfung der IDE das anmeckert, weil die Parameter
> *eigentlich* ja ganz anders heißen. So kommt man dann zu Code mit
> 8000 Warnings. Von den Methoden ganz ohne Javadoc gar nicht erst zu
> sprechen.
Toll ist dann auch, wenn sich drei Klassen ploetzlich im Repository
aendern, weil besagter Entwickler dann einen unbenutzten import
herausloescht, weil ihm das die IDE als Warnung anzeigt, waehrend
man selbst am rechten Rand einen schoenen gelben Strich stehen hat
(bis auf ganz oben ein halber Millimeter).
Gruesse, Lothar
--
Lothar Kimmeringer E-Mail: spamfang@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)
Always remember: The answer is forty-two, there can only be wrong
questions!
|
| |
| no comments |
|
|
Author: Felix von LeitnerFelix von Leitner Date: Jul 6, 2007 13:59
Thus spake Stefan Reuther (stefan.news@arcor.de):
>> Das ist zwar widerlich, aber das kann man sich angewöhnen, und dann
>> sieht man das mit einem Blick.
> Du frugst nach Dingen, die eklig zu parsen sind, und sowas ist ächt[tm]
> eklig zu parsen, mit "1 Token Lookahead" kommt man da lange nicht mehr hin.
Ich stimme zu, C++ Parsen ist ein hartes Problem.
Aber als Mensch hat man mehr als ein Token Lookahead.
>> Ich meine so Sachen wie eine Codezeile,
>> die völlig harmlos aussieht, aber bei näherer Betrachtung siehst du
>> dann, daß du diese komplette Datei und fünfzehn andere Dateien komplett
>> gelesen haben mußt, um diese eine Zeile verstehen zu können.
> Man kann fast komplett neue Syntax erfinden. Zum Beispiel Boost.Lambda.
> Sowas mit reinem Code-Studium zu erschließen, könnte schwierig werden.
Au weia, das hab ich noch gar nicht wahr genommen.
Danke für den Hinweis!
> Und dann gibt's noch benannte Infix-Operatoren a la Haskell:
> Vector v, a, b;
> v = a /vectorProduct/ b;
Oh Graus!
|
| Show full article (7.94Kb) |
| no comments |
|
|
Author: Felix von LeitnerFelix von Leitner Date: Jul 6, 2007 14:04
Thus spake Ulrich Witte (u.witte@gmx.de):
> Das ist dann der sog. selbstdokumentierende Code. Der besteht im
> üblichen aus Variablen, die char *p, char buf[256], int i und
> long l heißen. Funktionen heißen void transbuf(char *s) oder
> so.
Jetzt mußte ich doch mal kurz nach transbuf greppen gerade *hust*
Felix
|
| |
| no comments |
|
|
Author: Ulrich EckhardtUlrich Eckhardt Date: Jul 6, 2007 23:47
Felix von Leitner wrote:
> Thus spake Stefan Reuther (stefan.news@arcor.de):
>> bool operator<(const A&, const A&) { return rand() & 1; }
>> d
|
| |
| no comments |
|
|
Author: Volker BirkVolker Birk Date: Jul 7, 2007 02:44
Stefan Reuther wrote:
> Das "Killerfeature" von C++ gegenüber den sogenannten C++-Nachfolgern
> (Java, C#, D) ist IMHO das Vorhandensein von Headerfiles, was das Lesen
> von Code sehr vereinfacht.
Kein Importkonzept zu haben halte ich kaum für ein Feature.
> A propos map: 'if (m[x] == 0)' legt dir selbstverständlich das Element
> 'x' in der map an, falls es noch nicht drin ist.
Dafür gibt's find().
>>>Letztenendes halte ich C++ immer noch für die am wenigsten stinkende
>>>halbwegs portable ernsthafte Programmiersprache. Alles andere ist nur in
>>>der Theorie portabel und/oder verfügbar.
>> A...aber C#!1!! :-)
> Portabel? Verfügbar?
|
| Show full article (1.11Kb) |
| no comments |
|
|
Author: Felix von LeitnerFelix von Leitner Date: Jul 7, 2007 09:15
Thus spake Ulrich Eckhardt (doomster@knuut.de):
> Kannst Du ganz einfach nachlesen, ueber Alex Stepanov (sp?) gibt es viele
> interessante Infos im Netz. Kurz, der Grund ist Performance. Eine einfache
> for-Schleife ueber einen vector zu vergeigen ist auch einfach zu
> unwahrscheinlich als dass ich auch nur einen Taktzyklus dafuer opfern
> wuerde. Ansonsten gilt natuerlich dass selbe wie bei dem Komparator fuer
> std::map, moderne Implementierungen fangen sowas im Debug-Modus ab.
Blödsinn. Denn: der Compiler optimiert das raus.
Beispiel-Code zum selber gucken:
for (i=0; i<20; ++i) {
if (i<100) // immer wahr, erzeugt keinen Code
printf("i=%%d\n",i);
}
Da wir es hier mit einer Template-Bibliothek zu tun haben, liegen auch
konkrete Werte vor, und der Compiler kann redundante Range Checks
entfernen.
|
| Show full article (1.79Kb) |
| no comments |
|
|
Author: Stefan ReutherStefan Reuther Date: Jul 7, 2007 09:51
Felix von Leitner wrote:
> Thus spake Stefan Reuther (stefan.news@arcor.de):
>>Ja, mich hat das schon gestört, aber die Vorteile (eine Referenz kann
>>halt nicht NULL sein) überwiegen für mich.
>
> Eine Referenz kann trotzdem z.B. auf zwischenzeitlich freigegebenen
> Speicherplatz verweisen oder so. Insofern hilft das nur auf dem Papier.
Es hilft, wenn man Regeln aufstellt und sich daran hält (z.B. "in
Datenstrukturen eingetragene Objekte werden nur zum Zeitpunkt X, Y, und
Z zerstört" und "nur Funktionen A, B, C dürfen eine Referenz auf das als
Parameter übergebene Objekt permanent speichern"). Hilft dir natürlich
beim Audit nicht.
>> bool operator<(const A&, const A&) { return rand() & 1; }
>>dürfte eine std::map recht verlässlich abschießen (mit dem
>>Äquivalent davon hab ich allerdings auch schon Solaris' qsort zerlegt).>
> Ja, so ähnlich. Aber das finde ich "zu einfach", weil es operator
> overloading beinhaltet. Das ist ja schon fast ein Klischee, auf
> operator overloading rumzuhauen.
|
| Show full article (4.56Kb) |
| no comments |
|
|
|
|
|
Author: Stefan ReutherStefan Reuther Date: Jul 7, 2007 09:56
Felix von Leitner wrote:
> Thus spake Ulrich Eckhardt (doomster@knuut.de):
>>Du hast in basic_string<>:
>
>> char& operator[]( size_type n);
>> char const& operator[]( size_type n) const;
>
>>also einen ueberladenen Operator fuer konstante und nicht-konstante Objekte.
>>1. Wenn moeglich, wird immer der nicht-konstante aufgerufen.
>
> Wie auch in diesem Fall, unabhängig davon ob s jetzt lesbar ist oder
> nicht, denn der konkrete Zugriff ist lesend.
Wir machen aber keine Typinferenz a la Haskell ("das Ergebnis ist ein
const char, also rufen wir die const-Methode auf"), sondern die Typen
werden schön von innen nach außen aufgelöst: 's' ist std::string, und
damit ist die am besten passende []-Methode die, die einen 'string*' als
this-Pointer hat, nicht die mit dem 'const string*'.
|
| Show full article (1.45Kb) |
| no comments |
|
RELATED THREADS |
|
|
|
|
|
|
