ZFX + Developia

Verfasst: **19.07.2010, 09:13**

Wenn du unter mehreren Betriebssystemen entwickeln willst, mußt du dich beim C++-Code halt an den Standard halten. Das macht der MSVC-Compiler leider nicht überall, weswegen solche Dinge wie #pragma once entstanden sind. Hüte dich einfach vor MS-spezifischen Konstrukten. Die machen beim Portieren mehr Ärger und bringen dafür meist nicht viel Nutzen.
Auch der Vorteil von #pragma once gegenüber Includeguards beschränkt sich summa-summarum auf nur 2 Zeilen Codeersparnis.

Gruß Kimmi

Verfasst: **19.07.2010, 10:06**

Du hast Recht, für alle Projekte die ab jetzt entworfen werden.
Aber w.s.w.g. ich habe bisher nur unter VS entwickelt und da ist nun mal 'tonnenweise' Material vorhanden.
Das umzuarbeiten macht eben viel Arbeit (reine 'Handarbeit') und ich wollte doch meine Ideen programmieren und
nicht die Vergangenheit überarbeiten. :!:

Edit:
Eigentlich finde ich #pragma once einfacher und leichter zu handhaben als die 'GUARD'-Methode und
für die weltoffenen Linux- und gcc-Entwickler dürfte es kein Problem sein, diese Funktionalität
mit einzubauen. Ich bin ja mit diesem Problem nicht allein auf dieser Welt (siehe GOOGLE).
Es hat den Standard noch nie gestört, wenn mehr als vordefiniert möglich ist. Im Gegenteil, die Entwicklung soll
ja durch Standards nicht behindert werden, oder?

PS:
w.s.o.g: wieschonwiederholtgesagt

Verfasst: **19.07.2010, 10:37**

Zur Zeit wird es aber nicht unterstützt und dementsprechend wirst du es wohl anpassen müssen, wenn du deinen Code portieren willst. Da führt kein Weg daran vorbei.
Das ist der Grund, warum ich bei neuem Code immer gern auf Portabilität achtgebe. Wer weiß schon, ob man den irgendwann einmal portieren darf. Auch ich habe da schon ordentlich Handarbeit investieren müssen.

Gruß Kimmi

Verfasst: **19.07.2010, 11:09**

HeinzK hat geschrieben:Eigentlich finde ich #pragma once einfacher und leichter zu handhaben als die 'GUARD'-Methode und
für die weltoffenen Linux- und gcc-Entwickler dürfte es kein Problem sein, diese Funktionalität
mit einzubauen.

Das Standardkommitte verfolgt die (sinnvolle) Taktik, Funktionalität durch Recycling bestehender Sprachfeatures einzubauen anstatt dauernd neue Schlüsselwörter einzubauen. Das bedeutet auf diesen Fall übertragen: #ifdef #ifndef #elif #endif #define an sich machen 85 % der Präprozessor-Funktionalität aus. Würde #pragma once standardisiert, würde der Umfang der Sprache um 15 % wachsen um 0 % mehr Funktionalität zu erlauben als eh schon möglich ist und hier und da zwei Zeilen zu sparen. Indiskutabel.

Darüber hinaus ist #pragma afaik schon standardisiert als: „Was jetzt kommt, bestimmt der Compiler. Wenn er nichts damit anzufangen weiß, soll er schlucken statt kotzen.“ Und afaik war das auch eine der Entscheidungen, die im Großen und Ganzen als falsch angesehen wird.

Verfasst: **19.07.2010, 11:14**

Soweit, so gut. Warnen ist ja OK, aber man sollte diese Warnung dann auch gezielt abschalten können.
Nächste Frage: Unter VS ist beim Debuggen ein Symbol _DEBUG gesetzt.
Das schein bei gcc nicht der Fall zu sein. Ich habe es in den 'Build-Options' nun nachträglich gesetzt.
Jetzt funktioniert alles wie gewollt. Frage, wie erkennt gcc Debug und Release?

Verfasst: **19.07.2010, 13:12**

Beim gcc werden die Debuginfos in die Objects miteinkompiliert ( -g meine ich ). Wenn du -g setzt, kannst du im Makefile mittels -D_DEBUG ( -d oder -D, such mal nach der richtigen Option ) dir die entsprechenden Debug-Präprozessoranweisungen selber vom gcc setzen lassen. Der gcc an sich kennt halt nur Sourcefiles und keine Workspaces.

