#define mitten im code

[Durchstarter (Gast)]

Hallo zusammen,

ist es möglich #define mitten im code zu definieren.

//gewoehnlich ganz oben
if (Quelle A)
#define   register register_a
elseif(Quelle B)
#define   register register_b
.
.
.

je nach dem woher ich meine Daten her kriege (unterschiedliche Quellen) 
muss ich unterschiedliche Register ansprechen. Ich weiss aber nicht von 
vorn herein welcher Sender (Quelle) mir Daten senden wird. Wollte jetzt 
nich unbedingt 10 Funktionen schreiben, eine für jede Quelle, sondern 
wenn ich Daten aus der Quelle A habe sollen alle  Register der Quelle A 
abgearbeitet werden und so weiter...

void daten_bearbeiten()
{
    register.RXREGISTER...
}

Danke

Gruß

Dennis

[Klaus W. (mfgkw)]

Prinzipiell kannst das #define hinschreiben, wo du willst - ob es 
elegant ist, steht auf einem anderen Blatt.

Das was du vorhast geht aber trotzdem nicht.
Grund: Vor dem eigentlichen Kompilieren läuft der Präprozessor durch die 
Datei und kümmert sich u.a. um die #define-Geschichten.
Den interessiert aber dein if nicht, und er weiß auch gar nicht, welcher 
Fall zur Laufzeit eintreten wird.
Also sieht er einfach beide #define und wird beim zweiten meckern, weil 
es ja schon orher eines mit demselben Namen gab.

(Steht in C-Büchern heute nicht mehr, wie der Präprozessor arbeitet?)

[Durchstarter (Gast)]

So wie ich Sie verstanden habe Hr. Wachtler, sollte ich dieses vorhaben 
sein lassen.
Jut, dann werd ich mal mit dem Schreiben der Funktionen anfangen.

Danke

Gruß

[Rolf Magnus (Gast)]

Durchstarter schrieb:
> Wollte jetzt nich unbedingt 10 Funktionen schreiben, eine für jede
> Quelle, sondern wenn ich Daten aus der Quelle A habe sollen alle
> Register der Quelle A abgearbeitet werden und so weiter...

Dann verwende einen Zeiger.

[Kurzschlusselektriker (Gast)]

Vorsicht auch mit "elseif" und "register".
Ob diese wörter so erlaubt sind, hängt von der Sprache und dem Compiler 
ab...
Wenn ich mich nicht irre, gibts in C kein elseif und "register" könnte 
eine Speicherklasse sein ("pack den kram in ein reigster").

[Kurzschlusselektriker (Gast)]

Beispiel zu "register":
http://www.tu-chemnitz.de/urz/kurse/unterlagen/C/kap2/register.htm

[Klaus W. (mfgkw)]

Durchstarter schrieb:
> So wie ich Sie verstanden habe Hr. Wachtler, sollte ich dieses vorhaben
> sein lassen.

ja, so meinte ich das.

Je nachdem, was es genau machen soll, kann in der Tat ein Zeiger das 
richtige Mittel sein.
Das könnte etwa so aussehen (angenommen, die Register haben den Typ 
register_t):

    register_t   *p_welchesregister = NULL;
    if( irgendwas )
    {
        p_welchesregister = &register_a;
    }
    else if( irgendwasanderes )
    {
        p_welchesregister = &register_b;
    }
    else if( irgendwasganzanderes )
    {
        p_welchesregister = &register_c;
    }
...
    daten_bearbeiten( p_welchesregister );
....

void daten_bearbeiten( register_t *p_register )
{
    if( p_register!=NULL )
    {
        p_register->RXREGISTER...
    }
    else
    {
        // ganz dummer Fehler!
        // Meldung ausgeben, Programm abbrechen,
        // ab in die Kirche zum Beichten...
        ...
    }
}

[Klaus W. (mfgkw)]

