Let's recount the events here.
I mentioned it is possible to crash the init thread, but it took a lot of iterations to do so (< 30,000 iterations). You responded with "300,000 ops" as if there was some knowable translation between the number of iterations (or as the OP inquired, variable assignment) and ops produced.
"
Who says Jass is ever compiled down to machine code?"
Got me... who said it? Obama? See below...
"
Who says you need the compiled code in order to find out op costs?"
If we were writing all this in assembly language instead of jass, you wouldn't. But since we are talking about jass here, the number of ops is useless info without knowing how many ops the language produces when it is eventually converted to machine code.
Machine code is the only code your processor can process. It knows nothing about different source code languages. That means that source code must eventually be converted to the machine code that the computer understands. This can be done through an interpreter at run-time (relatively slow and usually impractical for time-critical applications) or as is done with languages like C, compiled into intermediate code (obj files) which are then "linked" and assembled into machine code.
Now, with that said, as a matter of terminology, the number of "ops" would be the number of machine code operations (ops) performed. One line of "source code" (such as jass or C) may produce numerous "ops" (save assembly language, which is pretty much a 1:1 ratio).
So, how does this correlate to the OP's post or my post? It doesn't. Therefore, in order to know the exact amount of ops that are produced by the HLL, one would have to know how the language is broken down into machine code. Unless of course, you are referring to "ops" as something else and simply misusing the terminology. If so, please feel free to translate.
{EDIT 1}
There you go... that's all I asked for as it descibes the ops generated by jass. Wasn't that simple?
{EDIT 2}
Jass compiles down to C++...
Given it compiles into C++ intermediate code (obviously not source code), then perhaps your comment is directed toward Captain Griffin who seems to think a compiler that would generate C++ would not be possible (at least given his response to my post about creating C++ intermediate code from C++ source).
If jass compiles down to C++, then it seems odd people would find it either impossible or improbable to create a C++ compiler that takes C++ source code and generates C++ intermediate code for WCIII.
I think you guys are jumping to conclusions before actually having read the posts in their entirety.
I simply said I would like to create a C++ compiler that generates WC3 compiled code (and according to your statement, that would be C++ - seems natural enough, doesn't it?).
Captain Griffin referred to it as an attempt to create "Compiled jass". Where that came from is anyone's guess.
Not to mention you can't actually know how Blizzard programmed it.
I'm not sure what you are trying to say here.
Are you trying to say you can't write a game if you don't know everything about how another game was written? If so... if people at Blizzard aren't privy to all the assets used in creating a racing sim (for example) and all its source code, then how on earth did they ever manage to write WCIII given your logic?
Or are you trying to say the C++ compiler can't be done because no one knows how "Blizzard programmed it"? In that case, you've already contradicted your above statement by saying it is compiled into C++ (how could you know if no one knows?). Obviously it's not impossible to produce the assets that Blizzard uses or reverse engineer the file format.
Good luck at writing a game.
Then I suppose luck has already been on my side since 1998. *shrug*
Edit: And as a side note, I would think being able to use full OOP C++ in writing map/ai code would be a welcome addition to the tools already available, given C++ popularity. Evidently, there are some here who would not appreciate it, however using it would not be compulsory.
