wird C++0x ein 'restrict' keyword haben?

[LordJaxom]

Nukularfüsiker schrieb:

Tim schrieb:

Having a feature in the standard that can't be tested for conformance and that has no semantics associated with it (a compiler can ignore restrict without changing the behavior of a valid program) seemed inappropriate.

Das trifft doch genauso auf inline zu, nicht wahr?

Nicht ganz. Inline ermöglicht, Funktionen in Headern zu definieren und dennoch die ODR einzuhalten. Das darf der Compiler auch nicht ignorieren. Er darf allerdings entscheiden, diese Funktionen nicht zu inlinen.

audacia schrieb:

(*: Hat jemand eine brauchbare Idee, wie man "to deprecate" ohne Klimmzüge wie "für veraltet erklären" im Deutschen ausdrücken könnte?)

Wörtlich: missbilligen

[volkard]

rüdiger schrieb:

Nein, restrict wird es leider nicht geben. Ich weiß auch nicht warum. Vorallem wird es ja bereits von vielen Compilern unterstützt und ist imho ein sehr sinnvolles Feature.

Das sehe ich anders. Aber sowas von.

[krümelkacker]

Für überflüssig halte ich "inline" nicht. Denn die "one definition rule" enthält ja auch Sonderregeln für inline-Funktionen. ZB dürfen diese mehrfach definiert werden, solange das in verschiedenen Übersetzungseinheiten passiert. Das ist natürlich praktisch, da der Compiler es einfacher hat, zu "inlinen", wenn die Definition bekannt ist. Bei Compilern/Linkern, die keine "link time optimization" durchführen (was praktisch die Regel ist) müsste man sich sonst mit static behelfen, wenn das inline-Schlüsselwort abgeschaft werden würde. In C wär das kein großer Verlust, da es in C keine Sonderregeln für inline gibt. Aber in C++ würde ich es vermissen, inline-Funktionen mit externer Bindung in mehreren ÜEs definieren zu können.

[Gast]

Interessant wär's doch sicher auch mal, register zu kicken, oder? Auf sowas hat die Welt glaub ich damals schon nicht gewartet.

[audacia]

LordJaxom schrieb:

audacia schrieb:

(*: Hat jemand eine brauchbare Idee, wie man "to deprecate" ohne Klimmzüge wie "für veraltet erklären" im Deutschen ausdrücken könnte?)

Wörtlich: missbilligen

Ja, bei LEO kann ich auch selbst nachschlagen

[Dravere]

volkard schrieb:

rüdiger schrieb:

Nein, restrict wird es leider nicht geben. Ich weiß auch nicht warum. Vorallem wird es ja bereits von vielen Compilern unterstützt und ist imho ein sehr sinnvolles Feature.

Das sehe ich anders. Aber sowas von.

Könntest du das etwas näher ausführen? Wieso erachtest du es nicht als sinnvolles Feature?

@audacia,
"deprecaten"
Aber wenn du schon auf LEO schauen gehen kannst, dann schau doch auch im Forum nach. Hat da zum Teil ganz interessante Diskussionen zu solchen Wörtern. Zum Beispiel auch für deprecated.

Grüssli

[Nexus]

Optimizer schrieb:

Interessant wär's doch sicher auch mal, register zu kicken, oder? Auf sowas hat die Welt glaub ich damals schon nicht gewartet.

Es wäre auch weniger hart für auto , wenn gleich zwei Speicherklassenschlüsselworte in den Ruhestand träten.

[volkard]

Dravere schrieb:

Könntest du das etwas näher ausführen? Wieso erachtest du es nicht als sinnvolles Feature?

Weil ich das prinzipiell nur dem Compiler aufhalsen will. Ok, geht nur oft, aber nicht immer. Naja, dann soll es gerne Compilerlokal sein. MS wird vielleicht mit #pragma machen und GCC vielleicht mit __restricted__ oder doch andersrum. Das hat man ja schnell weggemakrot, falls man zufällig für beide entwickelt.

[unskilled]

volkard schrieb:

Dravere schrieb:

Könntest du das etwas näher ausführen? Wieso erachtest du es nicht als sinnvolles Feature?

Weil ich das prinzipiell nur dem Compiler aufhalsen will.

Was spricht denn überhaupt für das Nutzen des keywords, so fern es es denn geben würde? Mir würde gerade keine Situation einfallen, wo der Compiler das nicht von alleine schon "weiß".

bb

[rüdiger]

volkard schrieb:

Dravere schrieb:

Könntest du das etwas näher ausführen? Wieso erachtest du es nicht als sinnvolles Feature?

Weil ich das prinzipiell nur dem Compiler aufhalsen will. Ok, geht nur oft, aber nicht immer. Naja, dann soll es gerne Compilerlokal sein. MS wird vielleicht mit #pragma machen und GCC vielleicht mit __restricted__ oder doch andersrum. Das hat man ja schnell weggemakrot, falls man zufällig für beide entwickelt.