Gruß Kimmi

Verfasst: **19.07.2010, 13:31**

Es geht mir nicht um die compilereigenen Objekte. Ich habe ein paar selbstdefinierte Bereiche
die ich mit

Code: Alles auswählen

#ifdef _DEBUG machwas #else machwasanderes #endif

abwickle. Das _DEBUG ist
mit so in Fleisch und Blut, das ich gar nicht auf die Idee komme, irgenwo anders könnte es wirklich anders sein!
Will eigentlich nur wissen, ob _DEBUG nicht vordefiniert ist, oder ob ich etwas falsch gemacht habe.

Verfasst: **19.07.2010, 14:47**

Du kannst im Compile-Vorgang gcc mittels der Option -D das Symbol _DEBUG setzen. Dann geht dein Debugcode wie gewohnt.

Gruß Kimmi

Verfasst: **20.07.2010, 21:30**

Code: Alles auswählen

double KFlinkWurzelExB(const double &dWert)
{
    double dWrt = fabs(dWert);
    if (dWrt < FLT_MAX)
    {
      float fWrt = (float)dWert;
      if (!(fWrt > 0.0))
      {
        return 0.0;
      }
      double dWu1 = (0.5 * dWrt);

      unsigned long *p = (unsigned long *)&fWrt;
      *p = (0xbe6f0000 - *p) >> 1;

      double dWu2 = (double)(fWrt);
      dWu2 *= (1.5 - (dWu2 * dWu2 * dWu1));
      dWu2 *= (1.5 - (dWu2 * dWu2 * dWu1));
      dWrt *= dWu2;
    } else
    {
      dWrt = KWurzel(dWrt);
    }
    return dWrt;
 }
double dX = 4.0;
dX = KFlinkWurzelExB(dX);

unsigned long *p = (unsigned long *)&fWrt;
*p = (0xbe6f0000 - *p) >> 1;
warnung dereferencing pointer 'p' does break strict-aliasing rules
Zuerst mal, dies ist eine alte nicht mehr benutzte Routine. Sie rechnete früher die ungefähre Wurzel viel schneller als sqrt().
Also die Routine ist im Quellcode noch enthalten, aber wird nicht mehr benutzt. Deshalb ist das Problem nicht so wichtig.
gcc: Im Debug-Modus wird alles ohne Warnung kompiliert, aber im Release-Modus kommt die o.a. Warnung.
Kann mir jemand den Grund der Warnung erklären (rein interessehalber).

Verfasst: **20.07.2010, 21:38**

Es ist undefiniert auf die gleiche Speicherstelle von 2 Pointern unterschiedlichen Typs aus zuzugreifen - der Sprachstandard trifft diese Regelung um Optimizern die Arbeit zu erleichtern (vom Prinzip her verwandt mit restrict). Da nahezu jede Bithackerei in dieses Problem rennt, geht GCC natuerlich korrekt damit um, sprich der Code laeuft allenfalls langsamer als er koennte, aber nicht anders oder falsch. Dennoch ist die Warnung berechtigt.

Code: Alles auswählen

int a, *pa = a, &a;

float* pf = reinterpret_cast<float*>(pa);
*pf = 4.0f;

Die letzte Zeile im Beispiel bricht die Aliasing-Regeln.

Verfasst: **20.07.2010, 21:39**

Aliasing nennt man es, wenn zwei Zeiger einen unterschiedlichen Typ für dieselbe Speicheradresse angeben. In deinem Beispiel bedeutet es, dass der Compiler fWrt gleichzeitig als float und als unsigned long interpretieren muss, was alle Optimierungen zerstört weil die normalerweise vollkommen unterschiedlich behandelt werden.

Übrigens kracht der Code auch unter x86-64, weil unsigned long dort 64 Bits groß ist und fWrt nur 32.

Schade, dass es hier keine Sekundenanzeige gibt – sonst könnte ich ausrechnen, wieviele -Tags ich in Zukunft weglassen muss um Aramis zuvor zu kommen …

Verfasst: **20.07.2010, 22:21**

x86-64 bedeutet nicht automatisch, dass unsigned long 64 bit lang ist. Siehe LP64 vs LLP64.

Verfasst: **20.07.2010, 22:24**

Jörg hat geschrieben:x86-64 bedeutet nicht automatisch, dass unsigned long 64 bit lang ist. Siehe LP64 vs LLP64.

Die Warnung stammt von GCC und der verwendet für x86-64 LP64.

