C++ Standard and one question

Hya all.

Recently there has been a lot of fuzz because of C++0x and such. I've been reading allot and I'm already working with GCC's attempt at implementing what is 'supposed' to be in the Standard.

But I'd like to ask you what you think will be the 'greatest revolution' (if any).

Secondly, I'd like to ask you if something liek waht I'll describe exists (I've googled it around and I can't seem to find it). So here goes:

When you have an inline function it is considered to always be inlined, even if the compiler decides not to do it, there is no way of stopping it getting inlined, or am I wrong? Well, if I am right and it is not possible to do this, will the Standard implement such a way? Or a similar (opposite) path that would allow a 'regular' function to be inlined automatically?

Thanks in advance

Jorl

I fell asleep during the asking of your question, but if I can piece together the blurry bits of convoluted rhetoric that I catnapped between I can only ask you why are you second guessing what your compiler decides is the best course of action for inlining? Most compilers do come with compiler specific commands, or even declarations that force inlining. However, I still wonder what makes you wish to take away your optimizer's ability to do whatever it deams optimal? One way I know of to guarantee that something is NOT inlined is to compile it into a linked library. And to answer your initial question about C++0x, my simple answer will be a construct that completely removes the need for va_args.

Thanks for your answer.

Well, what I meant was simply to know if there was such a mechanism of 'asking' for an inline in a specific point, nothing else. I surely was not doubting my compiler's ability to do anything sa that I DO know happens. It was simply a question, you could at least have been less rude, but I think I get you...as I tend to be even worse when I get upset with some silly question.

That said, thank you very much...

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

Thanks that answered me and also gave me a brighter insight on other subjects which may be useful in the future. Now I get why when i disassembled one of my applications it didn't even look like it, I guess you just explained it all.

So I guess this topic can be marked as closed.

It could, but you clearly do not know out moderators very well ;)

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.

Quote:

---

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?

Quote:

---

Originally Posted by CornedBee

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.

---

My apologies to both you and the original poster. I have been a little extra sleep deprived lately and also not feeling great. I shouldn't take that out on others.

I have said it many times before, and I will say it again. I will allow time to show which compilers fully implement C++0x and when every facet of the design is finalized. Until then I will just keep using what we have now.

Quote:

---

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".