Der Compiler kann Aliasing höchstens erkennen, wenn er Funkionen inlined. Das C99 restrict eingeführt hat, kommt ja aus der Praxis. Vorallem weil die Scientificcomputing-Leute sich darüber geärgert haben, dass die Fortran-Compiler teilweise besseren Code generieren konnten (Fortran hat kein Aliasing-Problem). Mittlerweile gehen einige Compiler so weit und generieren Code der Aliasing berücksichtigt und Code der davon ausgeht, dass kein Aliasing auftritt und fügen dann eine Laufzeitüberprüfung ein, welcher Code genommen werden soll. Dies ist natürlich alles andere als optimal, da es den Code aufbläht und man eine Laufzeitüberprüfung braucht. Und warum sollte restrict nicht einfach standardisiert sein? Dann spart man sich die Macrofrickeleien und den Kampf mit kleinen Unterschieden.

unskilled schrieb:

volkard schrieb:

Dravere schrieb:

Könntest du das etwas näher ausführen? Wieso erachtest du es nicht als sinnvolles Feature?

Weil ich das prinzipiell nur dem Compiler aufhalsen will.

Was spricht denn überhaupt für das Nutzen des keywords, so fern es es denn geben würde? Mir würde gerade keine Situation einfallen, wo der Compiler das nicht von alleine schon "weiß".

void a(int *p, int *q);

[volkard]

rüdiger schrieb:

void a(int *p, int *q);

Ausdrücken, daß p!=q?
Kein Problem!

void a(int *p, int *q)
{
   ASSERT(p!=q);
}

Hier kommt erstmal nur raus, daß dem GCC das __assume fehlt. Keine Ahnung, warum es fehlt. Ich vermute religiöse Gründe.
Würde restricted auch ausdrücken, da0 p+17 != q+29?

[Bashar]

volkard schrieb:

Würde restricted auch ausdrücken, da0 p+17 != q+29?

Wenn das in der Funktion relevant ist, ja.

[rüdiger]

restrict würde sagen, dass p und q exklusiven Zugriff auf den Speicherbereich haben auf den über sie zugegriffen wird. Das ist mehr als p!=q. Ich kenne __assume nicht (ich nehme aber eher an, dass der GCC das nicht aus religiösen Gründen nicht hat vielleicht hat es einfach nur niemand eingebaut). Aber kann man damit so eine Aussage treffen?

[volkard]

rüdiger schrieb:

restrict würde sagen, dass p und q exklusiven Zugriff auf den Speicherbereich haben auf den über sie zugegriffen wird. Das ist mehr als p!=q. Ich kenne __assume nicht (ich nehme aber eher an, dass der GCC das nicht aus religiösen Gründen nicht hat vielleicht hat es einfach nur niemand eingebaut). Aber kann man damit so eine Aussage treffen?

__assume(cond) ist wie builtin_expect(cond,true), nur viel stärker. Der Compiler kann sich auf __assume verlassen. Falls die Annahme falsch ist, darf er falschen Code erzeugen. Bekannt (falls man es überhaupt bekannt nennen darf)wurde es bei

switch(x){
  case 1: ...
  case 2: ...
  case 3: ...
  default: __assume(false);//macht das if(x>=1 && x<=3) vor dem Tabellennachguckerchen weg. 
}

Im Fall, daß p und q nur Arrays sind, bekäme man mit __assume(p<=q && q<=p+pSize) und so schon was hin.

Man bekäme nicht hin, daß p->leftChild->leftChild->rightChild!=q->parent->leftChild.
Naja, darum gehts aber wohl auch nicht. Der ASSERT/__assume-Trick bläht bei vielen Zeigern mit O(Zeigeranzahl^2) auf.
Der da http://www.cs.pitt.edu/~mock/papers/clei2004.pdf scheint von restrict nicht mehr so viel zu halten. Ich mag sowas natürlich, aber als was Compilerspezifisches vielleicht noch lieber, als in die Sprache rein.

[Bashar]

volkard schrieb:

Im Fall, daß p und q nur Arrays sind, bekäme man mit __assume(p<=q && q<=p+pSize) und so schon was hin.

Und wer sagt, dass das dem Compiler was bringt? Wie weit wird denn die assume-Bedingung ausge- und verwertet? Was der Compiler eigentlich will ist Hilfestellung bei der Aliasanalyse. restrict liefert das unmittelbar, bei assume müsste er die Bedingung erstmal verstehen und daraus für die Optimierung verwertbare Aussagen generieren.
Ich würde vermuten, dass das nur für direkt verwendbare Aussagen und gewisse Spezialfälle funktioniert, und ansonsten ignoriert wird.

Hab hier was in der MSDN gefunden:

There are some limitations to __assume. First, like __restrict, it is only a suggestion, so the compiler is free to ignore it. Also, __assume currently works only with variable inequalities against constants. It does not propagate symbolic inequalities, for example, assume(a < b).

Nur Vergleiche mit Konstanten, mit anderen Worten, er benutzt das, um den Wertebereich von Variablen einzugrenzen. Keine Magie.

[JustAnotherNoob]

Und sicherlich fällt irgendjemandem eine kreative Überladung dafür ein, die etwa so viel mit Inlining zu tun hat wie delete mit Standardkonstruktoren oder enum mit class.

so wie inline namespaces?