Kurzschlusselektriker schrieb:
> Wenn ich mich nicht irre, gibts in C kein elseif und "register" könnte
> eine Speicherklasse sein ("pack den kram in ein reigster").

stimmt, register ist ein reserviertes Schlüsselwort.

[Durchstarter (Gast)]

Vielen Dank

Adieu

[undef (Gast)]

Natürlich kann man mitten im Code ein #define vereinbaren. Das macht 
sogar Sinn.

z. Bsp.

...

int foo_func (void) {
   ...

#define LOCAL_DEF 123
   ...
#undef LOCAL_DEF

   ...
}

[Rolf Magnus (Gast)]

undef schrieb:
> Natürlich kann man mitten im Code ein #define vereinbaren.

Klar. Nur tut das leider nicht das, was "Durchstarter" sich davon 
erwartet hat.

[undef (Gast)]

Rolf Magnus schrieb:
> Nur tut das leider nicht das, was "Durchstarter" sich davon
> erwartet hat.

Klaus Wachtler schrieb:
> ob es
> elegant ist, steht auf einem anderen Blatt.

ich hatte den Satz von KW im Hinterkopf.

[Klaus W. (mfgkw)]

Aber auch dann gilt: in den meisten Fällen, wo es verwendet wird, ist 
ein #define inzwischen eher kontraproduktiv.
Funktionsähnliche Makros sowieso, aber auch als Konstanten ist eine 
const int oder sowas meist sinnvoller.

Ausnahmen gibt es sicher, aber um einen Wert zu definieren sehe ich 
eigentlich nur noch zur Übergabe an den Compiler eine Rechtfertigung 
(und damit ist es ja auch kein #define, sondern ein -D... :-)

[undef (Gast)]

Klaus Wachtler schrieb:
> aber auch als Konstanten ist eine
> const int oder sowas meist sinnvoller.

...

int foo_func (void) {
   ...
const int foo_const = 123;

#define LOCAL_DEF 123
   ...
#undef LOCAL_DEF

   ...
}

Wo legt jeder Compiler foo_const ab?

[Bartli (Gast)]

Im RAM? Im ROM? Das entscheidet schlussendlich das Linkerskript. Falls 
der Compiler foo_const nicht schon lange wegoptimiert hat.

Habt mal ein bisschen vertrauen in die modernen Compiler, also echt.

[undef (Gast)]

Bartli schrieb:
> Im RAM? Im ROM?

Ja wo nun?
Ein #define wird garantiert nie RAM belegen.

[Tobi H. (tobi-)]

Ein const int wird genau dann RAM belegen, wenn es Sinn macht, nämlich 
z.B. beim debuggen und keinen, wenn man Optimierungen einschaltet. Da 
kann sich jeder gerne im asm-Output (oder debugger) von überzeugen.

[undef (Gast)]

Tobi H. schrieb:
> Ein const int wird genau dann RAM belegen, wenn es Sinn macht, nämlich
> z.B. beim debuggen und keinen, wenn man Optimierungen einschaltet. Da
> kann sich jeder gerne im asm-Output (oder debugger) von überzeugen.

Das ist aber Compiler abhängig!
Der eine oder andere Compiler wird die lokale const Variable auf den 
Stack legen.

[Bartli (Gast)]

Und mit solchen Steinzeitcompilern erstellst du täglich Software für 
Systeme mit sowenig RAM, dass du lieber #define verwendest. Ist schon 
klar.

[undef (Gast)]

Bartli schrieb:
> Und mit solchen Steinzeitcompilern erstellst du täglich Software für
> Systeme mit sowenig RAM

Als Entwickler schadet es nicht zu wissen, wie die genutzten Werkzeuge 
arbeiten. Das kann der Qualität der Produkte förderlich sein ;-)

[Bartli (Gast)]

Gähn.

Na dann erzähl doch mal, mit was für Compilern du so arbeitest. MSC und 
gcc können es ja wohl kaum sein, die sind schon lange nicht mehr so 
dämlich.

