C
Optimizer schrieb:
solche mantras im stile von inline ist böse, pointer sind böse, operatoren sind böse, etc... hebst du dir besser für jemand anderes auf. im übrigen bin ich überhaupt nicht auf die frage eingegangen, ob der einsatz von inline in diesem konkreten fall (das heisst obigem klassen template) überhaupt sinnvoll ist. DARAUF angewandt macht deine argumentation sinn und ich stimme ihr auch zu.
Leg mir doch nicht einfach irgendwas in den Mund. Ich habe niemals gesagt, dass inline böse ist. Ich habe gesagt, dass es Unfug ist, statt inline grundsätzlich __forceinline zu schreiben.
Nichts anderes machst du nämlich mit deinem Makro. Bei dir gibt's gar kein normales inline. Aber das siehst du ja auch nicht ein.
entschuldige bitte, dass ich dich falsch vertanden habe. dafür genügt aber ein #undef nachdem alle relevanten deklarationen erfolgt sind - davon hab ich nichts gesagt und du hast auch nicht gefragt, insofern ist akzeptiere ich die kritik. eben weil der unterschied zwischen __forceinline und normalen inline so klein ist, wird sich in aller regel niemand die mühe machen, funktionen selektiv entweder mit dem einen oder dem anderen zu deklarieren. und daher kann es sinn machen, eine ganze gruppe gleichartiger funktionen, von denen man will, dass sie stets geinlined werden (was leider so nicht geht), derartig zu deklarieren. wie du sicher zustimmen wirst, fängt man ja damit an, funktionen mit inline zu deklarieren, und nicht mit __forceinline. wenn das ergebnis nicht befriedigt und man doch forceinline will, ist so ein makro bei weitem die einfachste möglichkeit, das zu tun, ohne unnötig editieren zu müssen, insbesondere wenn man es dann doch nicht will. dass man derartige makros, die schlüsselwörter verstecken, i. allg. nicht global verwenden sollte, betrachte ich als selbstverständlich.