Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » C / C++ (ANSI-Standard) » Verwendung eines string()-Wandlungsoperators

Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: > 1 <
000
31.08.2006, 19:49 Uhr
Yadgar



High!

Wie ao schon heute mittag meinte, toben sich Dozenten und Lehrbuchautoren gerne beim Thema "Überladen von Operatoren" aus, obwohl man das in der Praxis nur selten braucht... manchmal scheinen aber auch die Gurus den Überblick zu verlieren, wie z. B. Martin Aupperle auf S. 588 von "Die Kunst der Programmierung mit C++". Da wird ein string()-Operator für die Bruch-Klasse FractInt definiert und implementiert:


C++:
FractInt::operator string() const
{
   char buf[32];
   sprintf(buf, "(%d, %d)", zaehler, nenner);
   return buf;
}



dann aber im Aufruf, da cout ja angeblich intern nur mit C-Strings arbeitet, sowas hier:


C++:
FractInt f1 (3, -3);

cout << "Der Wert von f1 ist " << f1.c_str() << endl;



...was natürlich gar nicht funktionieren kann. Wenn ich c_str() weglasse, kommt übrigens für f1 unabhängig vom tatsächlichen Wert im Ausgabestream immer "1" raus...

Bis bald im Khyberspace!

Yadgar
--
Flagmaker - ein Programmier-Blog
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
001
31.08.2006, 20:12 Uhr
FloSoft
Medialer Over-Flow
(Administrator)


mach halt lieber einen const char * operator
--
class God : public ChuckNorris { };
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
002
31.08.2006, 20:22 Uhr
Yadgar



High!


Zitat von FloSoft:
mach halt lieber einen const char * operator


Dann gibt es zwar keine Fehlermeldung, aber ich bekomme immer noch nur den unsinnigen Wert "1" für jegliches FractInt-Objekt!

Bis bald im Khyberspace!

Yadgar
--
Flagmaker - ein Programmier-Blog
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
003
31.08.2006, 20:53 Uhr
~Blubber2063
Gast


Also ich bin mir da jetzt nicht sicher, weil ich diesen Operator noch nie benutzt habe aber normalerweise steht der return type vorne, dann existiert dein Puffer nach dem verlassen des Operators nicht, bei Pointer hilft es nix das so zurückzugeben. Und nehmen wir mal an das dass string vor dem () Operator als Returntype akzeptiert wird, dann musst du auch einen string zurückgeben und nicht einen char*. Es ist auch vollkommen egal ob du da in nen C-String wandelst oder nicht, der << Operator ist für string überladen.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
004
31.08.2006, 22:39 Uhr
stephanw
localhorst


@blubber: die Signatur des operators ist richtig - ist eben so bei Konvertierungsoperatoren. Und die Rückgabe sollte auch klappen, da der Rückgabetyp ja std::string ist. Also wird vorher aus dem char-Feld buf ein std::string gemacht, also zu einem Zeitpunkt, an dem buf gültig ist.

@Yadgar: an dem sprintf wird es zwar nicht liegen, aber guter C++-Stil ist das nicht. Da verwendet man Streams:

C++:
#include <sstream>

FractInt::operator string() const
{
  std::ostringstream os;
  os << "(" << zaehler << ", " << nenner << ")";
  return os.str();
}



Ansonsten wundert es mich, dass "f1.c_str()" bei Dir kompiliert. Schließlich gibt es kein FracInt::c_str() .

Was verwendest Du für einen Compiler ?

Ich habe das gerade mal ins MS VC Express reingeworfen. Wenn ich in der Ausgabe-Zeile explizit f1 auf string caste, geht es bei mir. Ohne den Cast übersetzt es nicht, da er offenbar nicht erkennt, dass aus FracInt ein string gemacht werden kann. Biete ich dagegen einen FracInt::operator int() an (für Testzwecke), kompiliert das Programm. Gibt es da eine Unterscheidung, dass nach Konvertierungsoperatoren für eingebaute Typen gesucht wird, für höhere Typen jedoch nicht ?

