I didn't think much of OO techniques until I had written a small handful of programs in them. At least to me, all the reading in the world wasn't going to make it obvious what the real advantage was...
Those first programs were in Smalltalk too, but I've recovered from that. :-)
What part, MFC or something? Most companies writing "major apps" (Symantec, Corel, even Microsoft themselves) do end up writing their own GUI libraries.
Visual Studio itself varies greatly between "crap" and "excellent" depending on exactly which version you're using. The better versions are as good as any
C++ is most definitely an OO language. The OO features account for most of the differences between C and C++.
OO is a natural fit for GUI toolkits, although it doesn't have to use C++. Both Xt and GTK are written in C but provide OO interfaces.
program,
Given that you don't use OO and don't appear to even understand it, your opinion of OO doesn't really have a great deal of weight.
Of course, it's *possible* to write any application without using an OO language or even OO concepts. But OO can provide very definite benefits in terms of modularity.
The semiconductor people tend to do the same thing, let multiple users find the same bugs over and over. I know of datasheets that are years old that don't hint about very serious problems.
BEWARE THS3062. It's fatally flawed and the latest datasheet is from
2002. How many people have been burned by this one? (I was, literally.)
Let me up that a bunch. I look at c++ in retrospect in my programming and i conclude that it is a bunch of syntactic heroin. I messes your head and is hellishly addictive, ands degrades your (and mine) ability to write good SW and particularly to write good OO software.
Erlang is the current poster child. It uses asynchronous message passing, has awesome performance that scales linearly up to at least hundreds of CPUs, and has been used for more than a decade to build time-critical software (like telephone exchanges for example).
There are many functional languages where parallelism doesn't need to be explicit - they are side-effect free so can be automatically parallelised without the programmer even needing to know.
Both Erlang and FP require a shift of focus for the programmer, but that's a Good Thing ;-).
On a sunny day (Fri, 22 May 2009 02:01:01 +0100) it happened Nobody wrote in :
program,
Strange, as I did program in Visual C++, what according to you is 'OO'. There is nothing to understand in ohoh (Dutch word play), it is just a construct by those who do not know how to program, to cover up for their shortcomings. Just like your argument does not have anything other then 'modularity', I mentioned 'modularity' before, and modularity is something one can achieve in a much simpler and clearer way in C. But as C++ programmers so not really know C, they only know the ++ constructs, so they use those, creating bloat and crap code.
You do not have to take my opinion for it, if you trust MIT, this is what they say: (from
formatting link
In the academic realm of MIT there is a long tradition of criticizing object-oriented programming as a false annunciation. Usually this claim is founded upon the observation that there are no formal innovations in object-oriented programming -- that the paradigm never brought out a technique or characteristic of programming languages not known to academics by another name. Classes and inheritance are syntactic sugar, whereas polymorphism has long been known to Lisp developers as "dispatching on type." Overall, object-oriented programming, generic programming, and whatever else the designers of static programming languages[clarification needed (see discussion)] add to augment the expressivity of these languages have been formally known to programmers of Lisp for many years[citation needed]. What has been wanting in Lisp is efficiency, and the addition of these techniques to static languages[clarification needed (see discussion)] brings their efficiency to the fore.
So, now MIT can be wrong at times, like that wireless power Tesla-re-invention.... But they got rid of that by selling it to Intel.... But they _do_ have some knowledgeable people. Why not listen to that? I mentioned linked lists, and people should know those. Guess what Lisp is based on?
formatting link
Before any of that OO crap, one should first learn the basics of programming. Then you likely do not want OO. What we need is programming power, to solve problems in the fastest simplest way, not code castles in the sky.
In the stone age that was true. But on the latest CPUs with sophisticated branch prediction, out of order and speculative execution the time to compute the immediate compare is invisible. This is particularly true in this case where the loop doesn't contain enough other computational work to absorb the memory access time.
The only way to speed it up is to either vectorise it with SIMD SSE instructions or add judicious prefetch cache hints to the loop code. Branch target alignment to 32 bytes might also help.
Most of these tricks have limited utility on the latest quad cores, but they do help on earlier P4 models.
You have shot yourself in the foot with this cheap jibe. It is now very clear for all to see that you do not have the first clue about how things execute on modern Intel CPUs. BASIC hacker mentality.
It is you who needs to ask an expert. In case you feel inclined to "get a clue" the relevant Intel optimisation manuals are at:
formatting link
The one you want is right at the bottom titled "Intel® 64 and IA-32 Architectures Optimization Reference Manual"
C:\\files\\per\\FREEBA~1\\code>test Ten passes in 3.178 seconds. C:\\files\\per\\FREEBA~1\\code>test Ten passes in 3.213 seconds. C:\\files\\per\\FREEBA~1\\code>test Ten passes in 3.221 seconds. C:\\files\\per\\FREEBA~1\\code>
Will have to learn the SIMD instructions. I didn't think I had an assembler that could handle even MMX, but apparently FreeBASIC can...
DIM i AS long i =3D 0 asm mov eax,1 cpuid and edx,8388608 mov cl,23 shr edx,cl mov [i],edx end asm if i =3D 1 then print "You have MMX" else print "No MMX" end if
You can write C++ code without using any of the OO features, as it's almost a superset of C.
No, you just don't understand it.
Not really. OO provides a different kind of modularity. E.g. it's possible to derive (extend) a class without knowing anything about the data representation.
You're just projecting your own ignorance of OO onto people who do understand it.
say:
Er, that quote wasn't written by "MIT". The author appears to be citing views he doesn't entirely understand, much like you.
If you want to argue the pros and cons of OO with me, you need to do so on the merits; appeals to "authority" will get you nowhere.
[Especially RMS; his aversion to OO is one of the main reasons why XEmacs remains as a fork rather than having merged with GNU Emacs.]
Also, I don't give much credence to academics without much real-world experience. While the academic side has its uses, there's a lot that you can only learn by practical experience. In particular, knowing what works when software is developed and maintained over decades by hundreds of different people, most of whom make relatively minor contributions.
I learned Lisp long before any OO languages (my first was Smalltalk), and it is one of the few languages that I use regularly. But even Lisp has CLOS, which suggests that even Lisp programmers have a use for OO.
way,
OO doesn't really help if you're only solving small problems. But it can be extremely useful when you're dealing with code which needs to be readily extensible, or is so large that "global" knowledge isn't feasible, or which naturally fits the OO paradigm (e.g. component-based systems and simulations).
Java has the "synchronized" method qualifier. The language specification also spells out load/store semantics in some detail to ensure consistent semantics for concurrent code.
Concurrency was fundamental to Occam, but that's ancient history.
Quite a few languages include threading in their standard library (and modern languages tend to put as much as possible into their standard library rather than in the language itself).
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.