[Klaus W. (mfgkw)]

undef schrieb:
> Als Entwickler schadet es nicht zu wissen, wie die genutzten Werkzeuge
> arbeiten. Das kann der Qualität der Produkte förderlich sein ;-)

Eben weil es der Qualität nicht förderlich ist, müllt man seinen 
Quelltext nicht mehr unnötig mit Makros zu.
Auch das schadet nicht zu wissen.

Abner jeder, wie er will.
Wenn jeder gute SW schreiben würde, wäre ich arbeitslos.

[Rolf Magnus (Gast)]

Tobi H. schrieb:
> Ein const int wird genau dann RAM belegen, wenn es Sinn macht, nämlich
> z.B. beim debuggen und keinen, wenn man Optimierungen einschaltet.

Dann muß er aber auch als static deklariert sein.

Klaus Wachtler schrieb:
> Aber auch dann gilt: in den meisten Fällen, wo es verwendet wird, ist
> ein #define inzwischen eher kontraproduktiv.
> Funktionsähnliche Makros sowieso, aber auch als Konstanten ist eine
> const int oder sowas meist sinnvoller.

In C gibt es im Gegensatz zu C++ keine echten Konstanten. Deshalb wird 
#define als Ersatz dafür verwendet. Beispiel:

const int arraysize = 5;
int array[arraysize];

das wird außerhalb einer Funktion eine Fehlermeldung geben, da arraysize 
eben keine Konstante ist. Oder die oft verwendete Definiton von pi:

#define PI (4 *atan(1))

wird als globaler const double auch nicht durch den Compiler gehen. Und 
wenn ich in solchen Fällen schon Makros verwende, dann werde ich nicht 
so inkonsistent sein und sie in manchen, aber nicht allen Fällen zu 
benutzen.
Außerdem kann man selektive Compilierung nur mit Makros machen, genauso 
wie z.B. Debug-Funktionen, die Quell-Datei und -Zeile ausgeben oder 
sowas wie MAX(), das den größeren von zwei Werten zurückliefert, und 
zwar ohne sich dabei auf einen einzelnen Typ einzuschränken. Es gibt 
jede Menge Gründe für die Verwendung von Makros in C.  In C++ wurden die 
meisten davon eliminiert.
Außerdem wird const in C recht "entspannt" gesehen. Es kann auch mal 
passieren, daß man die "Konstante" versehentlich ändert, was bei einem 
Makro nicht passiert.

[Klaus W. (mfgkw)]

Rolf Magnus schrieb:
> Dann muß er aber auch als static deklariert sein.

(falls global)

> In C gibt es im Gegensatz zu C++ keine echten Konstanten. Deshalb wird
> #define als Ersatz dafür verwendet. Beispiel:
>
> const int arraysize = 5;
> int array[arraysize];

Tja, was ist C?
K&R, ISO-C90: ja
C99: nein, da geht das.
C++ natürlich auch.

> Oder die oft verwendete Definiton von pi:#define PI (4 *atan(1))

Bei dem dummen Compiler von undef wäre das natürlich eine Katastrophe, 
der würde jedesmal atan() aufrufen! :-)

> Außerdem kann man selektive Compilierung nur mit Makros machen, genauso
> wie z.B. Debug-Funktionen, die Quell-Datei und -Zeile ausgeben

vollkommen richtig; das ist einer der Fälle, die ich pauschal 
unterschreibe.

> oder sowas wie MAX(),

ja, wobei man dabei halt schon wieder die Makroprobleme hat (++ bei 
Parametern etc.).

> In C++ wurden die
> meisten davon eliminiert.

Gott sei es gedankt.

> Außerdem wird const in C recht "entspannt" gesehen. Es kann auch mal
> passieren, daß man die "Konstante" versehentlich ändert, was bei einem
> Makro nicht passiert.

Oder absichtlich (const volatile...).

