CPU recommendations?

Steve at fivetrees escreveu: [snipped]

Why? It seems brain damaged to me: a sorted list of triangles shouldn't need any inheritance, what it needs is to have a class Triangle that can be ordered in first place.

For this case use different (member) funtions.

I was heading to bed, but your post was too enjoyable. In particular:

Ah, agreed, but there are tools around these days to automate the process. "make depends" etc...

Well, to a point...

;)

Steve

--

I agree that (abstract) interfaces are key. Interfaces are exactly what a C++ class of nothing but pure virtual functions provide.

Exactly.

God love *nix.

Here are some of my favorite papers on OO from Robert C. Martin:

The Open Closed Principle The Liskov Substitution Principle The Dependency Inversion Principle The Interface Segregation Principle

Yep. I agree that the header file is the right place for such interface documentation. However, text files don't deal well with architectural issues (inter module). Diagrams speak volumes about such matters.

Hi Niklas,

Thanks for sett> I was wondering the same thing myself with respect to Modula-2 compilers.

I inferred from David's post that Modula-2 uses something similar to Ada's compilation library. My familiarity with Modula-2 is really much more passing than with Ada, so in retrospect the comment was probably misplaced.

Hi Niklas,

Thanks for sett> I was wondering the same thing myself with respect to Modula-2 compilers.

I inferred from David's post that Modula-2 uses something similar to Ada's compilation library. My familiarity with Modula-2 is really much more passing than with Ada, so in retrospect the comment was probably misplaced.

OSX is not different.... it IS UNIX... Linux is different

No, you normally use "make" with Modula-2 (at least, you did when I was at university - about 17 years ago). The point I was making with Modula-2 is that it has proper module support - implementation and interface files for a module are separate, and separately compiled (in the case of interface files it is just into a symbol file rather than object code). Modula-2 doesn't actually go far enough or take full advantage of the possibilities of this arrangement (at least, not the compilers I used at the time), but it's still far in advance of C or C++ with their text-based #include mechanism.

Do you really know what the difference between, for example, the terms UNIX, BSD, Linux, unix-like, *nix, OSX, or posix? And do you have any idea about what has changed in the *nix world over the last 30 years, and what has stayed much the same? Apparently you do not, judging by your post.

Perhaps I wasn't entirely clear here - I agree 100% with you that private details should not be exposed in the interface definition, and I've been complaining that C++ missed the chance to improve on that, and in fact made it worse (compared to C). I was merely giving the reasons for the current situation, even though I too think they are not strong enough - it was to make the compiler easier (after all, compiler writers are humans too!).

That's not quite right - the interface file should tell you "what", the question of "how" is left to the implementation file, and "why" should be handled by comments and the documentation.

Atmel ATMega family.

At the time this was the design goal:"tagging OO onto C". That was probably more difficult than tagging OO onto Pascal, or tagging OO onto ADA, and certainly more difficult than designing the right language from scratch. I don't think the job could have been done much better. OO-fundamentalist should select LOGO or Eiffel, each with their own problems, if only the lack of implementations for embedded systems.

In practice I'm willing to restrict OO thinking to the design, and implement in whatever language is at hand, C, Pascal, Forth, Assembler.

Groetjes Albert

--

Exactly my view too.

Steve

--