Are there any 8051 C++ compilers ?

As long as it is just a signature I personally don't really care and would advise anyone not to care either ;-) Admittedly, as soon as political discussion started here I wouldn't like it either.

Just my personal opinion about this. (Without saying whether I agree with the signature or not;)

Regards, johannes

I think C89 is a subset of C++, but C99 adds new stuff.

Of course you can choose to write code that's compatible with both.

Best regards, Spehro Pefhany

Good points, although I expect practically speaking compiler specific

Robert

This last one should be the other way around shouldn't it?

Robert

I concede it was too long, and it gets changed periodically. What politics :-) - It just quotes GWB, draw your own conclusions.

No. The C const is peculiar, and effectively means write protect. The i can't be used in constant expressions, such as array sizes. Try the C faq for details, or the standard.

The point is C is not a subset of C++. They are different languages with superficial similarities.

-- "The most amazing achievement of the computer software industry is its continuing cancellation of the steady and staggering gains made by the computer hardware industry..." - Petroski

this intrigued me, so

martin

Serious error. All shortcuts have disappeared. Screen. Mind. Both are blank.

You know very well that you can pick a bunch of Bush quotes making Bush look good or you can pick a bunch of Bush quotes making Bush look bad and that you can pick a bunch of Kerry quotes making Kerry look good or you can pick a bunch of Kerry quotes making Kerry look bad. Please don't insult our intelligence by pretending that doing so is being unbiased.

"Guy Macon" schreef in bericht news: snipped-for-privacy@news.supernews.com...

It takes more than intelligence, to pick a bunch of quotes making GWB look good.

The PR flacks that politicians hire do it all of the time, and I wouldn't call them "intelligent." They do have a sort of low cunning...

Still wrong. C was never a subset of standard C++, ever since the first standard definition of C++. To give just a few examples:

• C has implicit conversion of all pointers to and from pointer-to-void. C++ explicitly disallows that, for reasons that are fundamentally important in its view of the world, but counter-productive in C.

• sizeof('a')==sizeof(int) in C, but it's sizeof(char) in C++. Which usually means they're different.

• C (at least as of C89) still allows "implicit int" declarations. C++ never did.

You can, but it's a widely accepted opinion by the C gurus that you shouldn't. What point could there be to break a perfectly fine C program, just to please a foreign tool that was never meant to be used on C programs in the first place?

Why is that peculiar? Would you prefer it was spelled "readonly" or somesuch? I find it extremely useful for placing look-up tables and the like into ROM rather than RAM.

Ah. You think it should be a compile-time constant (like Pascal's) rather than a run-time constant?

That's definitly true.

I am trying to find diplomaticaly acceptable reasons for why we should not do this.

That is certainly true. The problem is, that it IS the client, and hence must be kept happy. I am gathering enough reasonable arguments for the changing of the spec.

The spec says any MCU with a '51 core. The existing design which we are updating is based on a 4 clock/machine cycle 8032 with external flash and SRAM together with a US$150 EPLD to provide enough I/O.

We want to change to either an AVR without the EPLD or a Philips or Atmel ARM MCU that has enough capabilities without the need of the EPLD and all the extra external components.

Regards Anton Erasmus

The spec has got all the right buzzwords etc. We have managed to stear the client towards a more reasonable stance on many points, but where we have unknowingly stepped on someone toes, it becomes much more of a diplomatic game in stead of an engineering one. It is much easier to say that we believe we have found a typo, since no C++ compiler is available for the '51, than to in any way imply "What idiot specced a '51 core and C++ as the language"

Regards Anton Erasmus

No, I don't think anything. The point is that is not a real compile time constant, unlike C++. Read the C faq.

A more optimistic view is that an amazing achievement of the computer software industry is its continuing use of the steady and staggering gains made by the computer hardware industry to implement systems that computer users desire.

There are some good ones there. One that I found especially insightful:

Walking on water and developing software from a specification are easy if both are frozen. (Edward V Berard)

... snip ...

Luverly. By contrast this points out, once more, why I am no diplomat and need buffering. I wouldn't even think of the 'typo' ploy.

Of course in certain circles this spec is an open ended license. It requires a compiler, which is not available, and therefore must be developed (at X units of currency per hour until done). After this necessary preliminary we can quote the fixed price for the actual job. The compiler development might be inserted by making the customer responsible for supplying the compiler, and if this is awkward we will undertake ..... The system will increase the critical buzzwords per page value.

With proper verbiage you could even supply the totally useless end product in source form, after development on some fully featured and standards compliant system.

I told you I was no diplomat. :-)

I know the difference, I just don't understand why it's the C implimentation of const that's "peculiar" instead of the C++ const being "peculair". Using the term "peculiar" led me to believe that you thought it somehow violated your (or the world's) expectations and didn't do what it should.

1. Though formally C is not a subset of C++, C++ was created with huge effort to make it compatible with C. Making C code correct C++ code usually is very easy - I did it many times and sometimes it helped to find some unknown bugs - thanks to some more strict rules in C++.
2. C++ is a multy-style languages and one of its use is described as "better C".

- so calling their similarities superficial is not true. For more details I would recommend to read:

1. The Design and Evolution of C++ by Bjarne Stroustrup
2. formatting link
3. More on topic: I always prefer to use C++ - even in embedded systems. It is not necessarily increase resources needed for executing the program code. Sometimes it even helps make code smaller and more effective - of cause not directly because of using C++. but C++ helps make source code smaller and more maintainable which helps to find and implement some solutions, which could be much harder with C.

Of cause some techniques that are popular in C++ often not appropriate in embedded area.

Last time I developed 8051 software (~5 years ago) I could not find C++ compiler. It was ~5 projects and would use C++ for all but one (this one had CPU with only 128 bytes RAM),

Regards, Michael Furman