"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 

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

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.

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.

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

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.

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.

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     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

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

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