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.

Can we just consider all of C harmful already and call it a day?

>>2
Don't try to blame C for your shortcomings, Sepples.

Check em

If it can be parsed as a function declaration, it will be. You can't claim to know C++ if you don't know this.

The Perl AGI http://ai.neocities.org should output a thought stemming from only a limited set of sources: an idea stored in the knowledge base; a new idea generated by logical inference; or a sentence generated as the expression of information arriving from the senses, as for example when the AGI is describing what it sees in a visual scene. There should be no random and potentially erroneous associations from random subject to random verb and to random object.

As we start coding ghost163.pl and we simply press [Enter] with no input to see what output results, the EnNounPhrase() module defaults to 701=I as a subject. Immediately a t=753 $verblock is found which locks the AI into an output of "I HELP KIDS" from the innate knowledge base. Currently the SpreadAct() module is being called from EnNounPhrase() when the AI outputs the 528=KIDS direct object, but perhaps the call should wait until after ReEntry() inserts the idea into the moving front of the knowledge base.

The output of a thought, even from memory, is the result of spreading activation and should not lead to more spreading activation until the same thought becomes a form of input during ReEntry(). There must be some way to delay the calling of SpreadAct() until a new-line or [Enter] is registered. In OldConcept() we could set the $actpsi with the $oldpsi value, but not call SpreadAct() until the end of the input or re-entry.

We have created a new $quapsi variable "by which" the final noun ($psi) from InStantiate() can go into SpreadAct() from the ReEntry() module and possibly spread activation to pertinent knowledge in the knowledge base of the AI memory.

/cudder/

>>6

We have created

Shut the fuck up, you don't have any people who care about you or would even remotely want to work with you. Fuck off, Mentishit, you're a waste of oxygen.

Check em

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

You're declaring a function, my_c(), that returns a class of type c. What's the problem?

Furthermore, why would you use the class keyword at all? C++ is fine if you just use it like a better version of C and ignore the class-oriented programming paradigm.

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

int main(void) {
"VALID C";
}

The answer is absolutely nothing because >>1 is a baka

#include <stdio.h>
int foo() { return 0xe-2; }
int bar() { return 0xf-2; }
int main() {
printf("%u %u\n", foo(), bar());
return 0;
}

>>13
foo.c: In function ‘foo’:
foo.c:2:20: error: invalid suffix "-2" on integer constant
int foo() { return 0xe-2; }
^

>>12
>>13
>>14
What programming language is this?

>>15
One that can't even optimise!

>>14
12 13
This is where MSVC wins for not following the retardedness of the standards committee.

Everyone complaining about how C++ is so hard to parse is missing something so bloody simple it makes you feel stupid for not seeing it when you finally do.

The "if it can be parsed as a declaration, it is a declaration" rule is probably a direct consequence of the early C++ parsers simply trying to parse a declaration first, then an expression-statement if the declaration doesn't work.

Maybe years of academia has turned language researcher's brains into indoctrinated mush, as in fact C++ parsing is very straightforward with a variant of recursive-descent.

Here's a classic "C++ parsing is hard!" example:

int(x), y, *const z; // declaration
int(x), y, new int; // expression-statement

The academics claim you need "infinite" lookahead to parse those correctly, because there can be arbitrarily many tokens before it knows which path to take. Bullshit. All you need to do is "fork" the current thread whenever there are multiple matches and feed the incoming tokens to all the active "threads", and when one can't proceed any further, it terminates. If there are no more threads, that's an error. When you reach the ';', take the AST formed by the first (which if you arranged things correctly, will be the one that went down the declaration path) and/or only thread, and you're done. You don't even need to build the AST for both paths if you're really optimising for space - just record which path is the right one and go back to build the AST.

If you're somewhat knowledgeable of (but not indoctrinated by) the theory, that strategy should seem very familiar:

https://swtch.com/~rsc/regexp/regexp1.html

It's just like Thompson's NFA algorithm, except each state transition is the RD parser "swallowing" a token, and that can be done in constant time, so the parse is still linear in the length of the input.

>>18
So just a nigger-rigged version of breadth-first search? Lrn2code, fudder.

Check em

Cudder is a coalburner!

>>18
The academics claim you need "infinite" lookahead to parse those correctly, because there can be arbitrarily many tokens before it knows which path to take. Bullshit. All you need to do is "fork" the current thread whenever there are multiple matches and feed the incoming tokens to all the active "threads", and when one can't proceed any further, it terminates. If there are no more threads, that's an error.
So, infinite lookahead.

>>22
Does matching regular expressions require "infinite lookahead"? No. Or maybe they'll claim it does, but ultimately it doesn't make a gnat's arse of difference. In the end, parsing C++ (and other ambiguous grammars) is not that hard. It's the other stuff like templates which is a little harder.

>>21
The term is "coal roller", dimwit.

>>18
What is int(x), y, *z;? Does it declare a pointer z? Or does it apply the * operator to z?

>>24
"If it can be parsed as a declaration, it will be."

You tell me.

Check em

C-dder is all talk and no action.

>>23
It requires infinite lookahead to prove certain things. You haven't gotten around that. Your solution is just declaring a convention to be the correct one. You can't "solve" the halting problem by giving it a finite time to run and then just assuming that it doesn't halt.

Cuddork is a backpedalling idiot who won't admit to the stupidity he blatantly displays.

Cuckdurr will never do anything useful with his life

>>24
The comma notation means the int is 'distributed' to each item in the comma-delimited list. So the last item in the list is really int *z. Which means the * is interpreted as the pointer declaration operator, as the dereference operator is a unary operator and multiplying a typename by an undeclared identifier doesn't make sense.

>>28
An infinite lookahead algorithm should halt on all inputs. The number of threads (equal to the number of possible interpretations at the current stage of parsing) and the size of the input are both finite, so every thread will eventually halt either by its interpretation ceasing to be possible or by reaching the end of the input. Even if the ambiguity cannot be resolved (two or more threads survive to the end of input), it still halts.

>>28
What the hell do you need to "prove" anyway. I claimed C++ parsing wasn't all that hard, and once you understand how it works, it really isn't. If you applied the same reasoning you'd probably claim the Thompson NFA algorithm needs "infinite lookahead" too, and yet AFAIK no one has ever said that.

>>31

as the dereference operator is a unary operator and multiplying a typename by an undeclared identifier doesn't make sense.

It could've been declared in an outer scope. If you want to really cast x to an int, read y and throw its value away (which is perfectly acceptable and the compiler would have to do it if it was declared volatile, and then apply unary operator*() to z, then you would need to do this:

(int(x), y, *z);

Type specifiers cannot start with a parenthesis, so the parser is immediately going to go down the expression path.

>>29,30
U MAD?

>>31
And since there is a constant number of operations done on each token input, the overall running time is still linear in the length of the input.

That is probably not going to be the case if you introduce templates, however.

Check em

>>34
Check what?

>>32
You claim that nothing is hard, that you can implement everything in plain asm in just a few days, and actually deliver nothing. Just shut the fuck up already.

And since there is a constant number of operations done on each token input, the overall running time is still linear in the length of the input.

No it's not, you fucking ignoramus. See
>>18

All you need to do is "fork" the current thread whenever there are multiple matches and feed the incoming tokens to all the active "threads"

>>36
You shouldn't expect anything from one who only talks without backing it up with action.

>>36,37
Isn't "linear time" generally used to mean "every thread runs in linear time or better" in the context of multi-threading?

>>38
No it doesn't, you double-fucking double-ignoramus.

>>36
The number of active threads cannot exceed a small constant.