What will this output?

What will this program output?
Good luck, you'll need it!

#include <iostream>
using namespace std;

int main() {
class c {
public:
c() {
void f();
f();
}
};

c my_c();
}

void f() {
cout << "VALID C++" << endl;
}

The answer is absolutely nothing because c my_c(); is a fucking function declaration.

>>80

The standard allows it to be.

It doesn't require it to be. So any code which depends on GC cannot be said to be standard-conforming.

You assume many things.

It's a valid assumption because we're talking about algorithms, not implementations. So it's assumed the compiler generates the "most literal interpretation" of the source code.

Its UB

Again, according to "most literal interpretation", a null pointer would be interpreted as pointing to a non-valid memory address. Meaning that assignment would cause a segfault on a system with memory protection. Not all implementations may exhibit this behavior, but again we are talking about algorithms, not implementations. In any case, we could eliminate this issue by revising the program to

int main(void) {
unsigned char *ptr;
while(1) {
ptr = malloc(sizeof(char));
if(ptr) {
*ptr = 255;
} else return 1;
}
return 0;
}

Which means, assuming no optimization, and no GC, this program will exit with an exit code of 1 on any real computer, while on a Turing machine it should keep looping forever (since having unbounded memory means there is really no logical reason for a call to malloc() to fail).

Checking dubs

>>81

So any code which depends on GC cannot be said to be standard-conforming.

Programs don't need to depend on GC for an implementation to use GC.

It's a valid assumption because we're talking about algorithms, not implementations

We are not however.

Meaning that assignment would cause a segfault on a system with memory protection

The standard does not contain the world ``segfault''.

but again we are talking about algorithms, not implementations

And again, we are not. We are talking about the standard and what implementations are allowed to do.

} else return 1;

Are you aware that 1 might not stand for EXIT_FAILURE on some implementations?

Which means, assuming no optimization, and no GC

Again, many assumptions.

>>84

We are not however.

[citation needed]

The standard does not contain the world ``segfault''.

It doesn't have to. This is an OS issue, not a C Standard issue. Regardless of what language your program is written in, accessing illegal memory is a segmentation fault.

Are you aware that 1 might not stand for EXIT_FAILURE on some implementations?

And I'm not assuming that it is. Neither EXIT_SUCCESS == 0 nor EXIT_FAILURE == 1 is guaranteed by the standard; however anything that isn't either EXIT_SUCCESS or 0 should be interpreted as indicating failure.

Again, many assumptions.

Those assumptions were chosen to simplify the discussion of the algorithm.

>>84

Regardless of what language your program is written in, accessing illegal memory is a segmentation fault.

You're assuming the computer has memory protection.

Sometimes the computer will give you whatever is at that address. It might not even be attached to hardware at all. It could be random bits or whatever was on the bus last.

Also, it's not always a ``segmentation fault''. Good hardware would give you a more specific error.

>>82
What dubs?

these dubs

You're assuming the computer has memory protection.

I previously specified that that was one of the assumptions being made to demonstrate my point. But here's a program that does the same thing without depending on the assumption of memory protection:

#include <stdlib.h>
#include <stdint.h>

int main(void) {
uint8_t *ptr;
while(1) {
ptr = malloc(1);
if(ptr == NULL) {
puts("MEMORY ALLOCATION FAILURE");
return EXIT_FAILURE;
}
else *ptr = 111;
}
return EXIT_SUCCESS;
}

Now I'm sure someone will find some nitpick for why this wouldn't work, but this has the same expected behavior as the previous program: on a real computer, it would return with failure result, on a Turing machine it would never exit.

This version should work even without memory protection (as on a real machine, repeated calls to malloc() without calling free() should eventually use up all available memory and cause malloc() to return a null pointer). Again, we're to assume garbage collection (if available in the implementation) is disabled, and optimization is disabled, so the machine code generated is as close to possible to the source code.

>>84

[citation needed]

Check our discussion, there was no talk about algorithms.

This is an OS issue, not a C Standard issue

Actually it's an implementation issue.

Regardless of what language your program is written in, accessing illegal memory is a segmentation fault.

And this is wrong, the implementation is free to do whatever it wants as it is UB.

however anything that isn't either EXIT_SUCCESS or 0 should be interpreted as indicating failure.

I disagree, the standard disagrees as well.

Those assumptions were chosen to simplify the discussion of the algorithm.

We are not talking about any algorithm, in fact no algorithm was posted in this thread.

>>88

on a real computer, it would return with failure result

A real compiler on a real computer is free to optimise the loop by not including any of the code inside it or gc ptr.

on a Turing machine it would never exit

Except if the implementation of malloc for some reason returned NULL.

Why are you using uint8_t? Don't you know that it is considered optional and some implementations don't or can't include it? Your code doesn't even have a need for it, you could just use char instead.

as on a real machine, repeated calls to malloc() without calling free() should eventually use up all available memory and cause malloc() to return a null pointer

This is wrong, see above.

Again, we're to assume garbage collection (if available in the implementation) is disabled, and optimization is disabled, so the machine code generated is as close to possible to the source code.

Way too many assumptions. I thought that you wanted to talk about ``real machine''s.

>>88

Now I'm sure someone will find some nitpick for why this wouldn't work, but this has the same expected behavior as the previous program: on a real computer, it would return with failure result, on a Turing machine it would never exit.

Well, the OS might be retarded. Instead of printing MEMORY ALLOCATION FAILURE it might end up invoking an OOM killer.

>>90 Errors don't help anyone and require human intervention. OOM killer is the right design, since it allows to respond to memory hogging apps fast.

What does this output?

#include <stdio.h>

int main(void) {
int C;
if(C++ == C) puts("C++ is equal to C!");
else puts("C++ is not equal to C!");
return 0;
}

>>92
operations on declared but undefined variable are technically an undefined behavior so anything could happen but on real machines C will just be treated like a valid variable containing whatever was in that particular area of memory. for simplicity, let's assume that the memory was zeroed-out (although this doesn't change anything - only thing that matters is whether the implementation does anything retarded on undefined behavior) and write an equivalent:

int C = 0; //assume a normal implementation treats C like a valid variable
int x = C++; //we introduce an additional variable for clarity
if(x == C) puts("C++ is equal to C!"); // this won't happen: x was assigned 0 and C was incremented so it's 1 (post-incrementation)
else puts("C++ is not equal to C!"); // this will happen
return 0;

so basically, on actual hardware and with a non-meme compiler, you'll see C++ is not equal to C! on stdout and the program will exit. that's for STACKBOI RETOIDS though because it relies on undefined behavior, technically it could format your HDD, burn down your house and print HAX MY ANUS to stderr and go into an endless loop and it would still conform to the standard.