Verfasst: **21.07.2010, 13:08**

Was mich noch interessieren würde ist, warum kommt die Warnung nur im Release-Modus?
Im Moment benutze ich gcc mit Code::Blocks und verwende die Standardeinstellungen.

Verfasst: **21.07.2010, 13:22**

Weil GCC nur im Release-Modus Optimierungen anwendet, die von den Aliasing-Regeln Gebrauch machen. Falls du den Code übrigens doch behalten willst, versuch es mal mit

Code: Alles auswählen

union {
    float asFloat;
    unsigned int asUInt;
} const Value = { fWrt };
unsigned int p = (0xbe6f0000 - Value.asUInt) >> 1;

und benutz für die Integers nach Möglichkeit Plattformunabhängige typedefs.

Der Code wird übrigens nur unter GCC optimiert, unter VC ist reinterpret_cast<unsigned int const *>(&fWrt); schneller.

Verfasst: **21.07.2010, 13:29**

Allerdings ist auch die union–Loesung streng genommen Undefined Behaviour :-) An dieser Stelle wird klar dass es eigentlich nicht moeglich ist 100% wohldefinierten C++-Code zu schreiben.

Verfasst: **21.07.2010, 13:49**

Werd's gleich mal ausprobieren .. Danke.
Edit:
Das war natürlich die Antwort auf einen Thread zuvor .. :D

Verfasst: **22.07.2010, 13:59**

Allgemeine Frage zu Code::Blocks/Ubuntu:
Der Befehl 'rand()' funktioniert anscheinend anders als gewohnt (Win32).
Wenn ich unter VS Informationen über diesen Befehl haben will, dann
lege ich die Maus darauf und drücke F1. Wie mache ich dass unter gcc/Code::Blocks?
Ich habe bisher noch keine Möglichkeit entdeckt, außer 'Search at Koders' ..

Verfasst: **22.07.2010, 14:54**

Von Code::Blocks hab ich jetzt keine Ahnung, aber gib mal in einem Terminal "man 3 rand" ein. (Ohne die Anführungszeichen)

Verfasst: **22.07.2010, 15:01**

Bei sowas ist auch www.google.de sehr nützlich ;).

Gruß Kimmi

Verfasst: **22.07.2010, 15:03**

Potenziell dumme Frage, aber ist ::rand() nicht standardisiert?

Verfasst: **22.07.2010, 15:08**

Hab' ich auch gedacht, aber:
Ubuntu(stdlib.h):
/* The largest number rand will return (same as INT_MAX). */
#define RAND_MAX 2147483647
Win32(Hilfe):
The rand function returns a pseudorandom integer in the range 0 to RAND_MAX (32767).
Win32(stdlib.h)
/* Maximum value that can be returned by the rand function. */
#define RAND_MAX 0x7fff

Verfasst: **22.07.2010, 15:16**

RAND_MAX is a constant defined in <cstdlib>. Its default value may vary between implementations but it is granted to be at least 32767.

Und wo ist da jetzt das Problem? :)

Verfasst: **22.07.2010, 15:18**

Genau.

Biolunar fragt sich grade was Krishty mit

Krishty hat geschrieben:Potenziell dumme Frage, aber ist ::rand() nicht standardisiert?

gemeint hat.

Verfasst: **22.07.2010, 15:28**

Dass sich die Implementierungen bei sachgemäßer Anwendung identisch verhalten müssten.

Verfasst: **22.07.2010, 15:52**

Du kannst natürlich auch deinen eigenen Rand-Algorithmus nehmen. Such mal nach "Numerical Recipes" bei Google und schau dort nach den entsprechenden Algo's. Die sollten sich dann gleich verhalten.

Gruß Kimmi

Verfasst: **22.07.2010, 15:59**

Danke für die Infos. Meine Frage war eigentlich, gibt es keinen 'Klick' auf einen Befehl .. und Hilfe ist unterwegs?
PS:
Googeln kann ich schon.

Verfasst: **22.07.2010, 16:01**

Nein gibt es nicht wurde dir doch jetzt auch wiederholt gesagt (developia.de)

Verfasst: **22.07.2010, 16:11**

Ja, schon, aber nicht so deutlich ;) .

Verfasst: **22.07.2010, 17:00**

Du könntest mal Netbeans ausprobieren. Dort wird Hilfe (sofern vorhanden) so angezeigt:
Bild

ZFX + Developia

Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..