TIL that in C++, you can declare variable in if statement
-
Which in large part is why some of us still prefer using C
Yes, but then you can just use C, and not try to compile your C with a C++ compiler.
-
But having two compilers is hard.
-
-
a new ... way in which Discourse sucks donkey balls.
I really don't want to think about how many ways donkey balls can be sucked, but I'm pretty sure Discourse does so metaphorically in many more ways than are possible literally.
-
discourse..... you notify me, but break the mention text and reveal the supposed to be hidden text?
why?
-
2 girls 1 compiler?
-
-
2 girls 1 compiler?
[spoiler]I'm probably asking for trouble by mentioning this here but[/spoiler]
You know, I've never actually seen the original video.
-
I read a synopsis. That was sufficient.
-
I read a synopsis. That was sufficient.
[spoiler]I'm probably still asking for trouble here but[/spoiler]
I've never even done that, come to think of it. I suspect that has something to do with people being unwilling to devote the mental effort to the task of describing it in text form.
-
I can promise you that someone out there would relish doing so. I wouldn't, but my tastes are rather more vanilla.
pun intended
-
Does it not bother you that a statement with no parentheses can execute arbitrary user code?
-
Oh, I'm sure there are cough @Lorne_Kates cough
But I have never encountered the writings of such a person about that particular video. I have encountered a wide variety of horrible things on the internet, though, so I'm sure I'm not missing out on anything, really.
-
-
I had generally assumed the content of the video based on the "2 girls 1 cup reaction" videos I'd seen and the general contexts in which it tends to come up, but thank you for confirming my suspicion anyway.
-
-
-
discourse..... you notify me, but break the mention text and reveal the supposed to be hidden text?
why?
Oh Discourse. I didn't even notice that, but it's gotta be because the @-mention formatting has a span or whatever around it.
-
-
For someone who takes so much obvious delight in exposing others for making mistakes, you sure are pretty touchy when you're on the receiving end of being proven wrong.
Not that I am in any way surprised, mind you.
-
-
Two sex slaves consume some sort of bodily outflow, put in a cup. Christ, nobody got killed and people are all like "OMG"...
-
Come to think of it, being grossed out by 2 girls 1 cup is no more justified than being grossed out by unknowingly having sex with transperson.
-
And even better, it's just one or two minutes long.
-
You need to step a bit back from the hardware to grasp language level concepts. How the hardware models the language is not the language.
Like all this gobble about stacks... An IBM zSystem (aka the spiritual inheritors of the System/360) doesn't have a machine stack like you'd recognise in x86. The best you have is a linked list manipulated in LIFO fashion of activation records, which might in some cases (e.g. Pascal on the Michigan Terminal System) be allocated on the heap.(1)Or you are compiling FORTRAN in its normal no-recursion mode, and you can stash the return value in a hidden local variable, and never actually use the machine stack for anything at all, because you're still on that 360, and you don't even have one.
(1) I saw the consequences of this once, on the 3081D machine at RPI. This was 1984 or 1985, and Pascal was still king for beginning Computer Science. I wound up with an excessive (maybe even infinite, I don't remember) recursion, and my program crashed, saying it could not allocate memory for an activation record. It was a little surreal.
-
I did C++ for years and never knew that this existed, let alone its scoping rules.
Its scoping rules were in flux while VC++6 was being developed, which resulted in one of the many ways in which VC++6 was buggy. (The optimiser was less buggy than the one in VC++5, in which you never, never, never, I mean really never, not ever activated "Optimise for speed" if you wanted to be able to ship working code. "Optimise for size" was OK, but "Optimise for speed" was guaranteed to produce gibberish.)
-
You don't need stack memory built into your CPU to have a stack memory. All you need is a calling convention where one of general purpose registers your architecture offers is named "stack pointer". I'm sure this zSystem has at least three general purpose registers, amirite?
-
But having two compilers is hard.
I'll tell you a secret. If you make all your source code files start with a header including the language version, something like
//language: C++03then you could have a program read this and automatically use the right compiler for you! You can even use that to make your language backward compatibile forever and at the same time allow breaking changes to be introduced in the future! WOW!
-
-
You don't need stack memory built into your CPU to have a stack memory. All you need is a calling convention where one of general purpose registers your architecture offers is named "stack pointer". I'm sure this zSystem has at least three general purpose registers, amirite?
16, actually. GEEEEEEEEEEEZUS, learn some fucking history, man.And yes, that's what they did. A "linked list manipulated in LIFO fashion of activation records" or did you deliberately not read that part of my post? And the register in question was usually named R14 if memory serves, but anyway. The problem with many people nowadays is that they don't know doodly squat about how computers work, how they might work, and so on, and so they think that everything works the way they think their computer works.
And they are wrong. But yes, there are architectures out there (IBM is still selling zSystems, you know (1)) that don't have a dedicated hardware stack manipulated with instructions like PUSH and POP. So the activation records for a recursable language like C, C++, or Pascal have to be allocated somewhere other than the hardware stack, and on that particular day, I exhausted that "somewhere" and got a bizarre and not very helpful error message.
(1) It occurs to me to ask if you even know what a System/360(2) is.
(2) In keeping with the general theme of "there is nothing new under the sun" that is our modern computing experience, how many people in the audience know that the first example of what we now call a hypervisor ran customer software in 1967?
-
You don't need stack memory built into your CPU to have a stack memory. All you need is a calling convention where one of general purpose registers your architecture offers is named "stack pointer". I'm sure this zSystem has at least three general purpose registers, amirite?
Oh, yes, and taking the highlighted part literally as written, you are drooling on the keyboard again. The stack memory is not built into the CPU in the general case (like most things in computing, there are counterexamples), but the stack pointer is. Well, unless the registers are stored in main memory as well, which has happened.
-
But I have never encountered the writings of such a person about that particular video. I have encountered a wide variety of horrible things on the internet, though, so I'm sure I'm not missing out on anything, really.
Think you need to mention @algorythmics instead...
-
16, actually. GEEEEEEEEEEEZUS, learn some fucking history, man.
16 is still at least 3, so I was 100% correct.And yes, that's what they did. A "linked list manipulated in LIFO fashion of activation records" or did you deliberately not read that part of my post?
Linked list manipulated in LIFO fashion is nothing like x86 stack. A random pointer in memory would be more accurate description.But yes, there are architectures out there (IBM is still selling zSystems, you know (1)) that don't have a dedicated hardware stack manipulated with instructions like PUSH and POP. So the activation records for a recursable language like C, C++, or Pascal have to be allocated somewhere other than the hardware stack
Wouldn't that mean that you lose the main benefit of having a stack - namely, constant memory offsets to variables?(1) It occurs to me to ask if you even know what a System/360(2) is.
I don't know and I don't care.Oh, yes, and taking the highlighted part literally as written, you are drooling on the keyboard again.
Hardcodingadd sp, 4andsub sp, 4as single-byte opcodes directly in the CPU's circuitry is what I call built-in.The stack memory is not built into the CPU in the general case (like most things in computing, there are counterexamples), but the stack pointer is.
Stack pointer is a general purpose register that has no special meaning to the CPU. Stack pointer is no more built into CPU than "this" pointer is (which by MSVC __thiscall calling convention on IA-32, always goes in ecx).
-
Oh god where the fuck do I begin?
I think you belong next to Grub in Umoira (zone in Allods Online). Grub stands under a bridge, see, because Grub is a troll.
@Steve_The_Cynic said:
16, actually. GEEEEEEEEEEEZUS, learn some fucking history, man.
16 is still at least 3, so I was 100% correct.
True, but hardly useful.
@Gaska said:@Steve_The_Cynic said:
And yes, that's what they did. A "linked list manipulated in LIFO fashion of activation records" or did you deliberately not read that part of my post?
Linked list manipulated in LIFO fashion is nothing like x86 stack. A random pointer in memory would be more accurate description.
Of course it's nothing like the x86 stack. Didn't I say it wasn't like the x86 stack?
@Gaska said:@Steve_The_Cynic said:
But yes, there are architectures out there (IBM is still selling zSystems, you know (1)) that don't have a dedicated hardware stack manipulated with instructions like PUSH and POP. So the activation records for a recursable language like C, C++, or Pascal have to be allocated somewhere other than the hardware stack
Wouldn't that mean that you lose the main benefit of having a stack - namely, constant memory offsets to variables?
No. The offset is just from the pointer to the base of the current activation record, whose address is stored in one of the registers. (Just like offsets from EBP on x86/32.)
@Gaska said:@Steve_The_Cynic said:
(1) It occurs to me to ask if you even know what a System/360(2) is.
I don't know and I don't care.
That much is obvious. A small clue lies in the words "IBM mainframe".
@Gaska said:@Steve_The_Cynic said:
Oh, yes, and taking the highlighted part literally as written, you are drooling on the keyboard again.
Hardcodingadd sp, 4andsub sp, 4as single-byte opcodes directly in the CPU's circuitry is what I call built-in.
Well you won't find that on modern x86 either. You really suck at reading comprehension, don't you?
@Gaska said:@Steve_The_Cynic said:
The stack memory is not built into the CPU in the general case (like most things in computing, there are counterexamples), but the stack pointer is.
Stack pointer is a general purpose register that has no special meaning to the CPU. Stack pointer is no more built into CPU than "this" pointer is (which by MSVC __thiscall calling convention on IA-32, always goes in ecx).
Highlighted text: not usually.On x86, there are instructions that put stuff on the stack and take it off the stack, and guess what? They use one specific register (SP, ESP, or RSP depending on whether you are in 16-bit, 32-bit or 64-bit mode) to specify where this happens. And function calls use the CALL instruction which includes an implicit "PUSH IP/EIP/RIP" to make the call and RET to return.
Exception handling uses the same SP/ESP/RSP register to save the current machine state.
But of course none of that can be true because it has no special meaning to the CPU.
As I said at the beginning, I really think you need to get back next to Grub.
EDIT: fixed RIP that should have been RSP. Thanks @aliceif.
-
Stack pointer is a general purpose register that has no special meaning to the CPU.
:cough:int/iret
:cough: task gates
:cough:#SSfaultSorry, I think I'm coming down with something.
-
-
@Steve_The_Cynic said:
SP/ESP/RIP register
I think you typo'd ...
I think you're right. Oops.
-
True, but hardly useful.
Both 16 and at least 3 are as useful to say they could have spared one register for stack pointer.Of course it's nothing like the x86 stack. Didn't I say it wasn't like the x86 stack?
You said "that's what they did" and "the register in question was usually named R14 if memory serves" - both of which suggest that you're trying to same that LIFO something and x86's sp serve more or less the same purpose.No. The offset is just from the pointer to the base of the current activation record, whose address is stored in one of the registers.
I see. Kinda cool, actually.That much is obvious. A small clue lies in the words "IBM mainframe".
I still don't care.Well you won't find that on modern x86 either.
Are you speaking of i7's VLIW code that actually gets executed, or the abstract x86 machine that's used as an interface to CPU? Because the latter still has single-byte push/pop opcodes, and the former has nothing to do with x86 anyway.Highlighted text: not usually.
I specifically ignored branch predictions, precaching, and other optimizations the compiler performs based on the value of sp. Including those would be like including out-of-order-execution in discussion about order of expression evaluation in Java.On x86, there are instructions that put stuff on the stack and take it off the stack, and guess what? They use one specific register (SP, ESP, or RSP depending on whether you are in 16-bit, 32-bit or 64-bit mode) to specify where this happens. And function calls use the CALL instruction which includes an implicit "PUSH IP/EIP/RIP" to make the call and RET to return.
And this is why I said stack is hardcoded in x86. Doesn't change the fact you can bitshift stack pointer by value in al, just like with any other register.Exception handling uses the same SP/ESP/RSP register to save the current machine state.
Aren't exceptions something that CPU doesn't care about (aside interrupts)?As I said at the beginning, I really think you need to get back next to Grub.
You mention Grub for the first time in topic. Unless it's some hacker slang term that died along with the hackers of those times.
-
You mention Grub for the first time in topic. Unless it's some hacker slang term that died along with the hackers of those times.
I think you belong next to Grub in Umoira (zone in Allods Online). Grub stands under a bridge, see, because Grub is a troll.
<post can't be empty>
-
I see. I admit, I tend to ignore the beginnings of posts if they have shitload of quotes in them, but don't start with one.
-
@Steve_The_Cynic said:
True, but hardly useful.
Both 16 and at least 3 are as useful to say they could have spared one register for stack pointer.
Sure, but it's fifty years too late for that to change.
@Gaska said:@Steve_The_Cynic said:
Of course it's nothing like the x86 stack. Didn't I say it wasn't like the x86 stack?
You said "that's what they did" and "the register in question was usually named R14 if memory serves" - both of which suggest that you're trying to same that LIFO something and x86's sp serve more or less the same purpose.
OK, what I meant there was that they had a register that was used by convention as a stack pointer, that is, the head pointer of the LIFO-order linked list of activation records, because it wasn't a stack pointer like x86 has.
@Gaska said:@Steve_The_Cynic said:
No. The offset is just from the pointer to the base of the current activation record, whose address is stored in one of the registers.
I see. Kinda cool, actually.That much is obvious. A small clue lies in the words "IBM mainframe".
I still don't care.
That's your right, but knowing at least what it is would give you a clue what people were talking about.
@Gaska said:@Steve_The_Cynic said:
Well you won't find that on modern x86 either.
Are you speaking of i7's VLIW code that actually gets executed, or the abstract x86 machine that's used as an interface to CPU? Because the latter still has single-byte push/pop opcodes, and the former has nothing to do with x86 anyway.
I see that you don't bother reading what you wrote either. In a way, that's reassuring. You said that those opcodes (and no, there isn't a single-byte opcode for adding or subtracting four from (E|R)SP, but then again, that's not (just) what POP and PUSH do, either) are hard coded into the circuitry, which isn't true, and hasn't been in x86 since the technology in the NexGen Nx586 first saw the light of day in 1994. (In fact, it wasn't true even before then, because way back at the beginning x86 was a microcoded architecture. Like so many things in computing, "there's nothing new under the sun".)
@Gaska said:@Steve_The_Cynic said:
Highlighted text: not usually.
I specifically ignored branch predictions, precaching, and other optimizations the compiler performs based on the value of sp. Including those would be like including out-of-order-execution in discussion about order of expression evaluation in Java.
None of those things has the slightest bearing on whether the stack pointer register does or does not have special significance to the CPU. You said that on x86 it doesn't, and I reasonably enough said that for ... those ... reasons, it does. Sigh.@Steve_The_Cynic said:
On x86, there are instructions that put stuff on the stack and take it off the stack, and guess what? They use one specific register (SP, ESP, or RSP depending on whether you are in 16-bit, 32-bit or 64-bit mode) to specify where this happens. And function calls use the CALL instruction which includes an implicit "PUSH IP/EIP/RIP" to make the call and RET to return.
And this is why I said stack is hardcoded in x86. Doesn't change the fact you can bitshift stack pointer by value in al, just like with any other register.
Actually, you can't. the shift distance in a shift-by-distance-found-in-register is in DX. And doing anything to (E|R)SP other than push, pop, and subtract is a really bad idea, so the fact that you can do it is not significant.
@Gaska said:@Steve_The_Cynic said:
Exception handling uses the same SP/ESP/RSP register to save the current machine state.
Aren't exceptions something that CPU doesn't care about (aside interrupts)?
Of course not. They are only the mechanism by which GP faults / segfaults, bus errors, divide by zero errors, stack faults, and so on are delivered to the operating system, so why would the CPU care about them?(I'm not talking about exceptions as found in Java, C++, C#, and all the rest. I'm talking about CPU-level exceptions, like the aforementioned things, but also all kinds of page fault, hardware interrupts, and software trap instructions like x86's
int.)
@Gaska said:@Steve_The_Cynic said:
As I said at the beginning, I really think you need to get back next to Grub.
You mention Grub for the first time in topic. Unless it's some hacker slang term that died along with the hackers of those times.
Read my previous post. Grub is explained right at the very, very top. To recap: in the MMORPG Allods Online, Grub is an NPC found in the zone called Umoira. He lives under a bridge, and he is a troll.
-
You mention Grub for the first time in topic. Unless it's some hacker slang term that died along with the hackers of those times.
It occurs to me that I should perhaps take it as a compliment that you rather indirectly lump me in with them, but I'm not that old, not yet, anyway.
-
$Class's default ctor twiddles the bits in the hole set aside by the variable's declaration (and maybe in heap holes, depending on how it was written) until the default ctor's code is done executing. Better?
No, because you didn't account for trivial construction
-
Whatever. You're right on all those tiny pedantries, but still wrong about SP not being general purpose register. I don't feel like arguing this anymore, though.
-
We have examples of it everywhere: obj->property = 1; might do all sorts of stuff.
-
Read my previous post. Grub is explained right at the very, very top. To recap: in the MMORPG Allods Online, Grub is an NPC found in the zone called Umoira. He lives under a bridge, and he is a troll.
Read my addendum. You know, that post directly above yours.It occurs to me that I should perhaps take it as a compliment that you rather indirectly lump me in with them
I have great respect to old geeks. They made all the awesome stuff we use today. Even if they're wrong sometimes.but I'm not that old, not yet, anyway.
No respect for you, then.
-
No, because you didn't account for trivial construction
Technically, he didn't have to - he said that bit twiddling within constructor happens for as long as the constructor executes, and trivial constructor executes in no time.
-
Read my addendum. You know, that post directly above yours.
Ah, yes, the one that appeared while I was writing. I must remember that despite all its numerous faults, Discourse does have one useful feature, that I can read updates to a thread while I am writing a post for it.
@Gaska said:No respect for you, then.
I hadn't noticed any, no. And if you respect those old geeks, you should show a bit more respect for the stuff they created, like trying to find out a bit on what a System/360 is.
-
Ah, yes, the one that appeared while I was writing.
Yes, the one I posted half an hour before you.I hadn't noticed any, no. And if you respect those old geeks, you should show a bit more respect for the stuff they created, like trying to find out a bit on what a System/360 is.
The fact I have respect for them doesn't mean I can't find flaws in their products. Though when I think about it, this LIFO thingy is quite neat. But I guess passing parameters larger than a register must have been tricky.
-
@Fox said:
But having two compilers is hard.
I'll tell you a secret. If you make all your source code files start with a header including the language version, something like
//language: C++03then you could have a program read this and automatically use the right compiler for you! You can even use that to make your language backward compatibile forever and at the same time allow breaking changes to be introduced in the future! WOW!
