Blöde Frage

BasicMan01

die Funktion sqrt liegt in der Header cmath. Diese musst du eventuell noch einbinden, wenn dein Fehler in etwa "error: 'sqrt' was not declared in this scope" lauten sollte.

Ansonsten wie schon von Zeus erwähnt, musst du das Ergebnis beider Anweisungen irgendwo zwischenspeichern oder ausgeben.

blurry333

Problem :

modulo braucht int.

Aber sqrt braucht double !!!!!

blurry333

ok passt schon.

Einfach sqrt((double)n);

unskilled

blurry333 schrieb:

Problem :

modulo braucht int.

Aber sqrt braucht double !!!!!

so ein quatsch, sqrt bietet eine überladung für float udn eine für double (und noch eine für long double).
und da eine implizite umwandlung von int nach float(und auch double) existiert, compiliert das doch - von der warnung abgesehen(die du durch nen cast wegbekommst) - super.

bb

Athar

Das ist genau das Problem, da eine impliziter Cast nach float und double und long double möglich ist, kompiliert das eben nicht, wenn keine zusätzliche sqrt-Überladungen für Integertypen angeboten werden.

icarus2

Wie wärs mit einem expliziten cast nach float, double oder long, ungefähr so:

sqrt( (long)n )

Ist doch nicht so schwer. Oder hab ich da was falsch verstanden?

*Edit
Mist, das gleiche wurde oben ja schon vorgeschlagen ^^

BasicMan01

Kann es sein, dass jeder Compiler seine eigene Headeranpassungen mitliefert.
Bei mir existiert hierzu in der cmath eine entsprechende Codestelle, bei der ich davon ausgehe, dass diese den Cast von int in double vornimmt:

template<typename _Tp>
    inline typename __gnu_cxx::__enable_if<__is_integer<_Tp>::__value,
                       double>::__type
    sqrt(_Tp __x)
    { return __builtin_sqrt(__x);

SeppJ

BasicMan01 schrieb:

Kann es sein, dass jeder Compiler seine eigene Headeranpassungen mitliefert.

Implementierungen dürfen Zusatzfeatures anbieten die über den Standard hinausgehen, ja. Wäre auch schlimm, wenn nicht .

BasicMan01

SeppJ schrieb:

BasicMan01 schrieb:

Kann es sein, dass jeder Compiler seine eigene Headeranpassungen mitliefert.

Implementierungen dürfen Zusatzfeatures anbieten die über den Standard hinausgehen, ja. Wäre auch schlimm, wenn nicht .

Nun in Hinblick auf die Entwicklung ist des auch ganz positiv
Stelle mir blos grad vor, auf welche Problem man nun denn stößt, wenn man sein
geliebtes Programm dann mal unter anderer Entwicklungsumgebung kompilieren möchte und Reihenweise Warnungen und Fehler geworfen bekommt.

Nexus

Erweiterungen benutzt man natürlich nur, wenn man mit Nicht-Portierbarkeit leben kann. Oder man unterscheidet Fälle mit bedingter Kompilierung...

Für viele Fälle kommt man mit dem C++-Standard gut aus, darüber hinaus gibt es auch für etliche Anwendungsgebiete portable Bibliotheken.