----

Ich will auch gar nicht behaupten, daß #define generell böse wäre.
Aber in den meisten Fällen, wo ich eines sehe, ginge es ohne besser.

Ähnlich wie mit goto und anderen Murkserwerkzeugen: man kann es mit 
Bedacht verwenden, die meisten machen es anders.

[Gutdurch (Gast)]

undef schrieb:
> Tobi H. schrieb:
>> Ein const int wird genau dann RAM belegen, wenn es Sinn macht, nämlich
>> z.B. beim debuggen und keinen, wenn man Optimierungen einschaltet. Da
>> kann sich jeder gerne im asm-Output (oder debugger) von überzeugen.
>
> Das ist aber Compiler abhängig!
> Der eine oder andere Compiler wird die lokale const Variable auf den
> Stack legen.

Und wo kommt sie dann her, diese Konstante und was soll sie auf dem 
Stack? Nein du hast leider keine Ahnung oder benutzt Steinzeittools bzw. 
kommerziellen Mist.

[Klaus W. (mfgkw)]

Durchstarter schrieb:
> Hallo zusammen,
>
> ist es möglich #define mitten im code zu definieren.
> //gewoehnlich ganz oben
> if (Quelle A)
> #define   register register_a
> elseif(Quelle B)
> #define   register register_b
> .
> .
> .
>
> je nach dem woher ich meine Daten her kriege (unterschiedliche Quellen)
> muss ich unterschiedliche Register ansprechen. Ich weiss aber nicht von
> vorn herein welcher Sender (Quelle) mir Daten senden wird.

Oder mal eine andere Interpretation:
Vielleicht weißt du noch nicht beim Schreiben des Quelltextes, welche 
"Quelle" du hast, aber zumindest beim letzlichen Kompilieren (also nicht 
erst zur Laufzeit)?

Dann gibt es vielleicht noch etwas in der von dir gewünschten Art:

// heute kompilieren wir mit RS232, morgen mit CAN, übermorgen mache
// ich der Königin ein Kind...
#define QUELLE_IST_RS232
//#define QUELLE_IST_CAN
//#define QUELLE_IST_KOENIGIN

#ifdef QUELLE_IST_RS232
#define REGISTER    (register_a)
#elif defined QUELLE_IST_CAN
#define REGISTER    (register_b)
#elif ... etc.
#endif

...

Anstatt des ersten #define QUELLE... könnte man den Compiler dann auch 
z.B.mit -DQUELLE_IST_RS232 aufrufen und so mal die eine und mal die 
andere Version kompilieren.

[Tobi H. (tobi-)]

> Oder die oft verwendete Definiton von pi:#define PI (4 *atan(1))
pi wird z.B. beim gcc als zahl definiert...

> oder sowas wie MAX(),
std::max() sollte nicht langsamer sein und genauso allgemeingültig (c++ 
vorausgesetzt). ganz ohne parameter-probleme

> Anstatt des ersten #define QUELLE... könnte man den Compiler dann auch
> z.B.mit -DQUELLE_IST_RS232 aufrufen und so mal die eine und mal die
> andere Version kompilieren.
Klar, bedingte Kompolierung bezweifelt niemand. Aber warum zwischen den 
Blöcken nicht ein

const int REGISTER = register_a;

schreiben? Schon sind die defines auf das nötigste reduziert.

Gottseidank wird der neue c++-Standard noch mehr Einsatzzwecke 
ausräumen, dann bleibt absolut nur noch die bedingte Kompilierung

[Johann L. (gjlayde)]

#define oder #include im Code können durchaus zweckmässig sein.

Hier ein Beispiel aus den avr-binutils:

opcode/avr.h

AVR_INSN (clc,  "",    "1001010010001000", 1, AVR_ISA_1200, 0x9488)
AVR_INSN (clh,  "",    "1001010011011000", 1, AVR_ISA_1200, 0x94d8)
AVR_INSN (cli,  "",    "1001010011111000", 1, AVR_ISA_1200, 0x94f8)
...

