I've been trying to learn it also, but studying alone makes me get bored of it easily. Anyone interested in learning C++ in a group? it'll be so CACHE (lol, get it?)!
>>81
But PHP ugly hacks are more oriented towards ``library''. Most perl syntax was removed, and they added that ugly <?php ?>. Damn, php as a template language could be so fucking powerful.
Name:
Anonymous2008-06-05 0:25
>>78 Sepples is never the right tool for the job. Stick with C, or risk having your anus haxed.
Name:
Anonymous2008-06-05 1:35
>>78
Both PHP and Perl suck, what the fuck are you getting at?
>>84
C++ is an octopus made by nailing four legs onto a dog, just as PHP is an octopus made by castrating 4 horses and attaching their penises onto random parts of a dead dog in an utter bloody mess.
Name:
Anonymous2008-06-05 3:44
>>75
Source on the implementation details? But regardless, my point was that there are a lot of clever things that can speed up dynamic languages enormously, and it's shortsighted to say that the current implementation of any particular language is the best possible.
>>70
Actually it's not. Apple suggests you do it manually ❝on the rare occasion❞ that you call something more than once. The only way to circumvent dynamic binding is to get the address of a method and call it directly as if it were a function. This might be appropriate on the rare occasions when a particular method will be performed many times in succession and you want to avoid the overhead of messaging each time the method is performed.1
All that happens automatically is this: To speed the messaging process, the runtime system caches the selectors and addresses of methods as they are used. There’s a separate cache for each class, and it can contain selectors for inherited methods as well as for methods defined in the class. Before searching the dispatch tables, the messaging routine first checks the cache of the receiving object’s class (on the theory that a method that was used once may likely be used again). If the method selector is in the cache, messaging is only slightly slower than a function call. Once a program has been running long enough to “warm up” its caches, almost all the messages it sends find a cached method. Caches grow dynamically to accommodate new messages as the program runs.2
which surely is nowhere near ❝slightly slower❞, since you now have two function calls along with a table scan.
>>88
I think >>86 just castrated the horses for fun, and removed their penises later.
Name:
Anonymous2008-06-05 9:18
>>87
I wasn't saying that, I was saying that vtable-based dynamic dispatch will always be faster than multiple-hashtables-based dynamic dispatch, no matter how you optimize it. Both because the former is inherently faster and because much of the latter's optimizations also apply to the former.
Name:
Anonymous2008-06-05 16:23
>>92
You are assuming that dynamic dispatch must do the worst-case legwork in most situations, which is plainly not the case. While the worst case may be worse, when your run-time has dynamically inlined the most common methods, you're nowhere near worst case, and have reduced the cost of method dispatch in most instances to a type-check. So yes, doing more work is slower, but no, merely having the potential to do it does not slow you down if your run-time is good enough to avoid that work. I stress that there will be more clever tricks to come in the future. And it's folly to ignore both known optimizations and future ones, saying, "It can only be implemented this way".
Name:
Anonymous2008-06-05 17:17
real C++ programmers write their dispatch logic as templete metacode
Name:
Anonymous2008-06-05 18:00
>>93
You are assuming that I assumed what you think I assumed. I meant just what was said in >>92, no more, no less. Also, unknown future optmizations are only relevant to future arguments.
Name:
Anonymous2008-06-05 18:21
>>95
Well, somebody said, It can only be implemented that way.
This is a statement about all possible optimizations, both current and future. I am refuting it. That is all.
Name:
Anonymous2008-06-05 20:03
>>96
Dude, in that post, "that way" == "not through vtables".
Name:
Anonymous2008-06-05 21:13
>>97
Dude, in that post "clarity: not found". If that's actually what was intended, it's the most backwards locution imaginable. In what world does "that way" refer to "every possible way except for some arbitrary other method that I expect you to psychically know I'm thinking of"? But I don't believe that's what was intended. Someone said "it's a problem with a specific implementation" and the response was "It can only be implemented that way".
>>58: looking up methods by global identifier is slowing than indexing a fixed array >>59: ONLY CUZ UR COMPILER IS DUMB HURR >>60: no, that's just how things work >>62-999: HURRRRRRRRR
so where does the fucking psychic bullshit come in? are you blind or just retarded?
Name:
Anonymous2008-06-06 5:36
ITT: Sepplers being trolled
Name:
Anonymous2008-06-06 11:01
>>98
No, clarity abandoned the discussion in >>59. It was as vague as it could be. >>60 made the mistake of replying to that shitty post and everything got fucked up since.
>>99
I'll be blind, since you're clearly handling "retarded".
>>58 looking up methods by global identifier is slowing than indexing a fixed array >>59 Then don't do it like that. >>60 i has to >>66 No, you don't (insert real-life example here). >>70 Counterfactual claim about Objective-C implementation. >>92-999 FUCK, HE CAUGHT ME: BACKPEDAL
>>103
Your “real-life example” didn't remove the need for method lookups. It will always be slower than not having them at all.
A language with dynamic methods has to be implemented with dynamic method resolution, i.e. “that way”.
Name:
Anonymous2008-06-06 18:03
>>108
Are you stupid or do you just not understand type-feedback (I guess those would be the same thing)? Removing the need for method lookups is exactly what it does.
Is that really what you meant to say, or is this a case where you mean one thing yet say something that could not possibly be construed as you will later claim you intended?
>>116
You must be new here. Please refrain from posting until you have lurked enough.
Name:
Anonymous2008-06-08 4:13
C++ is only complicated because many of you are too content with baby languages that do your memory management for you, at the cost of worse performance. PROTIP: Garbage Collection is for NIGGERS and the UNEDUCATED. OOP and templates are not hard, and C++ takes care of that quite well. Why don't you actually try learning the language so real programmers don't have to put up with your interpreted language bullshit.