Thread: C++ Standard and one question

I don't think the C++0x standard will be "revolutionary" in any way. It adds things to the language, and standardizes a few things that various compilers already do as a non-standard extension.

As to inlining: The standard says nothing about what the compiler does with inlining. The compiler (gcc at the very least) will certainly inline functions from the same compilation unit without requiring an inline keyword, being defined in the class declaration, or other "hints" - it just does it because the compiler believes the result is better code. Particularly static functions that are only called once can be inlined even when they are pretty huge. [I actually struggled to understand my code because of this when I was working on the Xen-code, because my nice little function with a switch and a bunch of cases that each called one small function was all being inlined to one function - only the functions outside of this particular source file was not being inlined. So my 50-line function became some 2000 lines of disassembly - which made it pretty hard to understand.

The only way to completely guarantee that the compiler doesn't inline a function would be to call it through a function pointer [or as a virtual method from a class] and do so in such a way that the compiler can't determine which function is being used.

There are non-standard extensions to some compilers to say "inline this even if you think it's wrong", but I doubt the standard will introduce such a thing as standard.

Generally, it's not a great idea anyways, as the compiler usually knows better because it can determine from the number of instructions, types of instructions and usage whether it makes more sense to inline or not - whilst most of us can't actually determine from just looking at a function how many instructions it becomes, which precise instructions and what difference it makes to inline the code or not. So it uses rules based on respective processor manufacturers Optimization Guide to determine whether it's worth it to inline or not. It's not a tirival decision.

--
Mats

And you are walking on very thin ice, master5001. The OP asked a polite and complete question, and you were rude.

Don't think you know the moderators too well, either.

Dang, it is very hard to say what will be the most revolutionary feature of C++0x, but my guess would be initializer lists, variadic templates and explicit conversion operators.
I think all 3 of those features will be great.

My guess is rvalue refs, and the combination of concepts, variadic templates and auto+decltype. Together, they will bring template metaprogramming to a new level. Rvalue refs are a subtle but incredibly pervasive change - I believe it makes C++ the first mainstream language with support for move semantics. Also, together with variadic templates, they allow perfect forwarding - the old dream of a shared_new<Type>(arg1, arg2, arg3) that directly returns a shared_ptr has finally come true.

Code:

template <typename T, typename Args...>
std::shared_ptr<T> shared_new(Args... args)
{
  return std::shared_ptr<T>( new T(std::forward<Args>(args)...) );
}

My syntax may be a little off.

The rvalues sound great, but I am still uncertain of how they work or where to apply them... But in theory, they sound really useful and might even give C++ another advantage. Properly applied, it should decrease performance hits in programs and move speed closer to C.
The "auto" keyword is a dream come true, as well, when you talk about complex types and the amount of typing it may save on long types.

Originally Posted by Elysia

The "auto" keyword is a dream come true, as well, when you talk about complex types and the amount of typing it may save on long types.

auto keyword?
Haven't C/C++ always had an auto keyword?

Originally Posted by cpjust

auto keyword?
Haven't C/C++ always had an auto keyword?

Its meaning was simply redefined, seeing as how it is completely superfluous as it is now. This is, as far as I know, the only breaking change in the new standard that isn't caused by a new keyword. (There might be something about the parsing of >> in templates that breaks obscure code.)

auto is now equivalent to var in C#, in that it means, "deduce the type of this variable from the initializer".