Und das kann dann an mehreren Stellen verwendet werden wie zB

gas/config/tc-avr.c

#define AVR_INSN(NAME, CONSTR, OPCODE, SIZE, ISA, BIN) \
{#NAME, CONSTR, OPCODE, SIZE, ISA, BIN},

struct avr_opcodes_s avr_opcodes[] =
{
  #include "opcode/avr.h"
  {NULL, NULL, NULL, 0, 0, 0}
};

#undef AVR_INSN

Ähnliche Konstrukte gibt's in avr-gcc.  Eine Struktur anzulegen und 
darauf zuzugreifen ist hier nicht unbedingt zielführend, da etwa auch 
opt-Dateien, welche gültige Komandozeilen-optionen wie -mmcu= enthalten 
und nicht in C-Syntax sind, dadurch abgebildet werden können.

[... (Gast)]

Tobi H. schrieb:
> Klar, bedingte Kompolierung bezweifelt niemand. Aber warum zwischen den
> Blöcken nicht ein
>   const int REGISTER = register_a;
> schreiben?
Weil das in dem Zusammenhang dann völliger Schwachsinn ist.

Wenn schon, dann:

const int REGISTER_PTR = &register_a;

[... (Gast)]

... schrieb:
> Wenn schon, dann:
>    const int REGISTER_PTR = &register_a;

Mist, ist natürlich genauso daneben.
So wird ein Schuh draus:

const int * REGISTER_PTR = &register_a;

[undef (Gast)]

Bartli schrieb:
> Na dann erzähl doch mal, mit was für Compilern du so arbeitest. MSC und
> gcc können es ja wohl kaum sein, die sind schon lange nicht mehr so
> dämlich.

Klaus Wachtler schrieb:
> Bei dem dummen Compiler von undef

Gutdurch schrieb:
> Und wo kommt sie dann her, diese Konstante und was soll sie auf dem
> Stack? Nein du hast leider keine Ahnung oder benutzt Steinzeittools bzw.
> kommerziellen Mist.

Solchen sachlichen und wissenschaftlich fundierten Argumenten kann man 
ja nichts mehr entgegnen. ;-P

Da ich aber gerade ein jungfräuliches Visual C++ (2010) unter die Finger 
bekam, konnte ich mich dem Beweis eures übermächtigen Wissens nicht 
entziehen:

#include "stdafx.h"


void foo_func (void)
{
  const int i = 0x0F0F;

  for (int n = 0; n < i; n++)
  {
    n++;
    n--;
  }
}

ergibt

;  COMDAT ?foo_func@@YAXXZ
_TEXT  SEGMENT
_n$5259 = -20            ; size = 4
_i$ = -8            ; size = 4
?foo_func@@YAXXZ PROC          ; foo_func, COMDAT
; Line 5
  push  ebp
  mov  ebp, esp
  sub  esp, 216        ; 000000d8H
  push  ebx
  push  esi
  push  edi
  lea  edi, DWORD PTR [ebp-216]
  mov  ecx, 54          ; 00000036H
  mov  eax, -858993460        ; ccccccccH
  rep stosd
; Line 6
  mov  DWORD PTR _i$[ebp], 3855    ; 00000f0fH
; Line 8
  mov  DWORD PTR _n$5259[ebp], 0
  jmp  SHORT $LN3@foo_func
$LN2@foo_func:
  mov  eax, DWORD PTR _n$5259[ebp]
  add  eax, 1
  mov  DWORD PTR _n$5259[ebp], eax
$LN3@foo_func:
  cmp  DWORD PTR _n$5259[ebp], 3855    ; 00000f0fH
  jge  SHORT $LN4@foo_func
; Line 10
  mov  eax, DWORD PTR _n$5259[ebp]
  add  eax, 1
  mov  DWORD PTR _n$5259[ebp], eax
; Line 11
  mov  eax, DWORD PTR _n$5259[ebp]
  sub  eax, 1
  mov  DWORD PTR _n$5259[ebp], eax
; Line 12
  jmp  SHORT $LN2@foo_func
$LN4@foo_func:
; Line 13
  pop  edi
  pop  esi
  pop  ebx
  mov  esp, ebp
  pop  ebp
  ret  0
?foo_func@@YAXXZ ENDP          ; foo_func
_TEXT  ENDS

und

#include "stdafx.h"


void foo_func (void)
{
#define i  0x0F0F

  for (int n = 0; n < i; n++)
  {
    n++;
    n--;
  }

#undef i
}

ergibt

;  COMDAT ?foo_func@@YAXXZ
_TEXT  SEGMENT
_n$5258 = -8            ; size = 4
?foo_func@@YAXXZ PROC          ; foo_func, COMDAT
; Line 5
  push  ebp
  mov  ebp, esp
  sub  esp, 204        ; 000000ccH
  push  ebx
  push  esi
  push  edi
  lea  edi, DWORD PTR [ebp-204]
  mov  ecx, 51          ; 00000033H
  mov  eax, -858993460        ; ccccccccH
  rep stosd
; Line 8
  mov  DWORD PTR _n$5258[ebp], 0
  jmp  SHORT $LN3@foo_func
$LN2@foo_func:
  mov  eax, DWORD PTR _n$5258[ebp]
  add  eax, 1
  mov  DWORD PTR _n$5258[ebp], eax
$LN3@foo_func:
  cmp  DWORD PTR _n$5258[ebp], 3855    ; 00000f0fH
  jge  SHORT $LN4@foo_func
; Line 10
  mov  eax, DWORD PTR _n$5258[ebp]
  add  eax, 1
  mov  DWORD PTR _n$5258[ebp], eax
; Line 11
  mov  eax, DWORD PTR _n$5258[ebp]
  sub  eax, 1
  mov  DWORD PTR _n$5258[ebp], eax
; Line 12
  jmp  SHORT $LN2@foo_func
$LN4@foo_func:
; Line 15
  pop  edi
  pop  esi
  pop  ebx
  mov  esp, ebp
  pop  ebp
  ret  0
?foo_func@@YAXXZ ENDP          ; foo_func
_TEXT  ENDS

uuuuuupppsss, da fehlt ja der asm Code für die Line 6. Was macht der 
wohl im 'const' Beispiel?

[... (Gast)]

Du hast aber nicht zufällig einen Debug-Build kompiliert?
Schalt Dein Visual C++ mal auf "Release" und schau nochmal.

[Bartli (Gast)]

> Du hast aber nicht zufällig einen Debug-Build kompiliert?

Natürlich ist das ein Debug-Build. Sieht man ja schon daran, wie immer 
schön brav alle Variablen in den Speicher zurückgschrieben werden.

Mein VS2008 optimiert im Release-Build foo_func komplett weg.

void foo_func (void)
{
  const int i = 0x0F0F;
  int n;

  for (n = 0; n < i; n++)
  {
    n++;
    n--;
  }
}

int main(int argc, char **argv)
{
  foo_func();
}

=>

--- c:\users\xxx\desktop\test\test\test.c --------------------------------------
void foo_func (void)
{
  const int i = 0x0F0F;
  int n;

  for (n = 0; n < i; n++)
  {
    n++;
    n--;
  }
}

int main(int argc, char **argv)
{
  foo_func();
}
00241000  xor         eax,eax 
00241002  ret              
--- f:\dd\vctools\crt_bld\self_x86\crt\src\intel\secchk.c ----------------------

> Solchen sachlichen und wissenschaftlich fundierten Argumenten kann man
> ja nichts mehr entgegnen. ;-P

Scherzkeks. Dein Beweis oben ist ja sowas von wissenschaftlich.

[Rolf Magnus (Gast)]

Klaus Wachtler schrieb:
>> In C gibt es im Gegensatz zu C++ keine echten Konstanten. Deshalb wird
>> #define als Ersatz dafür verwendet. Beispiel:
>>
>> const int arraysize = 5;
>> int array[arraysize];
>
> Tja, was ist C?

Offiziell gibt es nur eins, nämlich C99. Deswegen ist das für mich immer 
die Referenz.

> K&R, ISO-C90: ja
> C99: nein, da geht das.

nein, tut es nicht. Wenn ich die obigen beiden Zeilen in eine Datei 
schreibe, meint gcc -std=c99 dazu zurecht:

klaus.c:2:5: error: variably modified ‘array’ at file scope

man beachte meinen von dir geschickterweise nicht mitzitierten Satz "das 
wird außerhalb einer Funktion eine Fehlermeldung geben". Wenn das 
Array lokal und nicht statisch ist, ist das natürlich was anderes, aber 
nur weil C99 für diesen Fall die Möglichkeit bietet, auch nichtkonstante 
Arraygrößen anzugeben.

> C++ natürlich auch.

Da geht es, weil arraysize in C++ eine echte Konstante ist, und nicht 
nur eine Variable mit der Bitte, sie nicht zu beschreiben.

>> Oder die oft verwendete Definiton von pi:#define PI (4 *atan(1))
>
> Bei dem dummen Compiler von undef wäre das natürlich eine Katastrophe,
> der würde jedesmal atan() aufrufen! :-)

