DoG Wrote:That is nonsense. RTM.

Usually, it is not allowed.

C++ FAQ page Wrote:10. Which are the situations where inline function is not working?

Some situations where inline function may not work -

For function returning values, if a loop, a switch or goto exists.
for function not returning values, if a return statement exists.
if functions contains static variables.
if inline functions are recursive.
if function contains large code.
if function is virtual as binding takes place at compile time.

(source)

akb825 Wrote:(source)

Quote:ASP Engine error

The ASP engine on this server (IIS 5) is prone to crashing under high load. No specific error has occurred - it's simply that the server has collapsed and will be restarted within the minute by our health monitoring systems.

Good old IIS!

Anyway, if loops, switch and gotos aren't allowed, then if's wouldn't be either, would they? Doesn't make a lot of sense to me.

Switches are basically gotos, and I think loops essentially do their thing through a goto. If statements I believe actually call another block of code for the if and the else. From what I can gather, you can't use switches, gotos, or loops since they all sprout from the same block of code, while if statements have another section of code. I'm not 100% sure of this, so if I'm wrong feel free to correct me.

akb825 Wrote:Some situations where inline function may not work -

For function returning values, if a loop, a switch or goto exists.
for function not returning values, if a return statement exists.
if functions contains static variables.
if inline functions are recursive.
if function contains large code.
if function is virtual as binding takes place at compile time.

First of all, it says it may not work, depending on your compiler, and second, if you read closely, it says if a loop exits, not that functions with loops don't get inlined at all.

Also, the above if severely flawed, the last "if function is virtual …" is completely wrong, it should be saying "… as binding takes place at run time", not compile time. The other points are mostly valid, and can really prevent inlining in some, not all, cases.

Also, loops and switches are NOT NOT NOT essentially gotos. Goto creates some pretty serious issues w.r.t. variables on the stack and program flow. No offense, but RTFM.

Also, conditional branch instructions, such as if, case, or loops, don't prevent inlining, only possibly in the above mentioned conditions. If an inlined function couldn't branch, it would be pretty damn useless.

DoG Wrote:First of all, it says it may not work, depending on your compiler, and second, if you read closely, it says if a loop exits, not that functions with loops don't get inlined at all.

Well, it's also what my CSE 12 professor said last year. I just wanted to find an actual source that confirms it. After looking online, there isn't much that confirms it. Whether or not it's right, it's what I've been told. If it isn't right, I'll be very peeved indeed. (at my professor for telling us wrong information)

DoG Wrote:Also, loops and switches are NOT NOT NOT essentially gotos. Goto creates some pretty serious issues w.r.t. variables on the stack and program flow. No offense, but RTFM.

I just double checked with my roommate who took the assembly class last quarter (I'm enrolled in this quarter, so I'll confirm it for myself within a few weeks ): switches and loops are essentially gotos at the assembly level, at least in SPARC. Also, there is further evidence that at least switches are generally gotos. During a programming contest practice, one of the contest administrators pointed out a piece of code in my C++ book that essentially had a loop and a switch statement, called Duff's device, and explained how it shows that switch statements are basically gotos. Here's an example using Duff's devise:
As for loops, it could be that other architectures handle loops differently, or that all of them use the same method as a goto.

OK, lets make this easy:
In assembler, a goto is a jmp (jump). An if is a jmpz or something like that, meaning "jump if zero". That is, if certain register is zero, jmp to some instruction. If that instruction is forward, you have a regular "if" implemented(*), if backward, you have a "while", a "for", etc.

For instance, "if (a != b) {this} else {that}; other stuff;" can be represented as:
1. Store a-b in register FOO
2. jmpz FOO,5
3. "that"
4. jmp 6
5. "this"
6. other stuff

This is a made-up assembly, of course, but that's the general idea.

DoG Wrote:if you read closely, it says if a loop exits, not that functions with loops don't get inlined at all.

And if you look even closer, it says "exists" Anyway, it should have said "has a return", that is if it actually does make a difference.

PowerMacX Wrote:...And if you look even closer, it says "exists" Anyway, it should have said "has a return", that is if it actually does make a difference.

Ok, I read what made sense there. I assume that is just an error like with the last statement.

The main difference between goto and the if and loop statements is that goto doesn't modify the stack, while the others do. It is true that switch statements are more hideous in this regard, and indeed have much more in common with goto, but the switch itself sets up a new stack frame (as indicated by { } ).

Goto is an unconditional branch, though, while the others are conditional. All of them are branches, that's what they have common at the assembly level.

The implications of using goto (and duff's device) are especially bad under C++, where constructor and destructor calls are vital.

I've never seen just the existance of a block (i.e. { } ) cause the compiler to do anything with the stack. If a local variable is introduced, then it will allocate space on the stack and deallocate it as appropriate, but there is pretty much zero difference between:

if(z == 0)
{
DoMyThing();
}

and

if(z != 0) goto tag;
DoMyThing();
tag:

There are no "stack frames" created with if/switch/while/etc...

In addition, in ANSI C++ I'm pretty darn sure that goto is restricted to the current function, and it properly handles destructors when leaving block scopes and will not allow entry into blocks with constructors. i.e. its not _that_ dangerous.

"goto" is a dangerous thing that should be mostly avoided, but let's make sure we are convicting it of the proper crimes.

Goto skips variable initialisations, that much is sure. That's why it is dangerous. How restricted it is with C++, I don't know, I have never used goto except in Basic.

At least in C++ (maybe in C as well), it gives you a warning or error (I don't remember what) if it skips an initialization. I use gotos sometimes since it's convenient for skipping large sections of code for things such as error handling.

akb825 Wrote:At least in C++ (maybe in C as well), it gives you a warning or error (I don't remember what) if it skips an initialization. I use gotos sometimes since it's convenient for skipping large sections of code for things such as error handling.

Err, that's what exceptions are for. Using goto in a high level language is bad style. Especially when there are better ways to do the same thing.

The only times that I've used a goto to skip blocks of code were when doing basically low-level style parsing. I haven't used a goto for a while, though, and I'm not sure if I ever kept a goto in use when writing a program in C++. I personally think that exceptions are often overused, since that seems to be some people's answer for every problem. I would agree that it would be better to use an exception, though, style-wise, than a goto in that instance if it's in C++.