CompilerWarnungen

mrloverlover schrieb:

gcc kompiliert den code von nwp2 fehlerfrei

der GCC kann doch nix dafür. der linker muss merken, dass das symbol doppelt belegt ist und meckern. nwp hat ja kein 'static' davor, d.h. linken sollte scheitern. wenn nicht, habt ihr irgendwelche einstellungen vergurkt bzw. euer linker nimmt an, dass solche funktionen 'übersetzungseinheit-lokal' sind, was aber eigentlich nicht richtig ist.

nwp2

Also an Einstellungen liegts nicht, alles default. Andererseits ist der gcc 3.4.5 auch reichlich tolerant, der akzeptiert auch Variablendefinitionen in case Statements und Klassenassoziationen im class:

switch(i){
    case 1: int j; break;
    default: char j;
}

class bla{
    bla::print();
};

Der 4er schluckt das aber alles nicht mehr und außer mir hat keiner mehr den 3er

nwp2 schrieb:

Also an Einstellungen liegts nicht, alles default.

naja, per default hat der GCC ja 'ne ziemliche menge an nicht-standard extensions aktiviert, wie ich dunkel in erinnerung habe. allein dieses 'class'-zeug hat in einem waschechten C-compiler wirklich nichts verloren (müsste syntax-errors ohne ende hageln). bisher war ich immer der meinung, dass der GCC nur auf embedded-systemen nix taugt (er optimiert schlecht im erhältnis zu kommerziellen compilern == lahme und grosse executables), aber dass er sogar auf x86-gurken so rumspinnt, hätt' ich nicht gedacht (ok, er muss wohl erst entsprechend konfiguriert werden, damit er sich wie ein richtiger C-compiler verhält, das geht bestimmt, da bin ich mir sicher).

Hallo,

die Einstellungen sind hier nicht das "Problem", vielmehr die Architektur der GNU C-Bibliothek, die kennt "schwache" Symbole:

http://winfred-lu.blogspot.com/2009/11/understand-weak-symbols-by-examples.html

MfG,

Probe-Nutzer

leyden

Hallo,

vielen Dank für die Antworten. Habe jetzt den Parameter im printf und den Namen von pow in myPow geändert, alle Warnunegn weg.

Aber hier dann die nächste Frage. Die Funktion pow ist doch in der Datei math.h. Da ich die aber nicht benutze sollte das den Compiler doch nicht kratzen, oder?? Hab nach dem Begriff pow in der stdio.h gesucht und nichts gefunden.

ich bekomm den fehler

incompatible implicit declaration of built-in function ‘pow’

weiß nicht was eine built-in function ist aber das bekomm ich schon noch raus...
wenns ihm nicht passt das du eine built-in function überschreibst dann machs doch einfach nicht

google hat mal wieder ausgeholfen...

http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#Other-Builtins

evtl. ists die

— Built-in Function: double __builtin_powi (double, int)

Returns the first argument raised to the power of the second. Unlike the pow function no guarantees about precision and rounding are made.

lg lolo

hab jetzt mal versucht das als c89 zu compilieren scheint als wär das möglich

gcc -std=c89 ...

The ISO C90 functions ... are all recognized as built-in functions unless -fno-builtin is specified (or -fno-builtin-function is specified for an individual function) das steht aber alles nochmal genau erklärt in dem link, wennst nen anderen compiler verwendest außer gcc gibts sicher auch ne schöne docu in der du mal nach built-in functions suchen kannst

nwp2

leyden schrieb:

Da ich die aber nicht benutze sollte das den Compiler doch nicht kratzen, oder?? Hab nach dem Begriff pow in der stdio.h gesucht und nichts gefunden.

Sollte er nicht, tut er aber trotzdem. Siehe hier: http://www.gnu.org/software/hello/manual/libc/Reserved-Names.html

The names of all library types, macros, variables and functions that come from the ISO C standard are reserved unconditionally; your program may not redefine these names.

Das heißt, alles was in den Standardbibliotheken drin ist darfst du nicht als Variablenname verwenden, auch nicht wenn du die Bibliothek garnicht verwendest.

leyden

Vielen Dank für die schnellen Antworten, ihr habt mir sehr geholfen.