CPU recommendations?

"Pertti Kellomaki" <pertti.kellomaki@tut.fi> wrote in message 
news:gr23tg$rqd$1@news.cc.tut.fi...
> David Brown wrote:
>
> The reason for the private part (as you probably know) is separate
> compilation. If code in another compilation unit needs to create
> an instance of Motor, it needs to know how much memory to allocate.
> In the traditional Unix style compilation model, the information
> needs to come from the specification (e.g. Motor.hh). If it is
> in the implementation part (e.g. Motor.cc), then you either need
> some kind of compilation library, or an additional whole-program
> compilation step before linking.

You're right *from the compiler's point of view*. Not from the human's point 
of view.

Programming languages exist to make programmers' lives easiers, not the 
compilers'.

Exposing "under the hood" private details in the public header is just plain 
wrong. It's indefensible.

Steve
--
http://www.fivetrees.com 

Steve at fivetrees escreveu:
[snipped]

>  Multiple inheritance
> is broken - it shouldn't be there in the first place, or it should be
> done properly (allowing a "sorted list of triangles" to inherit from
> both "list" and "shape").  

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.

> Overloading is broken - there should be a way
> to handle overloading based on return types, 

For this case use different (member) funtions.


-- 
Cesar Rabak
GNU/Linux User 52247.
Get counted: http://counter.li.org/

"David Brown" <david@westcontrol.removethisbit.com> wrote in message 
news:49d467c7$0$22007$8404b019@news.wineasy.se...
> Steve at fivetrees wrote:
>>
>> Your turn ;).
>>
>
> I can't really argue with you when we agree on most of the points - it's 
> really only a difference in weightings and nuances.

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

>> To paraphrase Churchill, C is the worst possible language, but it's the 
>> best we've got. <<

That got me thinking. I agree. I guess I've grown so used to working around 
the deficiencies of C, and dealing with it as a super-assembler, that I'd 
missed the value of your (more tolerant) view on (the newcomer ;)) C++. 
Thanks for the insight.

Steve
--
http://www.fivetrees.com 

"Chris Burrows" <cfbsoftware@hotmail.com> wrote in message 
news:Q66dnQBMFJmEO0jUnZ2dnUVZ_uGdnZ2d@posted.internode...
> The fact that languages like C need separate makefiles that have to be 
> manually maintained to keep in sync with source code is a disadvantage NOT 
> an advantage. Not only is it a tedious task it is also error prone.

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

Well, to a point...

;)

Steve
--
http://www.fivetrees.com 

Steve at fivetrees wrote:
> "Michael N. Moran" <mnmoran@bellsouth.net> wrote in message 
> news:6lWAl.23691$v8.7089@bignews3.bellsouth.net...
>> Steve at fivetrees wrote:
>>> My main objective in writing code these days is clarity,
>>> clarity, and yet more clarity.
>> Clarity is good.
>> Clarity at the module/file level is possible.
>> Clarity at the inter-module level requires
>> external documentation.
> 
> For me, it's about interfaces. I deal with a 3-terminal regulator as you'd 
> expect: one input, one output, one ground. I read the datasheet from time to 
> time (yes, external documentation [1]), but the interface is my main 
> connection.

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

> So it should be in software. I don't need to know the details of what's 
> going on under the hood (unless I need more detail about my I/O than I 
> understand); I just need to know what it does. 

Exactly.

> I do a lot of Unix sysadmin work; I can configure one 
> .conf file happily while having some faith that the code
> will do what I ask. I don't need/want to know anything
> else.

God love *nix.

> Fundamentally this comes down to good decomposition and good methodologies 
> for interfacing. Some of these techniques are now well-understood 
> ("spaghetti code sucks", "globals are bad"); some less so -  learning good 
> decomposition and breaking things down into simple modules with clean 
> interfaces seems to be a hard thing to teach. Or indeed learn.

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

<http://www.objectmentor.com/resources/publishedArticles.html>

> [1] Trouble with s/w documentation is that it is always out of sync with the 
> code. I'd rather the header file provided the interface and all the details 
> of "how" and "what"... the docs will likely tell me what the originator had 
> in mind for version 0.1 ;).

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.

-- 
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
"Already Gone" by Jack Tempchin (recorded by The Eagles)

The Beatles were wrong: 1 & 1 & 1 is 1

Niklas Holsti wrote:
> Can you explain why you think that Ada compilers do not play well with 
> 'make'?

Hi Niklas,

Thanks for setting me straight about Ada. The last time I did
any serious development with Ada was a long long time ago, and
the compiler's compilation library was certainly not exposed to
the programmer.

Chris Burrows wrote:
> 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.
-- 
Pertti

Niklas Holsti wrote:
> Can you explain why you think that Ada compilers do not play well with 
> 'make'?

Hi Niklas,

Thanks for setting me straight about Ada. The last time I did
any serious development with Ada was a long long time ago, and
the compiler's compilation library was certainly not exposed to
the programmer back then. But as I said, this was a long way back.

Chris Burrows wrote:
> 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.
-- 
Pertti

In message <gr33kk$e5e$1@news.cc.tut.fi>, Pertti Kellomaki 
<pertti.kellomaki@tut.fi> writes
>David Brown wrote:
>> I know the reason for including the private part - it's still very 
>>bad design.  It's based on a compilation and link strategy that was 
>>aimed at the limited computers of 30 years ago, and is simply not 
>>appropriate for a language of C++'s date.  There were already better 
>>models in use at that time (such as Modula 2) - C++ should have been 
>>better than existing  models, not worse than the reigning king of bad 
>>
>
>In a very true sense we still have the computers of 30 years ago, they
>are just a lot faster. Linux and OSX are really not all that different
>from 1970's Unix.


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

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Pertti Kellomaki wrote:
> Niklas Holsti wrote:
>> Can you explain why you think that Ada compilers do not play well with 
>> 'make'?
> 
> Hi Niklas,
> 
> Thanks for setting me straight about Ada. The last time I did
> any serious development with Ada was a long long time ago, and
> the compiler's compilation library was certainly not exposed to
> the programmer.
> 
> Chris Burrows wrote:
>> 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.

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.

Chris H wrote:
> In message <gr33kk$e5e$1@news.cc.tut.fi>, Pertti Kellomaki 
> <pertti.kellomaki@tut.fi> writes
>> David Brown wrote:
>>> I know the reason for including the private part - it's still very 
>>> bad design.  It's based on a compilation and link strategy that was 
>>> aimed at the limited computers of 30 years ago, and is simply not 
>>> appropriate for a language of C++'s date.  There were already better 
>>> models in use at that time (such as Modula 2) - C++ should have been 
>>> better than existing  models, not worse than the reigning king of bad
>>
>> In a very true sense we still have the computers of 30 years ago, they
>> are just a lot faster. Linux and OSX are really not all that different
>> from 1970's Unix.
> 
> 
> OSX is not different.... it IS UNIX... Linux is different
> 

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.