C++ Schreib-still

Bei mir kommt public immer zu erst.

irgendwas.hpp

class Manager
{

    public:

  	// Ctor
	// *@param none
    Manager();

	// Dtor
	// *@param none
    ~Manager();

	// Call to initialize Manager
	//	*@param name player name
	//	*@return reference to this
    Manager& Init( const std::string & name);

    protected:
    // ....

    private:
    // ....
};

Noch vergessen zu erwähnen, dass mein Schreibstil natürlich am Schönsten ist.

asc

hustbaer schrieb:

...

...
#include <cryptopp/blah.h>         // anm: dann "andere" header (diverse libs)
...
#include <windows.h>               // anm: dann "standard" header
#include <algorithm>

Ich frage mich was an der windows.h Standard ist, wenn man im gleichen Zug die boost-Bibliotheken als "andere Header" auffasst... Was ist dann bitte schön Standard und was "Anderes" [Das Standard in diesem Fall nicht mit der Standardbibliothek zu tun hat, habe ich schon verstanden, aber wo ist die Grenzziehung?]...

cu André

Shade Of Mine

asc schrieb:

[Das Standard in diesem Fall nicht mit der Standardbibliothek zu tun hat, habe ich schon verstanden, aber wo ist die Grenzziehung?]...

windows.h hat jeder windows rechner. sie ist standardmäßig vorhanden.

für boost muss ich extra etwas installieren.

in meinen augen eine sinnvolle trennung

Ohje, da hab ich ja eine Diskussion angezettelt mit public und private - Reihenfolge

@Shade of Mine: Ich hoffe, ich habe dich richtig verstanden, dass ich mich unglücklich ausgedrückt habe? Natürlich interessieren einen manchmal auch die privaten Sachen (egal ob pimpl, oder Daten / Methoden).

blah123 schrieb:

irgendwas.hpp

class Manager
{

    public:

  	// Ctor
	// *@param none
    Manager();

	// Dtor
	// *@param none
    ~Manager();

	// Call to initialize Manager
	//	*@param name player name
	//	*@return reference to this
    Manager& Init( const std::string & name);

    protected:
    // ....

    private:
    // ....
};

@blah123:

Rufst du die Init-Methode mehrmals auf? Ansonsten ist sowas IMHO ein Konstrukt aus C-Zeiten. In C++ werden dafür Konstruktoren benutzen...

@Aquae

Nö. "Init" wird nur Einmal aufgerufen.

#include <iostream>
#include <string>

class Manager
{

    public:

  	// Ctor
	// *@param none
    Manager();

	// Dtor
	// *@param none
    ~Manager();

	// Call to initialize Manager
	//	*@param path directory path
	//	*@return reference to this
    Manager& Init( const std::string & name );
};

Manager::Manager()
{
	Init("yarr");
}

Manager::~Manager()
{
	// clean up
}

Manager & Manager::Init( const std::string & name)
{
   printf("%s\n", name.c_str() );

   return *this;
}

int main()
{
   Manager * _manage = new Manager();
   delete _manage;
   return 0;
}

Weiß nicht was daran aus "C-Zeiten" stammen soll, gut bis auf printf.. aber das is nur ne Angewöhnung da ich std::cout nicht mag.

Shade Of Mine

sehe den Sinn in Init nicht.
Erklaerst du mal warum du Init unbedingt brauchst?

Und statt printf gibt es boost::format...

Shade Of Mine schrieb:

sehe den Sinn in Init nicht.
Erklaerst du mal warum du Init unbedingt brauchst?

Und statt printf gibt es boost::format...

"Init" war nur ein Modifiziertes Beispiel aus einem Programm. Boost hab ich auf der platte, brauchte es noch nicht so oft, bis auf boost::asio.

Manager & Manager::Init( const std::string & path )
{
	WIN32_FIND_DATA	fileData;
	HANDLE			fileHandle;
	std::string		fileSearch;

	fileSearch = path + "\\*.jpg";
	fileHandle = INVALID_HANDLE_VALUE;
	memset( &fileData, 0, sizeof( WIN32_FIND_DATA ));

	fileHandle = FindFirstFileA( fileSearch.c_str(), &fileData );

	do 
	{
       if ( false == parseFileName( fileData.cFileName )) 
	   {
		   fileMap_.clear(); FindClose( fileHandle );
	   }

	} while ( TRUE == FindNextFileA( fileHandle, &fileData ));

	FindClose(fileHandle); IsInit_ = true;

	return *this;

}

Muss mir eig boost::filesystem angucken damit ich auf FindFirstFileA/FindNextFileA verzichten kann.

Shade Of Mine

Sehe den Sinn davon immer noch nicht.

Warum nicht in den CTor packen?

Und warum kein einheitliches Namensschema und warum hat parseFileName Seiteneffekte und warum kein RAII um das doppelte FindClose zu verhindern?

Shade Of Mine schrieb:

Sehe den Sinn davon immer noch nicht.

Warum nicht in den CTor packen?

Und warum kein einheitliches Namensschema und warum hat parseFileName Seiteneffekte und warum kein RAII um das doppelte FindClose zu verhindern?

Warum nicht in den ctor? Keine ahnung, wollte das so haben. Kannst mir ja erklären wieso ich es in den ctor packen sollte. Der Sinn dabei ist, dass ich ein Programm machen musste dass alle *.jpg dateien in einen container ablegt, da ich verschiedene von denen laden / zeichnen muss. War auch schnell geschrieben.. find das Namensschema nicht so schlimm. ^^ Gut bei FindClose hast du auch wieder recht... parseFileName soll halt abbrechen falls irgendwas schief läuft.

Damit meinte ich in C-Zeiten solche Initialize-Funktionen, die man jaaaa als erstes rufen sollte, damit alles klappt.

In C++ wird das in den Konstruktor verlagert. Natürlich kann dein Konstruktor auch klasseninterne Methoden rufen, wenn du nicht den Code unstrukturiert da drin haben willst. Diese sollten dann aber "private" sein.

EDIT: Oder du nimmst dir Helper-Funktionen in einem anonymen Namespace in der cpp, wenn du den Konstruktor implementierst.