Zum Glück nutze ich solche Compiler nicht.

Tobi H. schrieb:
>> Oder die oft verwendete Definiton von pi:#define PI (4 *atan(1))
> pi wird z.B. beim gcc als zahl definiert...

Beim gcc wird pi gar nicht definiert. Höchstens die von dir verwendete 
libc tut das, und wenn sie es in math.h tut, ist das auch noch ein 
Verstoß gegen die ISO-Norm.

>> oder sowas wie MAX(),
> std::max() sollte nicht langsamer sein und genauso allgemeingültig (c++
> vorausgesetzt).

Es geht aber nicht um C++.

[Johann L. (gjlayde)]

Klaus Wachtler schrieb:
> Rolf Magnus schrieb:
>> Oder die oft verwendete Definiton von pi:#define PI (4 *atan(1))
>
> Bei dem dummen Compiler von undef wäre das natürlich eine Katastrophe,
> der würde jedesmal atan() aufrufen! :-)

Das Ergebnis ist doch vom eingestellten Rounding-Mode abhängig?

[undef (Gast)]

Bartli schrieb:
> Mein VS2008 optimiert im Release-Build foo_func komplett weg.

Mensch Bartli, du hast es immer noch nicht verstanden: const <irgendwas> 
ist für den Compiler eine Variabl. #define USW sieht er nicht, da der 
Präprozessor den Text ersetzt. Es spielt doch keine Rolle, ob hinterher 
optimiert wird oder nicht.

Das ist wie in der Schule bei Mathe: Wenn dun das richtige Ergebnis vom 
Nachbarn abschreibst, hast du aber den Rechenweg nicht verstanden. Was 
machst du mal ohne Tischnachbarn?

Für mich ist das Thema jetzt abgeschlossen.

[Klaus W. (mfgkw)]

Gottseidank.

[Bartli (Gast)]

> Mensch Bartli, du hast es immer noch nicht verstanden.

Na dann ist ja gut und deine Welt wieder in Ordnung.

> Als Entwickler schadet es nicht zu wissen, wie die genutzten Werkzeuge
> arbeiten. Das kann der Qualität der Produkte förderlich sein ;-)

Genau. Einfach mal ausprobieren: Release-Build deiner Saftware bauen und 
staunen wie schnell das plötzlich alles läuft. Du bist ja echt ein 
Spassvogel.