CompilerWarnungen

nwp2 schrieb:

Er beschwert sich, dass du eine Standardfunktion überschreibst, was man nicht tun sollte.

geht in C sowieso nicht, sondern nur in OO-sprachen wie z.b. Java, C# usw., indem in einer abgeleiteten klasse eine bereits vorhandene methode der basisklasse mit gleichem namen und gleicher signatur neu definiert wird (oder verwechsle ich das jetzt mit 'überladen'?, ach, egal). in C jedenfalls, meckert der compiler einfach nur, dass die funktion schon existiert. musste also einfach einen neuen namen nehmen, dann funzt es.

nwp2

Komisch, bei mir geht das.

#include <stdio.h>

int malloc(int i){
	return printf("weeeee\n");
}

int main(){
	malloc(5);
	return 0;
}

Das gibt tatsächlich weeeee aus, allerdings gibt es danach einen Segfault, bestimmt weil der Stack futsch ist. Mit pow hingegen funktioniert alles. Ich nehme mal an der Assembler oder Linker hat malloc hartgecodet(das Wort sieht falsch aus).
Jedenfalls ist es eine schlechte Idee Standardfunktionen zu überschreiben. Es geht, aber es tut manchmal nicht was es soll.

nwp2 schrieb:

Komisch, bei mir geht das.

seltsam, hast wohl irgenwelche linker-settings verstellt. bei mir passiert das:

fatal error LNK1169: one or more multiple defined symbols found

(msvc 2005)

;fricky schrieb:

(msvc 2005)

wieso nutzt du so einen oldie? :xmas1:

mrloverlover schrieb:

wieso nutzt du so einen oldie?

der tuts halt. manchmal nutze ich auf'm PC sogar vc6, reicht auch. ich benutze C auffer PC-plattform sowieso nur für prototypen und simulationen.

;fricky schrieb:

mrloverlover schrieb:

wieso nutzt du so einen oldie?

der tuts halt. manchmal nutze ich auf'm PC sogar vc6, reicht auch. ich benutze C auffer PC-plattform sowieso nur für prototypen und simulationen.

anscheinend nicht :p
gcc kompiliert den code von nwp2 fehlerfrei

msvc2008 hab ich jetzt nicht auf der haube

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.