Neues C++ Schlüsselwort ?

[phlox81]

Mal wieder was neues, was evtl. im kommenden Cpp0x Standard enthalten sein könnte:

Jeder kennt ja das Schlüsselwort friend, damit kann man Klassen mit anderen
Klassen befreunden, oder Funktionen den Zugriff auf Klassenvariablen erlauben.
Das neue Schlüsselwort enemy verhindert genau das, es verhindert, das ein
bestimmter Typ zugriff auf etwas erhält.

Mal ein Beispiel:

class B{};
template<class T>
class A
{
  enemy B;
};

Hier wird nun Klasse B kein objekt von class A instanzieren können,
da sie als enemy eingetragen ist. Mit enemy B*; könnte keine Klasse
auf das Template A zugreifen, die mit B beginnt.

Bei Templates kann das schon mal praktisch sein, z.b. ließe sich mit
enemy !isnumeric<T> verhindern, das T ein Typ ist, der nicht numerisch ist.

Auch könnte man enemy in der Argumentliste angeben, und somit
einen Typ einschränken:

template <class T = enemy !{float,int,char,double,complex}>
class test{};

Damit kann T nur float,int,char,double oder complex sein, sonst nichts.

Wie man sieht bietet enemy viele spannende Möglichkeiten.

Devil

[*lol*]

Ja dann...:P

[otze]

brauch man net, wozu gibts dokus und compiletime assertions?

//edit
aber ich seh auch keine gefahr, dass dein vorschlag jemals umgesetzt werden wird, ein so träges standardcommitee(is das so richtig geschrieben? Oo) wie es c++ hat tut sich ja schon schwer sowas zu erlauben:

class B{
    //...
};

template<class T:public B>
class C{
    //...
};

//edit2 dieses schlüsselwort is so sinnlos Oo
im moment is es ja so, dass man eh keine templates zu friends machen kann(und wohl niemals können wird), sodass wohl enemy auch kein template sein könnte. daraus folgt, dass die verfeindeten klassen schon soweit bekannt sind, dass man das problem einfach lösen könnte, in diesen klassen einfach nicht die verbotene Klasse zu instanzieren.

[net 0]

devil81 schrieb:

Jeder kennt ja das Schlüsselwort friend, damit kann man Klassen mit anderen
Klassen befreunden, oder Funktionen den Zugriff auf Klassenvariablen erlauben.
Das neue Schlüsselwort enemy verhindert genau das, es verhindert, das ein
bestimmter Typ zugriff auf etwas erhält.

gute idee! ich würde es aber eher 'foe' taufen.
auch noch gute schlüsselwörter wären 'neither', 'other' ....
und als operator 'maybe' --> ~=

if (a ~= b)
{
   // a ist vielleicht b
}

[volkard]

net schrieb:

gute idee! ich würde es aber eher 'foe' taufen.

schau auf struppis homepage. da erläutert der recht ausführlich, warum man sich auf "~friend" einigte. es tun sich die c++-leute sehr schwer damit tun, neue schlüsselwörter einzuführen, weil bestehende code kaputtgeht. welches strategiespiel oder welcher first-person-shooter hat denn nicht enemy als normalen variablennamen rumgammeln? und foo auch.
deswegen schreibt man ~friend statt enemy und jeder bisher korrekte code ist immernoch korrekt. !friend hätte den vorteil gehabt, daß man auch not friend schreiben kann, aber ~ wurde genommen, weil man bei destruktoren auch ~ nimmt. so merkt man es sich besser.
aber es ist schon wieder vom tisch. weil es für die compilerbauer recht einfach ist und für programmierer, die es nicht nehmen wollen, gar keinen einfluss hat, stand dem ~friend nichts schlimmes entgegen. aber es hat sich schnell ergeben, daß man alle effekte von ~friend mit friend und compilezeitnegierung über SFINAE "Substitution Failure Is Not An Error" auch erzeugen konnte.

[net 0]

volkard schrieb:

oder welcher first-person-shooter hat denn nicht enemy als normalen variablennamen rumgammeln? und foo auch.

nicht foo, foe

[phlox81]

volkard schrieb:

net schrieb:

gute idee! ich würde es aber eher 'foe' taufen.

schau auf struppis homepage. da erläutert der recht ausführlich, warum man sich auf "~friend" einigte. es tun sich die c++-leute sehr schwer damit tun, neue schlüsselwörter einzuführen, weil bestehende code kaputtgeht. welches strategiespiel oder welcher first-person-shooter hat denn nicht enemy als normalen variablennamen rumgammeln? und foo auch.
deswegen schreibt man ~friend statt enemy und jeder bisher korrekte code ist immernoch korrekt. !friend hätte den vorteil gehabt, daß man auch not friend schreiben kann, aber ~ wurde genommen, weil man bei destruktoren auch ~ nimmt. so merkt man es sich besser.
aber es ist schon wieder vom tisch. weil es für die compilerbauer recht einfach ist und für programmierer, die es nicht nehmen wollen, gar keinen einfluss hat, stand dem ~friend nichts schlimmes entgegen. aber es hat sich schnell ergeben, daß man alle effekte von ~friend mit friend und compilezeitnegierung über SFINAE "Substitution Failure Is Not An Error" auch erzeugen konnte.

Und dann kann man immer noch !~friend schreiben

[Shade Of Mine]

Ich hoffe nur, dass es man hier endlich konsequent regex in die sprache einbaut. Schliesslich schreit ~friend ja danach.

class MyClass
{
  ~friend /(C|T)[A-Z_].*/;
};

um so mal effektiv die
CObject oder TObject Leute auszusperren.

[key-c]

äh, April April!?

[Michael E.]

Wieso? Ich find die Vorschläge interessant.

[Shade Of Mine]

Michael E. schrieb:

Wieso? Ich find die Vorschläge interessant.

[Walli]

Hehe, wie war das noch mit dem Kopierdestruktor...?

[Michael E.]

Stimmt, der war auch cool.

[net 0]

Walli schrieb:

Hehe, wie war das noch mit dem Kopierdestruktor...?

praktisch. löscht gleich alle kind-objekte wech, wenn das eltern-objekt deleted wird. tjä, es fehlt noch viel in c++