Was ist besser: No Copy/No Assignment Basisklasse oder Makro

otze

weil es so einfacher ist, wenn man keine klassenhierarchie aufbaut,einfach von noncopyable erben, und schon viel weniger arbeit^^
ps: wir hatten schon otze. .otze und nun ötze was kommt als nächstes?

otze schrieb:

ps: wir hatten schon otze. .otze und nun ötze was kommt als nächstes?

atze :p

phlox81

Hm, wie würde ein solches Makro aussehen ?

Devil

#define DENY_COPY(CLASS) \
private: \
CLASS(const CLASS&); \
CLASS& operator=(const CLASS&);

Walli

devil81 schrieb:

Hm, wie würde ein solches Makro aussehen ?

Frag nicht . Das habe ich gestern nach ner Familienfeier und dem ~7. Bier gepostet und volkard hat sich einen Spaß draus gemacht es durch den Kakao zu ziehen. Der Thread müsste auch hier irgendwo einer der oberen sein.

otze

ich schätz mal so:

#ifdef _DEBUG
    #define NO_COPY(className) private: className& operator=(const className&){};className(const className&){} public:
#else
    #define NO_COPY(className)
#endif

rofl. was hat das mit debug zu tun? außerdem muss man die dinger nicht implementieren. kann ja eh keiner aufrufen.

otze

im debug mode tritt so direkt der fehler auf,im releasemode wird dafür der code nich zugemüllt

btw:

ich schätz mal so

das erhebt keinen anspruch auf absolute richtigkeit

otze schrieb:

im debug mode tritt so direkt der fehler auf,im releasemode wird dafür der code nich zugemüllt

Aber den Code kriegt man doch eh nicht zu Gesicht.

Ok, dann brauch der Compiler wahrscheinlich länger um zu compilieren.

Walli

Ausserdem wäre das Ding (von den anderen Sachen mal abgesehen) noch schlechter als meins, da du eine private-Section in dem Makro versteckst.

glaub ich nicht. das muss das makro schon drin haben.

wenn jemand schreibt:

public:
    Foo();
    Bar();
    DENY_COPY(xxx);

erfüllt das Makro doch nicht mehr seinen Zweck.

Walli

Nein, das würde in der Verantwortung des Programmierers liegen. Oder das Makro muss die Section nachher wieder zurücksetzen. Aber worauf? public oder protected? Aber wie gesagt... das Makro war im wahrsten Sinne eine "Schnapsidee"!

public:
    DENY_COPY(Foo); // "private:" enthalten
    Foo(); // Foo ist nicht mehr public, sieht aber keiner

ich verwende:

#ifndef NOCOPY_H
#define NOCOPY_H

class NoCopy{
private:
	NoCopy(NoCopy const&);
	NoCopy& operator=(NoCopy const&);
public:
	NoCopy(){
	}
};
#ifndef NDEBUG
	#define NOCOPY NoCopy _noCopy
#else
	#define NOCOPY typedef int _noCopy
#endif

#endif

Das sieht ja sehr interessant aus. Das umgeht ja die Probleme der anderen beiden Möglichkeiten.

phlox81

volkad schrieb:

ich verwende:

#ifndef NOCOPY_H
#define NOCOPY_H

class NoCopy{
private:
	NoCopy(NoCopy const&);
	NoCopy& operator=(NoCopy const&);
public:
	NoCopy(){
	}
};
#ifndef NDEBUG
	#define NOCOPY NoCopy _noCopy
#else
	#define NOCOPY typedef int _noCopy
#endif

#endif

Eine Sehr schöne Basisklasse

Devil

Hey volkad,

warum eigentlich "typedef int _noCopy"? Käme

#define NOCOPY

nicht auf das Gleiche raus?

@devil: Das sollte doch gar nicht als Basisklasse gedacht sein?!?

Shade Of Mine

prob schrieb:

warum eigentlich "typedef int _noCopy"? Käme

#define NOCOPY

nicht auf das Gleiche raus?

Dann hättest du einen ; mitten in der KLassendefinition stehen...

@devil: Das sollte doch gar nicht als Basisklasse gedacht sein?!?

Natürlich keine Basisklasse, sondern Member.

Sobald ein Member nicht Copyable ist, kann der Compiler keine Default Aktionen mehr erstellen.

volkard

prob schrieb:

Hey volkad,
warum eigentlich "typedef int _noCopy"? Käme
#define NOCOPY
nicht auf das Gleiche raus?
@devil: Das sollte doch gar nicht als Basisklasse gedacht sein?!?

eigentlich sollte ich das als rätsel stehen lassen.
.
.
.
spoiler
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
meine makros dürfen immer mit abschließendem semikolon geschrieben werden. das ist manchmal wichtig, wie bei

//schlechtes assert
#ifndef NDEBUG
   #define ASSERT(x) if(!x) throw "fehler";
#else
   #define ASSERT(x)
#endif

ASSERT(sizeof(int)==4)//klappt wurnderbar

if(bar)
   if(foo)
      ASSERT(false)//aua!
   else
      cout<<"seltsam";

aber auch
if(bar)
if(foo)
ASSERT(false);//aua!
else
cout<<"seltsam";
[/cpp]
das führt zur generellen forderung, daß makros nie ein semikolon am ende einbringen. also mindestens mal

//schlechtes assert
#ifndef NDEBUG
   #define ASSERT(x) if(!x) throw "fehler"
#else
   #define ASSERT(x)
#endif

ASSERT(sizeof(int)==4);//klappt wurnderbar

if(bar)
   if(foo)
      ASSERT(false);// aua?
   else
      cout<<"seltsam";

naja, das aua? tut auch noch weh. das else drunter bindet im debug-mode das if aus dem makro und im release-mode das if(foo).
also

#ifndef NDEBUG
   #define ASSERT(x) if(x);else throw "fehler"
#else
   #define ASSERT(x)
#endif

und wenn man sich angewöhnt, daß makros generell nicht ihr eigenes semikolon einbringen, daß man aber immer ein semikolon am ende setzen darf, muß es bei NOCOPY geeignet abgefackelt werden. ein alleinstehendes semikolon innerhalb der klasse ist nach c++-standard verböten. daher das typedef.

Shade Of Mine

und wenn man if(false){}else foo
statt if(false);else foo
schreibt - kann man auch einige Compilerwarnungen umgehen

otze

MaSTaH schrieb:

Nein, das würde in der Verantwortung des Programmierers liegen. Oder das Makro muss die Section nachher wieder zurücksetzen. Aber worauf? public oder protected? Aber wie gesagt... das Makro war im wahrsten Sinne eine "Schnapsidee"!
public:
    DENY_COPY(Foo); // "private:" enthalten
    Foo(); // Foo ist nicht mehr public, sieht aber keiner

doch, ganz zum schluss kommt ein nettes public, lieber MaSTaH, lesen lernen :p

@Volkard gute idee, aber leider auch wieder gut auszuhebeln