Die RICHTIGE Art zu konvertieren



  • Zeig bitte mal die Klasse CConvert ...



  • Swordfish schrieb:

    Zeig bitte mal die Klasse CConvert ...

    Bin gerade am ändern. Gib mir ein paar Minuten. Btw. die Klasse ist nicht gerade spektakulär...



  • Die cpp ist noch unkommentiert.

    #ifndef CConvert_HPP
    #define CConvert_HPP
    
    // standard headers
    #include <string>
    
    // sfml headers
    
    // classes
    
    // forward declarations
    
    // CConvert class: manages all conversions
    class CConvert
    {
    	private:
    		// string buffer
    		std::string m_stStringBuffer;
    
    		// int buffer
    		int m_nIntBuffer;
    
    	public:
    		// convert int to const char*
    		const char* IntToChar (int p_nInt);
    
    		// convert const char* to int
    		int CharToInt (const char *p_pchChar);
    };
    
    #endif
    
    // include needed headers
    #include "CConvert.hpp"
    
    const char* CConvert::IntToChar (int p_nInt)
    {
    	m_stStringBuffer = std::to_string (p_nInt);
    
    	return m_stStringBuffer.c_str ();
    }
    
    int CConvert::CharToInt (const char *p_pchChar)
    {
    	m_nIntBuffer = std::stoi (p_pchChar);
    
    	return m_nIntBuffer;
    }
    


  • Bizarreofnature schrieb:

    EDIT: Saubere ungarische Notation 🙂

    pch --> sz
    p_ für Funktionsparameter kennt die originale HN eigentlich nicht.

    Zum Rest sag ich jetzt nur, was Dir schon mehrfach gesagt wurde. Benutze std::string . Warum stecken die beiden Funktionen überhaupt in einer Klasse? Zustand sollten beide keinen haben und zum thematisch Zusamenfassen tuts ein Namespace.



  • Swordfish schrieb:

    Bizarreofnature schrieb:

    EDIT: Saubere ungarische Notation 🙂

    pch --> sz
    p_ für Funktionsparameter kennt die originale HN eigentlich nicht.

    Zum Rest sag ich jetzt nur, was Dir schon mehrfach gesagt wurde. Benutze std::string . Warum stecken die beiden Funktionen überhaupt in einer Klasse? Zustand sollten beide keinen haben und zum thematisch Zusamenfassen tuts ein Namespace.

    Die Klasse wird eventuell noch größer und da bin ich froh wenn es abgekapselt ist.

    Soll ich jedes pch mit einem sz ersetzen? 😕



  • Btw das mit den Namespace finde ich interessant. Gibts dazu gute Tutorials?



  • #include <string>
    
    namespace Conversions {
    
    	std::string ToString(int number)
    	{
    		return std::to_string(number);
    	}
    
    	int ToInt(std::string const &str)
    	{
    		return std::stoi(str);
    	}
    }
    
    int main()
    {
    	char const * sz{ "1234" };
    	int n = Conversions::ToInt(sz);
    	std::string str = Conversions::ToString(n);
    }
    


  • Genial! Vielen Dank 🙂



  • Es klappt. Total genial. Vielen Dank nochmal 🙂 wieder was gutes dazu gelernt.

    Eine Frage noch. Wo genau binde ich die namespace Datei ein? in der "main.cpp" ?



  • Bizarreofnature schrieb:

    Wo genau binde ich die namespace Datei ein? in der "main.cpp" ?

    Dort, wo Du die darin deklarierten Funktionen brauchst??

    Convert.hpp

    #ifndef Convert_HPP
    #define Convert_HPP
    
    #include <string>
    
    namespace Convert {
    
        std::string ToString(int number);
        int ToInt(std::string const &str);
    }
    
    #endif /* Convert_HPP */
    

    Convert.cpp

    #include "Convert.hpp"
    
    namespace Convert {
    
        std::string ToString(int number)
        {
            return std::to_string(number);
        }
    
        int ToInt(std::string const &str)
        {
            return std::stoi(str);
        }
    }
    


  • Alles klar, vielen Dank 🙂



  • So etwas wie "private" oder "public" gibts bei namespace nicht, oder?



  • Nein.

    ^Ich frag jetzt mal bewusst nicht warum man das haben wollen würde.^



  • Swordfish schrieb:

    Nein.

    ^Ich frag jetzt mal bewusst nicht warum man das haben wollen würde.^

    #include <string>
    
    namespace Convert
    {
    	std::string m_stStringBuffer;
    
    	const char* IntToChar (int p_nInt)
    	{
    		m_stStringBuffer = std::to_string (p_nInt);
    
    		return m_stStringBuffer.c_str ();
    	}
    }
    

    Komme leider nicht drum rum.



    Swordfish schrieb:

    Zustand (dein m_stStringBuffer *)) sollten beide [Funktionen] keinen haben [...]

    Printe schrieb:

    std::string ist char* in jeder Hinsicht überlegen. Wenn du trotzdem mit char* arbeiten willst, solltest du dafür extrem gute Gründe haben.

    SeppJ schrieb:

    warum keine Strings?

    😉 jetzt wird es mit m_... noch enger, denn Namespaces sind keine Klassen oder Structs, von denen es Instanzen geben könnte. Dein m_stStringBuffer ist eher ein g(lobal)_sonstwas .



  • Swordfish schrieb:

    Swordfish schrieb:

    Zustand (dein m_stStringBuffer *)) sollten beide [Funktionen] keinen haben [...]

    Printe schrieb:

    std::string ist char* in jeder Hinsicht überlegen. Wenn du trotzdem mit char* arbeiten willst, solltest du dafür extrem gute Gründe haben.

    SeppJ schrieb:

    warum keine Strings?

    😉 jetzt wird es mit m_... noch enger, denn Namespaces sind keine Klassen oder Structs, von denen es Instanzen geben könnte. Dein m_stStringBuffer ist eher ein g(lobal)_sonstwas .

    Achso, ja das war ein Typo.. habs einfach aus meiner Klasse kopiert.



  • Lass diesen ganzen Unsinn weg.
    Ganz genau das, was du da machst, gibt es schon. Du verwendest es ja sogar in deiner Funktion.
    Du sorgst nur noch einmal dafür, dass es langsamer wird - etwas, was du doch eigentlich nicht willst, oder?

    Verwende std::to_string() und std::stoi(). Das ist genau das, was du suchst.
    Weder mehr noch weniger.

    Irgendwie habe ich bei dir auch definitiv das Gefühl, dass da einige (bis viele) dringend benötigte Grundlagen fehlen...



  • me_and_cpp schrieb:

    Lass diesen ganzen Unsinn weg.
    Ganz genau das, was du da machst, gibt es schon. Du verwendest es ja sogar in deiner Funktion.
    Du sorgst nur noch einmal dafür, dass es langsamer wird - etwas, was du doch eigentlich nicht willst, oder?

    Verwende std::to_string() und std::stoi(). Das ist genau das, was du suchst.
    Weder mehr noch weniger.

    Irgendwie habe ich bei dir auch definitiv das Gefühl, dass da einige (bis viele) dringend benötigte Grundlagen fehlen...

    Ich habe mein letztes Projekt ganz normal mit strings gemacht.
    Ich verwende char weil ich bis jetzt nie richtig damit gearbeitet habe.

    P.S. Ich habe wieder ein Problem.
    Beim Einbinden meiner namespace hpp gibt es folgenden Fehler.. (erstmal code):

    #ifndef NConvert_HPP
    #define NConvert_HPP
    
    #include <string>
    
    namespace Convert 
    {
    	// string buffer
    	std::string stStringBuffer;
    
    	// char to int 
    	int CharToInt(const char *p_szChar);
    
    	// int to char
    	const char* IntToChar(int p_nInt);
    }
    
    #endif
    
    #include "NConvert.hpp"
    
    namespace Convert
    {
    	int CharToInt(const char *p_szChar)
    	{
    		return std::stoi(p_szChar);
    	}
    
    	const char* IntToChar(int p_nInt)
    	{
    		stStringBuffer = std::to_string(p_nInt);
    
    		return stStringBuffer.c_str();
    	}
    }
    

    Fehler LNK2005 "class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > Convert::stStringBuffer" (?stStringBuffer@Convert@@3V?basic_string@DU?basic\_string@DU?char_traits@D@std@@V?$allocator@D@2@@std@@A) ist bereits in NConvert.obj definiert.

    Fehler LNK1169 Mindestens ein mehrfach definiertes Symbol gefunden.



  • Bizarreofnature schrieb:

    Ich habe mein letztes Projekt ganz normal mit strings gemacht.
    Ich verwende char weil ich bis jetzt nie richtig damit gearbeitet habe.

    Und so wie du es jetzt mit C-Strings (so nennt man das, wozu du char sagst) machst, ist es nicht Fisch und nicht Fleisch, denn wenn schon C-Strings, dann übergibt man solchen Funktionen in der Regel einen Buffer und dessen Größe und lässt die Funktion den bereitgestellten Buffer befüllen. So, wie es auch std::itoa() macht.

    me_and_cpp schrieb:

    Irgendwie habe ich bei dir auch definitiv das Gefühl, dass da einige (bis viele) dringend benötigte Grundlagen fehlen...

    +1



  • Hab den Bug gefunden. Danke trotzdem 🙂


Anmelden zum Antworten