Break/Continue in switch nested in while

[MyndFyre]

I'm working on converting LibMPQ to C# at the moment, and I'm running into a problem.  There's a situation like this:

Code Select Expand


while (condition) {
  switch (value) {
     case a:
        if (condition2) {
          break;
        }
        continue;
  }
}

That's greatly simplified of course.  I want to know if the break breaks the switch or the while.  That's it!  Thanks!

[edit] The reason I ask is because the guy makes liberal use of continue in the code -- that's the only time break is used, though.  If break breaks the switch, then it is effectively identical to the use of continue in this case; if it breaks the loop, that's a BIG difference.

[Eric]

break ends the most current loop or conditional statement, which in your case would be the switch statement.

[OnlyMeat]

I know both C/++ AND Java, as well as Assembly.  I also know old-school BASIC.  I don't know what to pick!

LMAO.

[Kp]

break ends the most current loop or conditional statement, which in your case would be the switch statement.

Minor point, but the wording of this seems to imply that break can get you out of an if.  It can't.  break ends switch, for, while, do {} while, but not if.

[dxoigmn]

I know both C/++ AND Java, as well as Assembly.  I also know old-school BASIC.  I don't know what to pick!

LMAO.

Same thread a little further down:

I know (in order of comfort levels):
C#/VB.NET/J#
Java
JavaScript (again, scripting) in browsers, WSH, and IIS
C/++, in a pinch.
BASIC
Assembly, if I really have to

You're an annoying troll.

[MyndFyre]

break ends the most current loop or conditional statement, which in your case would be the switch statement.

Minor point, but the wording of this seems to imply that break can get you out of an if.  It can't.  break ends switch, for, while, do {} while, but not if.

Yeah, I knew that much.  I was pretty sure that break ended the switch, and that's what I was betting on (I finished the conversion shorly after the post), but I wanted to confirm.  Like I said, there wasn't any difference in using break or continue if it broke the switch, but it's just unusual to see continue in any context.

Thanks to those of you who are intelligent.  OnlyMeat -- you may wish to consult my signature for the cure for your condition (to clarify, it's the latter).

[Kp]

Yeah, I knew that much.  I was pretty sure that break ended the switch, and that's what I was betting on (I finished the conversion shorly after the post), but I wanted to confirm.  Like I said, there wasn't any difference in using break or continue if it broke the switch, but it's just unusual to see continue in any context.

I expected you knew that break had no effect on an if, but I wanted to correct the mis-implication in case a newbie stumbled into the thread later.  I disagree about continue being unusual; a quick search reveals it occurs over 200 times just in some of my Linux code.

[Banana fanna fo fanna]

I know both C/++ AND Java, as well as Assembly.  I also know old-school BASIC.  I don't know what to pick!

LMAO.

Same thread a little further down:

I know (in order of comfort levels):
C#/VB.NET/J#
Java
JavaScript (again, scripting) in browsers, WSH, and IIS
C/++, in a pinch.
BASIC
Assembly, if I really have to

You're an annoying troll.

Actually, it appears that you and OnlyMeat are the annoying trolls here.

Edit: Throwing in more examples of how virtually every post by OnlyMeat is incorrect...

Seems clear to me you are saying the code snippet above doesn't allocate any memory. This is incorrect, if you don't believe me run the code in my reply, you will find the size of the variable buf == 1 (the null terminator). This is clearly allocating 1 byte on the stack giving you a valid zero length string:-

Code Select Expand


char* buf = "";
char* buf2="hello";
cout << sizeof(*buf) << buf2 << endl;


#1: It's not allocating a byte on the stack
#2: It may not be allocating anything at all
#3: You're not testing for anything being allocated; example:

Code Select Expand


char* buf = 0;
char* buf2="hello";
cout << sizeof(*buf) << buf2 << endl;


Tell me how assigning null to a pointer would be allocating a byte for it? Yet according to you, sizeof says it does?

Say what you like but the point is buf points to 1 byte of memory. You just agreed with that thanks .

Memory is committed (in win32) in 4096 byte blocks, also known as pages. Your pointer will point to somewhere in your address space. There most likely won't be just 1 byte available at the location buf points to, much like when you allocate 5 bytes there won't most likely be just 5 bytes where your pointer points to. Maybe what you wanted to say was "buf points to 1 byte of memory allocated for you to use as you like"? Unfortunately that'd be incorrect as well...

It has a static lifetime, however it must still be allocated and loaded into memory at runtime. Which proves the point that the variable buf will point to 1 byte of data. It doesn't matter if it's on the stack or allocated when the program starts statically it will be allocated in memory.

There will be memory for the '\0', that's all you can say. That memory may have been allocated for the byte, or it may have been allocated for something else and reused for the '\0'. The memory may be allocated a load-time, or it may have been allocated much earlier. An example would be writing code for a BIOS chip, in which case you might say the memory was allocated when the EEPROM was written. The point is that the declaration char *buf = ""; not necessarily causes an allocation, and particularly doesn't give you  memory that you can do anything other than read a '\0' from.