CPU recommendations?

Steve at fivetrees wrote:
> "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.
> 

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!).

Steve at fivetrees wrote:

> [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 ;).
> 

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.

fredbasset1000@gmail.com wrote:
> Hi All,
> 
> I'm starting a new embedded control project soon, it looks fairly
> simple so far, read some analog and digital inputs and provide some
> PRM, digital & serial RS485 outputs.  Sampling at about 10Hz should be
> sufficient.  I'm thinking a lower speed 16 or 32bit CPU will do the
> job.
> 
> I'd like to use a CPU which:
> 
> supports source level debugging & fast code download for rapid turn
> around cycles
> has onboard Flash for of at least 64K
> has plenty of eval. boards and ref. designs available
> has uCos|| ported to it
> a free compiler and tools (I would pay if the tools where really good)
> optionally, can support C++
> 
> I'm wide open to using a PIC, ARM, Freescale, Atmel chip, anything at
> this stage
> 
> I know this question is fairly general but can anyone recommend a CPU
> meeting the above requirements?
> 
> Thanks,
> Fred

Atmel ATMega family.

In article <49d4a647$0$3491$8404b019@news.wineasy.se>,
David Brown  <david@westcontrol.removethisbit.com> wrote:
<SNIP>
>
>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 models (C).  This stuff
>is not rocket science now, and it was not rocket science when C++ was
>conceived - even if you don't want the full whole-program compilation
>process (because of long build times).  C++ was created by tagging OO
>onto C without doing anything about the design limitations and problems
>of C, and the result is a language that is not nearly as good as it
>could have been.

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

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

"Albert van der Horst" <albert@spenarnc.xs4all.nl> wrote in message 
news:ki3gjw.7vy@spenarnc.xs4all.nl...
>
> In practice I'm willing to restrict OO thinking to the design,
> and implement in whatever language is at hand, C, Pascal, Forth,
> Assembler.

Exactly my view too.

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