C++ Schreib-still

hustbaer

Kommentare wie "//----------> Getter! <----------//" sind für mich
a) "noise"
b) "undocumentation" (wassndas?)
Finde ich garnicht gut.

Wenn eine "optische Trennung" erwünscht ist, dann mach ich einfach ne Zeile

/////////////////////////////////////////////////////////////////////////

und gut is.

Wenn wir allerdings zwischen jeder Funktion so eine Zeile einziehen ... sind wir schnell wieder beim Thema "noise".

hustbaer

@Shade Of Mine:
Ich schätze du willst eigentlich wissen wie franz das macht, aber ich schreib trotzdem einfach mal wie sowas bei mir aussieht:

#pragma once

#include "Common.h"                // anm: erst "meine" header
#include "WasIchNochBrauch.h"

#include <cryptopp/blah.h>         // anm: dann "andere" header (diverse libs)
#include <boost/noncopyable.h>

#include <windows.h>               // anm: dann "standard" header
#include <algorithm>

namespace Blubb
{

///////////////////////////////////////////////////////////////////////////

class Foo:
    public XYZ,
    private boost::noncopyable
{
    friend Bar;
public:
    //! doku
    Foo();

    //! doku
    Foo(P1 p1, P2 p2);

    ~Foo(); // anm: bekommt sicher keine doku wenn's hier nicht was ganz seltsames zu beachten gibt

    size_t GetWidth() const;  //!< doku
    size_t GetHeight() const; //!< doku

private:
    void Fun() const;
    void Joy();

    static void JoyJoyHappyHappyJoyJoy();

    class InnerClass
    {
        // ...
    };

    size_t m_width;   //!< doku
    size_t m_height;  //!< doku
    boost::shared_ptr<InnerClass> m_inner;
};

} // namespace Blubb

hustbaer

FreakY<3Cpp schrieb:

Shade Of Mine schrieb:
FreakY<3Cpp schrieb:
void setData(T); ///nur den Typ und nicht den Namen der Variable festlegen
Warum?
Klar geht es, aber ich hab bisher noch nie in der Klasse den Variablennamen festgelegt.

Das ist doch der Blanke Horror (tm)!

Wenn ich in ein Header-File reingucke, dann will ich wissen was es für Funktionen gibt, was die machen, und welcher Parameter welcher ist.
Wenn da keine Namen dabeistehen... toll. Ausserdem können die meisten IDEs Header-Files parsen und hübsche Hilfsfenster einblenden.
Hilft mir aber wenig wenn in dem Hilfsfenster dann keine Parameter-Namen stehen.

Und vonwegen festlegen: du legst garnix fest, du kannst bei der Implementierung einen ganz anderen Namen verwenden:

//header:
void Foo(int dasWasAusgedrucktWerdenSoll);

//impl:
void Foo(int v)
{
    printf("%d\n", v);
}

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.