Ich weiß schon, warum ich Konvertierungsoperatoren nicht oft benutze... für die Auflösungsregeln von solchen Sachen und evtl. vorhandener Mehrdeutigkeiten ist mein Gehirn zu klein
--
Reden ist Schweigen und Silber ist Gold.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
005
31.08.2006, 23:29 Uhr
~Blubber2063
Gast


Also das nenn ich aber schon pervers, wenn der Standard beim return die implizite Konvertierung vorsieht. Also für einige Sachen sind Operatorenüberladungen ja ganz nett, aber dieser Klammeroperator erscheint mir doch reichlich... . Naja egal, das mit den Streams ist schon richtig, ich würde bei solch kleinen Einsatzgebieten aber um den Overhead zu vermeiden, bei atoi, bzw atol bleiben.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
006
01.09.2006, 09:40 Uhr
Yadgar



High!


Zitat von ~Blubber2063:
Also ich bin mir da jetzt nicht sicher, weil ich diesen Operator noch nie benutzt habe aber normalerweise steht der return type vorne, dann existiert dein Puffer nach dem verlassen des Operators nicht, bei Pointer hilft es nix das so zurückzugeben.



Das leuchtet mir ein... könnte man das Problem umgehen, indem man im Operator für buf den Speicher dynamisch anfordert? Bei der Rückgabe von Referenzen auf erst in der Funktion erzeugte Objekte funktioniert das doch auch...


Zitat von ~Blubber2063:

Es ist auch vollkommen egal ob du da in nen C-String wandelst oder nicht, der << Operator ist für string überladen.


Dachte ich es mir doch, ich wunderte mich schon, weshalb cout ausgerechnet mit string nicht funktionieren sollte... Aupperle schreibt hier sichtlich Kokolores!

Bis bald im Khyberspace!

Yadgar
--
Flagmaker - ein Programmier-Blog
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
007
01.09.2006, 09:44 Uhr
Yadgar



High!


Zitat von stephanw:
Ansonsten wundert es mich, dass "f1.c_str()" bei Dir kompiliert. Schließlich gibt es kein FracInt::c_str() .



Moment, das habe ich nicht behauptet! Natürlich gibt es eine Fehlermeldung, die genau dies moniert...

Bis bald im Khyberspace!

Yadgar
--
Flagmaker - ein Programmier-Blog
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
008
01.09.2006, 10:21 Uhr
stephanw
localhorst



Zitat von ~Blubber2063:
Also das nenn ich aber schon pervers, wenn der Standard beim return die implizite Konvertierung vorsieht.

Na gut, im Prinzip gebe ich Dir recht. Es wäre klarer, wenn man explizit den deklarierten Rückgabetyp zurückgibt.

Andererseits:

C++:
std::string getStr()
{
  return "blub";
}


Rückgabetyp: std::string
Vom Programmierer angeboten: const char*
Was der Compiler implizit draus macht:

C++:
std::string getStr()
{
  return std::string( "blub" );
}


Man kann sich im Debugger prima durch den (impliziten) String-Konstruktor-Aufruf klicken.

Und in meiner Eigenschaft als Krümelkacker füge ich noch hinzu, dass der von Yadgar präsentierte Operator ein Konvertierungsoperator ist, kein Klammeroperator
--
Reden ist Schweigen und Silber ist Gold.

Dieser Post wurde am 01.09.2006 um 10:23 Uhr von stephanw editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
009
01.09.2006, 10:59 Uhr
~Blubber2063
Gast


Jo das ist schon klar, hab das gestern gleich noch getestet, finde aber das man bei so impliziter Konversion, wenigstens n Warning kriegen könnte, dass muss ja nicht immer der Weg sein, wie man die Konversion durchführen will. Ich finds zwar gute das man durch den Konstruktor implizit den Zuweisungsoperator überlädt so das man den benutzen kann, aber beim return finde ich es doch nicht unbedinngt einsichtig, ist ein wenig so als wenn man if(bla =0) oder sowas schreibt, da kriegt man ja auch n Warning .
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: > 1 <     [ C / C++ (ANSI-Standard) ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: