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?)!
:(
Name:
Anonymous2008-06-04 0:25
How funny that the below would be written just in time for this discussion.
>>60 It can only be implemented that way.
That's not correct. I would bet good money that it's possible to fix this up either in the compiler or at run-time.
Name:
Anonymous2008-06-04 7:48
>>54
We're all EXPERT programmers here who have read SICP. We can learn any language on our own in a couple of days.
If you really want to just start learning C++ on your own. If you have any questions you can always ask on /prog/ and the helpful /prog/community will surely answer all your questions.
Name:
Anonymous2008-06-04 10:40
>>62
Not really. Objective-C's dynamic dispatch allows any method to be called on any object at runtime, just like in any dynamic language. C++'s dynamic dispatch restricts wich methods can be called on a object based on the type of the variable that holds the object. If you were to give Objective-C C++'s brew of dynamic dispatch, you would end up turning Objective-C into C++. And that would suck royally.
>>64
Yes, really. It's possible to leave this feature in the language from the programmer's point of view but optimize around it most of the time. For example, in a loop a variable's type may be likely not to change. In that instance you can inline the method, reducing the performance hit to a safety check to confirm that object's type (which may be as simple as inspecting your reference to the actual data -- no need to dereference a pointer and load it into memory). This can be applied in other situations as well, and I'm sure there are other techniques I'm forgetting/which haven't been invented yet.
Name:
Anonymous2008-06-04 16:16
C++ is a bunch of confusing bullshit that nobody needs.
Name:
Anonymous2008-06-04 16:40
>>61
um, can anybody say Amiga from 1985? They did a ton of OO features in plain C all through the OS and public APIs, and I suspect they weren't the first.
>>67 EXPERT PROGRAMMERS are not confused by C++, even if it is not their first choice of languages. faggot
Name:
Anonymous2008-06-04 17:25
Make a Half-Life 2 mod. Also, get some good book on C++ that you can use as a reference. Hack a lot.
Name:
Anonymous2008-06-04 17:48
>>66
That particular optimization, along with method caching and maybe others I don't know about, is already part of the implementation. Resulting programs are still slower than C++ equivalents (though they are never really equivalent, due to not being as dynamic).
C++ is fucking messy and outdated. I think it is a fine language though for a lot of reasons. At the same time there are some languages anyone would prefer to work in. I think F# offers a lot of options to any programming project. The language really takes a backseat to the programmer and allows you to dictate which tool for the job more so than in C++ or some other languages (java/c# etc).
F# is my true love at the moment, although I don't mind sleeping around.
Name:
Anonymous2008-06-04 19:00
>>63
Well, I would like to learn C++, but I'm open to suggestions for any other language. And does "SICP" really help with anything? Or is that just a /prog/ meme?
It's not much but will give you an idea. Notice that in the benchmarks where the Objective-C programs make significant use of method calling (namely binary-trees and spectral-norm) those programs are at least 2 times slower than the corresponding Java programs.
Name:
Anonymous2008-06-04 20:37
I am about to learn C++, and I found the book "Beginning C++ Game Programming" from 2004 to be very helpfull. It teaches you C++ from the scratch, with a cool game-angle on it.
Very well-written and fun to read/learn.
Name:
Anonymous2008-06-04 20:48
>>57 For the things that C and C++ are really the Right Tool For The Jobtm, such as low resource environments (embedded systems, etc) or truly real time applications (of which there are very few, and your program that sorts your music collection is not one of them, but medical equipment requiring real time response is)... then generally assembly is your only other resource to get that close to the machine and if you think Sepples is a lot of pointless work to get something done you haven't written an entire program in assembly lately.
>>77
Wrong, you should use C everywhere and forget about higher level languages. Assembly breaks portability, don't use it unless you are a huge faggot with a lot of time.
>>76
Just use fucking SDL instead of DirectX. Also, lol at abstraction layers selling themselves as direct hardware access
>>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.