Bug in compiler

 Bug in compiler

I,ve installed the Compiler and I can,t get even the simplest code to compile properely.

Anyone know where the fix for this bug is?

Or is it a limit of the demonstration version?

void main(void)
{ cout << "Hello world!";
}

 what compiler you install ???

what is it the compileer you installled?

keil c????

if you be answer keil c then code you give is bad and not compiler

you code is c++ but compile is c

c not thinking about cout like this you be not good and give errror

 RE: what compiler you install ???

Can someone answer my question in English please!

 In English

Keil C51 is an ANSI 'C' compiler - it is not a C++ compiler, and does not claim to be one.

http://www.keil.com/c51/c51.asp

Your code is C++ and, therefore, will not compile with Keil C51.

This is not a bug - this is perfectly correct behaviour!

 RE: In English

So, if I pay for the compiler I will be able to compile this simple program.

Why is the demonstration version so limited? It looks very weak! Microsofts free compiler can do so much more!

I can,t afford to pay for the full version! So can you recommend to me a good cheap compiler that can do this simple job?

 RE: In English

So, if I pay for the compiler I will be able to compile this simple program.

No. Your program is written in C++. The Keil C51 is a C compiler. It will compile programs written in C, but not programs written in C++, Pascal, Fortran, Oberon, Smalltalk, or any other programming language that is not C.

Why is the demonstration version so limited?

The limits of the evaluation verison have nothing to do with the "problem" you have encountered.

Microsofts free compiler can do so much more!

Microsofts compilers cannot produce output that will run on an 8051. If you need your programs to run on an 8051, you will need to use something other than a Microsoft compiler.

So can you recommend to me a good cheap compiler that can do this simple job?

A free/cheap C++ compiler for the '51 ? Sorry. There is a C++ compiler, but it's not cheap or free. There are free compilers, but they do C, not C++.

How about you switch to programming in C instead of C++ ? Then you will have plenty of options. Maybe the evaluation version of Keil will actually suffice for what you are trying to do.

 More positive response anyone?

Someone give a more positive (and helpful) response please!

I know how to write code using cout and expect my compiler to do it. Why so difficult to get a simple answer?

 you no deserve goodod answering!!!!

you looking very rude and not good!!!!!

why you not be listening??

code with cout using c++ not c

keil is goodc c compiller and good for profesional 8051 programers

if ypou needing c++ for 8051 you specnd big money you think!!!!

 c++ prices

looking at

http://www.ceibo.com/eng/pdf/c++prices.pdf

 RE: More positive response anyone?

Someone give a more positive (and helpful) response please!

So, essentially you're asking "Please tell me what I want to hear." ?

All the information you need is already in this thread.

I know how to write code using cout and expect my compiler to do it.

If you use cout, then you are writing code in C++. "Your compiler", therefore, needs to be a C++ compiler. The Keil C51 is not a C++ compiler.

In simple terms, you're trying to pound a nail with a screwdriver. You are using the wrong tool for the job at hand.

Why so difficult to get a simple answer?

The simple answer is already in this thread. The problem is that you did not read, understand or believe it.

 RE: More positive response anyone?

Someone give a more positive (and helpful) response please!

It looks pretty helpful to me... You want a C++ compiler but the Keil compiler isn't.

I know how to write code using cout and expect my compiler to do it. Why so difficult to get a simple answer?

I believe your questions have been answered.

Are you aware that you are posting on an embedded toolset forum?

If you're simply looking for free stuff on a PC then check out the GNU compiler. http://gcc.gnu.org/ They also have their own forums for support.

--
Joost

 Found one myself!

I've found one at Ceibo :)

Even better is that they have a demo version.

http://www.ceibo.com/ftp-site/update/8051cpp.zip

I,ll give it a try and see if it does better than the limited Keil package.

 RE: Found one myself!

I,ll give it a try and see if it does better than the limited Keil package.

I'm sorry to tell you this, but the Ceibo C++ compiler uses the Keil compiler. Any limits that the evaluation version of the C51 compiler has (regarding code size, memory map restrictions, etc) will thus be inherited by the "free demo" of the Ceibo compiler.

And since the evaluation version of C51 is limited to 4 kB code size, you will most likely run into problems when you use "powerful" (also known as "bloated") string output functions like cout or printf().

Are you aware that the Keil compiler will not produce any output that will run on a PC ? It is a compiler for 8051-based microcontrollers.

 RE: Found one myself!

I like C++ for embedded work. I do not like to use the C++ libraries, because of their size.

Trying to use C++ to write code for a demo compiler with a 4kB limit is quite amusing. I whish you great luck. You will be very happy with your choice...

If your goal was to write programs for a PC, then good luck.

If you where really planning on writing programs for '51-chips, then I think it is time you try to read up on the processor architecture. Don't talk about limited compiler until you have figured out exactly how limited the processor is, when it comes to running high-level languages.

It's a bit interesting that whenever someone gives you an answer you don't like, you are rude towards them. Basically, you are the kind of guy would google for information. If the first 10 (or 100) links says something you don't like, you continue scanning links until someone gives the "correct" answer. Even the 100th link is at the 100th place because the contents of the document is wrong...

 Anyone got good information

Why have a demo version that won,t compile my simple program?

Anyone got any other suggestions (please limit to ones that are both helpful and in English)?

 RE: Anyone got good information

Why have a demo of a C compiler that doesn't compile Ada?

Why have a demo of a C compiler that doesn't compile Pascal?

Why have a demo of a C compiler that doesn't compile Cobol?

Don't you still get it. C and C++ are two completely different programming languages. You may test any C compiler in the world. It doesn't matter. A C compiler just can not compile C++ programs. I say it once more: A C COMPILER IS COMPLETELY UTTERLESSY IMPOSSIBLY UNABLE TO COMPILE A C++ PROGRAM, SINCE C++ IS A COMPLETELY DIFFERENT LANGUAGE!!!

What does it take for you to realize that you are trying the wrong programming language?

Would it help if I say it in Swedish? En C-kompilator kan inte kompilera C++-program!

Other people on this forum might be able to help with other languages, since it seems obvious that you can't parse English...

 RE: Anyone got good information

Why have a demo version that won,t compile my simple program?

What part of

"A C compiler will not compile C++ code."

is not clear to you ?

Even if you bought the full version of C51, it still would not compiler your C++ code, because

the C51 compiler is a C compiler.

Also, your program isn't "simple". It uses a string formatting and output function, and those are extremely powerful and complex, which translates into a very large code size. It can fill up a sizable portion of a 8051s memory without any problems.

For this reason, this type of function is usually avoided in embedded programming.

 Alternatives please

Thanks for your comments guys.

So, in brief, the demo of the Keil C compiler will not do what I want and nor will it even if I spend a few thousand bucks on it.

The ceibo might do it if I spend a few thousand bucks, but I cannot test it out on my complex one line program because it uses the Keil C compiler - Which (apparently) cannot compile C++ programs. This raises the question if Keil C cannot do it, why does ceibo come bundled with it?

Anyway, I need to know of alternatives and not just get you can,t do it style comments.

Can the SDCC compiler do it? It,s based on GNU tools I think so can I use the GNU C++ with that?

 RE: Alternatives please

...my complex one line program...

Can the SDCC compiler do it? It,s based on GNU tools I think so can I use the GNU C++ with that?

Your trying to build your one line program for a 8051? Where will the "cout" output go?

From the website:
SDCC is a retargettable, optimizing ANSI - C compiler

As stated in earlier posts: ANSI C is NOT C++.

--
Joost

 RE: Alternatives please

Where will the "cout" output go?

cout = console output

I,ve been given some hardware with a display on it.
A display makes a good console output.

So I need it to go to the display.

I know SDCC is a C compiler, but it is based upon GPL code so I think maybe someone hitches it to the GCC compiler chain.

Probable you think?

 RE: Alternatives please

I,ve been given some hardware with a display on it.

... and the compiler is supposed to know about this how ?

A display makes a good console output.

It's nice and human-readable, but way, way more complex than, say, a serial port.

So I need it to go to the display.

In that case, you'll need to write code that controls the display, or find some library that contains such code.

The compiler doesn't know about the hardware you're using.

 RE: Alternatives please

I,ve been given some hardware with a display on it.
A display makes a good console output.
So I need it to go to the display.

You'll probably need to do a bit more to get this working (display driver?).

I know SDCC is a C compiler

I wasn't sure because you didn't find this info for the Keil compiler.

but it is based upon GPL code so I think maybe someone hitches it to the GCC compiler chain.

I'm not sure what you mean with "hitching it to the GCC compiler". If you mean adding 8051 support to GCC (C++), I wouldn't call that "hitching" :-)

So, basically your question is: "does anyone know a free (as in beer and speech) C++ compiler for the 8051?". Is that correct?

--
Joost

 RE: Alternatives please

Anyway, I need to know of alternatives and not just get you can,t do it style comments.

The alternative you should look at is what languages that the majority of all developers uses when using '51 chips.

Some use C. Some use C. Then some use C. Most most of then tend to use C. Of the C users, some mixes in ore or less assembler, for the situations where a low-level high-level language is still too high-level.

I haven't looked at the compiler you mention, but there have since the birth of C++ existed C++ front-ends - parsers that takes C++ code, and mangles it into C code for use by a compiler. C++ was originally developed with C-Front.

Your simple line of code makes use of templates. I don't think you know too much about C++. If you did know C++, you would know the contents of the STL. You would know exactly how much code the compiler needs to mangle through to be able to decide what code to generate for that single line. You would also know how much run-time help that would be linked into your binary. On a PC, some compilers can manage to incorporate from 100k to more than 1MB for a trivial C++ binary that writes "Hello World" using cout.

It is now up to you to use your professionalism to consider the value of filling up most of the processor code space with runtime library code - even before you have started to implement an application.

Hint - how many microwave ovens have a need for a command line? How many intelligent battery chargers needs support for a path and environment variables? How many camera flashes needs a string datatype?

There are many ways to fail a project. You can be among the few who fails even before you have started - just by deciding that the two plus characters are the most important aspect of the project... The choice is up to you. If this is a school job - why fail before starting? If it is for a business - think about the badwill of the failure!

 RE: Alternatives please

The ceibo might do it if I spend a few thousand bucks, but I cannot test it out on my complex one line program because it uses the Keil C compiler -

As I have said before: The problem you are going to run into if you use the Ceibo + Keil combination is that the evaluation version of Keil C51 only allows a code size of 4 kB. Any complex string formatting function (this includes printf and cout) will easily need upwards of 10 kB code space.

There's no need to use sarcastic bold letter. Any program that uses a string formatting function _is_ large and complex for a simple 8-bit microcontroller as the 8051.

This raises the question if Keil C cannot do it, why does Ceibo come bundled with it?

Because one way of compiling C++ programs is to use C as an intermediate step.

So a C++ compiler might translate a C++ program into a C program, and then a C compiler can be used to translate this C program to assembly. I would guess that this is the way Ceibo does it - this way they don't need to make their own C compiler (and they'll have a hard time trying to beat Keil or any of the other existing solutions).

Anyway, I need to know of alternatives and not just get you can,t do it style comments.

If you had actually bothered to fully read the comments, you would have noticed several alternatives already. But I'll give you the list.

1. (this is not an alternative, but a prerequisite) Learn to extract useful information from human-readable text instead of being rude to the people who are, in fact, trying to help you. Use this skill to inform yourself about the particularities of the 8051 architecture (by reading the appropriate datasheets and the hardware documentation) and why C++ might not be a good language choice for this type of device.
2. Switch to a programming language that is more appropriate for a small device such as a 8051-type microcontroller. Plain C would be one such language. Your simple program would stay "simple", i.e. one line. (By the way, since you're trying to print text - where should the microcontroller output this text ? I did not see any intialization of an output device, for example a serial port)

Can the SDCC compiler do it? It,s based on GNU tools I think so can I use the GNU C++ with that?

I wouldn't think so. To make C usable on a 8051-type device, quite a few extensions need to be added to the C compiler. GNU C++ will not know these extensions. You may feel free to modify the GNU C++ compiler to your needs, however. It is free software, after all.

 A couple of alternatives

Here's a couple of alternatives:

#1 - Go ahead with your plan to modify SDCC and the GCC compiler chain to produce 8051 C++ code.

#2 - Consider a way of working around the 4K limit of the demo compiler. Maybe split your program into 2 or more blocks each being small enough to produce an executable less than 4K. Not sure how you'd split your one line program up though.

But, be warned, I (and probably most) would consider neither to be practical.

 RE: A couple of alternatives

Alternative:
Can't you switch to C? Do you really need C++?

--
J

 Sarcastic comment overload

Ok guys,

Looks like I'm not getting through to you here!

You make these comments without knowledge or appreciation of the requirement.

My contract requires me to produce code for an 8052 controller board that has a keypad and a display.

I need serious options please.

 RE: Sarcastic comment overload

Looks like I'm not getting through to you here!

Well, you've discounted the hints and opinions of several experienced developers. I think the issue of who isn't getting through to whom is acutally reversed.

You make these comments without knowledge or appreciation of the requirement.

Well, it's not like you completely left us guessing at what the requirements were, right ?

My contract requires me to produce code for an 8052 controller board that has a keypad and a display.

Well, why didn't you say so ?

If your contract doesn't explicitly state that C++ must be used, then you are free to use a much, much more appropriate language for the microcontroller in question, such as C.

And after you have made this decision, you can proceed to the real time-consuming parts of your task. Like reading the datasheets of the keypad and the display and write the appropriate code so your '51 can actually communicate with these devices (no, your compiler won't do that for you. It knows exactly nothing about the peripherals attached to your MCU. May, if you're really lucky, you can find libraries, but I wouldn't count on it).

 Pot calling Kettle...

"Looks like I'm not getting through to you here!"

On the contrary - it's the return path to you that isn't working.

You seem totally unable to understand that C and C++ are different programming languages.

"You make these comments without knowledge or appreciation of the requirement."

nobody can know your requirement if you haven't stated it!

"My contract requires me to produce code for an 8052 controller board that has a keypad and a display."

I see no requirement there to use C++

Where is the requirement that the programming language used must be C++ ??

"I need serious options please."

Why do you not consider writing in 'C' to be a serious option?

However, if you do have a bona-fide commercial requirement for an 8051 C++ compiler, you should speak directly to the people at Keil and/or Ceibo and see if you can negotiate terms on a suitable evaluation...

Also, Hitex used to offer short-term licences for the full Keil toolchain (still C-only, remember) - I don't know if they still do; you can ask them:
http://www.hitex.co.uk/

 hopeless issue

hopeless issue

if (s)he does not understand the difference between C and C++ what will the next question be?

Of course, is a major fault of the '51 that is is good at what it is designed for and not for what the OP wants. YES, fault of the '51, not 'fault to the toolmakers', trying to make the '51 execute C++ bloatware is even more ridiculous than supporting function pointers/malloc etc. At least they (except ceibo) stopped there.

The ceibo product is NOT a C++ compiler, it is a C++ to C converter.

Erik

 RE: hopeless issue

Looks like I'm not getting through to you here!

How many projects of this type have you done?

Quite a number of people on this forum have made quite a number of similar projects - each.

Are you really sure that it is you who isn't going through to us, and not the reverse.

As I already said in an earlier post. You are the kind of person who repeats a question until someone gives an answer you like. If the answer is wrong, is not important. When you hear the answer you like, you will go ahead.

Right now you are standing at the edge of a deep gorge. People are suggesting that you should step away from the edge, but since you like the beautiful red morning sky on the other side of the gorge, you are waiting until someone suggests that walking into the sunrise is a good idea.

Are you using your real name for these posts? Are you working on getting a wikipedia or Oxford English Dictionary entry with your name on it?

Maybe you want "define: stupidity" on google should give a link to this thread?

Hard words? Well, it is better if we use some very explicit words now, before you have started your doom project. Right now, it is only a question of lost face. A couple of weeks or months from now, it will be a question of quite a lot of lost money and significant customer badwill.

 The jar for sarcasm remains open!

"Where is the requirement that the programming language used must be C++ ??"

I'm a C++ programmer. I write programs in C++. If I am to write a program, then the optimum path will be in C++.

 RE: The jar for sarcasm remains open!

"I'm a C++ programmer. I write programs in C++."

What sprang to mind when I read this was:

I think C++, therefore I am C++.

 RE: The jar for sarcasm remains open!

I'm a C++ programmer.

In that case, you should also know C, since it is a subset of C++.

And even if you don't know C - if you really are a programmer, you should be able to learn it in a few days. Otherwise, you're just someone who writes code.

If I am to write a program, then the optimum path will be in C++.

... and if you have a big enough hammer, every problem will look like a nail, right ?

A programmer should know that there is such a thing as "the right tool for the job", and be able to select the right tool and learn to use it.

Would you do web development in C++ (instead of php or perl) ?
Would you program a DSP in C++ (even though the compiler doesn't know 60% of the instruction set and will therefore produce abysmally slow code) ?
Would you program huge numeric simulations in C++ (instead of Fortran) ?
Would you program an operating system in C++ (instead of a mix of C and assembly) ?
Would you program a portable web application in C++ (instead of Java) ?
Would you program a customizable game UI in C++ (instead of LUA) ?

C++ is not the right tool for the job "Write a program for an 8051".

 RE: The jar for sarcasm remains open!

I have produced at least 7 digits of C++ code lines, so I like to think of myself as a C++ programmer.

I would not try a C++ program on a '51, because I know enough of C++ and the '51 architecture to know that it would not be advantageous to me - or to a customer.

Exactly how much embedded programming have you done? Do you really have enough experience that you can afford to ignore unanimous comments pointing in a different direction?

Are you willing to post your customers contact information here - so we can get in contact with them when they need a new supplier of the product? Right now, you are not heading in a direction what will lead to a working product.

Being a consultant means that you have to spend a significant time listening. First listening to the customer requirements. Then listening if there are existing solutions that can result in short development times and a well working product. Then listening to the feedback of the end users, so that you can suggest how to improve the product.

Were you as "goood" at listening to the customer requirements as you are at listening to the suggestions you receive here?

 Something doesn't add up here

Ok,

The general view from this forum is that C++ an the 8052 don't mix.

Well, why do Ceibo have a product to do what you have been saying is not suitable?

I assume that they do have customers for such a product otherwise they would be out of business - Right?

So either they are wrong or you are wrong.

I think it is the product to try. It's just that I think the cost is too much. Maybe I won,t be able to afford such a big turkey this year ;)

 RE: Something doesn't add up here

Well, why do Ceibo have a product to do what you have been saying is not suitable?

Because there is a demeand from 'customers' that do not know better

Based on your posts I am confident that you have no idea of the '51 architecture (VERY fastidious statement: real programmers do not care about such details) so, to you, the '51 is "just another processor that you do not need to know".

This has nothing to do with C++, but with "real programmers". I was asked to help on implementing code banking (allowing a '51 program to be more than 64 k) by a company that had hired "real programmers" who, of course, started out with a 'great' OS and multitasked even the simplest operations. I had a look and redid the whole shebang to working code that fit in 8k.

there is no universal language, there is no universal processor some companies make money from those that believe it is so. And eveidently that will happen again. Have fun till you see your mistake.

Erik

 Jumping to conclusions

"Well, why do Ceibo have a product to do what you have been saying is not suitable?"

Why do people who never drive outside the city limits have 4x4s?
Why do people fit spoilers to cars that cannot possible reach a sufficient speed for them to be of any advantage?
etc, etc...

I think you'll find that Ceibo is the only C++ product for the 8051, whereas there are many C compilers (some not even full ANSI) for the 8051 - that fits very well with the general opinion that C++ is not generally suitable for 8051 products.

"I assume that they do have customers for such a product otherwise they would be out of business - Right?"

Not necessarily: the 8051 C++ is not their only product - maybe not even a major product for them.

"Maybe I won,t be able to afford such a big turkey this year"

Buy an 8051 C++ cross-compiler - you might find that you do have a big turkey...

;-)

 RE: Something doesn't add up here

"Ok,

The general view from this forum is that C++ an the 8052 don't mix."

Filip,

Their real statement is somewhat more basic than that, but may not quite have gotten through. When you're programming for an "embedded" processor, various assumptions that are easy-to-make and almost guaranteed to be "correct" in a desktop environment cease to make any sense. Imagine this situation: Someone could have an 8052 based system that has all of the following:

1. A large LED bar sign that can scroll text
2. A small LCD display
3. A serial port

All of these bits of hardware could be considered the "console" referred to by cout. Which one is appropriate? Further, what code should be generated to control one of them when you use "cout <<"? These are the kinds of things that have to be considered in an embedded project.

I will make a prediction: If you buy the Ceibo package, it will have no idea how to compile "cout <<" unless you customize some library or at least tell it in detail what type of display and controller chip are attached to your board and where.

-Jay Daniel

 So it wasn't a requirement, then.

"I'm a C++ programmer. I write programs in C++. If I am to write a program, then the optimum path will be in C++."

Ah - so it's not a requirement that the code be C++, then?
That is just your preferred implementation

Although using the language that you know (C++) could well be the quickest route to get the code written, it may well not be the "optimum path" for the overall project:

eg, if you write C++ code (especially if you write it as you write for a PC), you can easily end up with grossly inflated memory requirements - which will increase the cost of each unit shipped.
If you're only going to ship a few units, this probably won't matter; but, if you're going to ship millions, it would probably be better for the overall project to spend the extra development time writing lean-and-mean code (probably in C rather than C++; possibly even in assembler) and save on the cost of each and every unit shipped.

On the other hand, if the target hardware is already defined, you are going to have to work within its available parameters - which may or may not be sufficient for an application written in C++...

 RE: So it wasn't a requirement, then.

You are the type of guy who decides that if something exists, it must be good and should be used.

You would want Vista in your mobile phone, just because Vista is the latest and greatest from M$.

TV Shop has a huge number of products that exists, but are no good. The world is full of products that exists because it is possible to make them, not because they solve a problem people want to have solved. Not because they actually works.

You can emulate DirectX in software - without any 3D hardware. Such functions exist. Does that mean that it is a good idea to try a firt-person-shooter game without a 3D graphics card? Do you really think it will work well with 0.1 frames/second?

A company may have invested a lot of time into a number of thousand lines of very complex C++ code that they just desperately has to convert to the '51 environment. In that case, it might be an idea to make a one-time conversion from C++ to C and then manually clean up the code to normal C, block by block. I say may - but only if the C++ front-end generates C code that is possible to maintain on it's own.

Why do I get the feeling that you are carefully avoiding the qustion about any existing knowledge of embedded development?

 Two ears, only one mouth...

"either they are wrong or you are wrong"

Of course, it's not as simple as that!

Every rule has its exceptions, and every market has a niche where the specific conditions mean that the general rules require a different interpretation.

You came here without even understanding that there is any difference between C and C++ - do you not think that there are probably plenty more issues of which you are not (yet) aware, but of which others here will have extensive experience...?

As Per says, "Why do I get the feeling that you are carefully avoiding the question about any existing knowledge of embedded development?"

 Snake Oil

"TV Shop has a huge number of products that exists, but are no good. The world is full of products that exists because it is possible to make them, not because they solve a problem people want to have solved. Not because they actually works."

Have you never heard the term, "Snake Oil"...?

http://en.wikipedia.org/wiki/Snake_oil

 Wehowaaa - Limited views

You guys REALLY don't get it!

I've now noticed that IAR produce a C/C++ compiler for the 8051.

So that's two products I've found that do what you people say shouldn't be done!

Someone in those companies must have seen an opportunity to fill the need for C++ on the 8051.

Maybe, just maybe, for some projects it would be a quick way of getting the job done.

I'll have a look on the IAR forum. Who knows, it may even have people on that one who have slightly less narrow minded views.

 RE: Wehowaaa - Limited views

Someone in those companies must have seen an opportunity to fill the need for C++ on the 8051.

I think you don't understand what companies do.

Companies don't exist to fill needs.

Companies do exist to make money, by making products that there is a market for. It does not matter whether the product is necessary, useful or sensible. The only thing that matters is that there are people who will pay for it (or that can be talked into paying for it). In fact, there are many, many necessary, useful and sensible products that do not get made because there aren't enough people that can pay for them.

Maybe, just maybe, for some projects it would be a quick way of getting the job done.

If you had read this thread, then you would have already seen a mention of the one scenario where such a compiler makes sense - when there is an existing, large code base that needs to be run on an 8051 without porting it to a more appropriate language.

Also, you could already be halfway done with your project if you had taken advice from experienced embedded developers, instead of arguing with them. Or at least you could have read the specs of your hardware. Simply using cout and expecting text to magically appear on your display makes me believe that you expect your 8051 to work like a PC. It doesn't.

Who knows, it may even have people on that one who have slightly less narrow minded views.

"I know only C++, so any problem must be solved in C++" isn't narrow-minded ?

All the other people on this thread also know C++. They know C. They know assembly. They know the hardware architecture of the 8051. They have a broad perspective and know that and why C++ is not the right tool for simple 8-bit devices.

Anyway, good luck at what you're trying to do. You'll need it.

 RE: Wehowaaa - Limited views

You seem to think that C++ with virtual methods is good. The 8051 chips hates function pointers, and a virtual method is a form of a function ponter.

You seem to think that object-orientation with dynamically created objects is good. The 8051 has too little memory to work with dynamic memory. Even if you can implement it, you run a large risk of failing because of memory fragmentation. So forget new/delete.

You probably haven't realized that the '51 chips are TRUE 8-bit chips. They are not 16-bit chips with an 8-bit bus like the 8088 was on the original PC, more than 20 years ago. The register size is smaller than the short or int data types, so you don't have atomic add/sub/mul/div. How much code do you think a software div contains?

The processor doesn't have a file system, so forget about file streams.

The target doesn't have an OS, and the processor are just minimally able to host a minimal OS. So forget about threads or tasks.

There is no driver layer. Every single hardware peripherial needs bit-fiddling code to function. Code written by you. Or written and uploaded by narrow minded old fools who doesn't know that C++ has come to town.

The processor contains true boolean variables. But the variables are not actually boolean true/false, but actually on/off.

The processor requires special language extensions for tagging of variables to inform in which memory areas they should be stored.

The application has to settle for using a subset of the C runtime library. A huge number of the C library doesn't make sens. A even huger part of the C++ standard libraries makes sens - or can even be used - on a '51 platform.

You have no experience of embedded development, but instead of listening, you think everyone is narrow-minded.

You are the drunk who stands on a rooftop and claims you can fly.

The problem is that you claim that you know C++, but your posts gives very clear indications that you do not actually know so much about C++. You do not seem to know what makes C++ ticks - what it looks like under the hood. For embedded programming on this scale, you have to know the inner workings. Programming on a macro scale does not work.

So you get a C++ compiler. You then have to use the C++ compiler to write a mostly C-ish program, because most of the C++ concepts and libraries are not available. Who do you expect to fool with that?

You have still totally missed the point. The people who are on this forum have already got things done. We are not arguing based on "maybe" or "i like to" or "it would be good to". We are arguing based on existing products available all around you. Real, physical, working factory-produced products.

 RE: Wehowaaa - Limited views

"Companies don't exist to fill needs."

What a cynical view of life!

Ok, Mr Henry Ford wanted to make money but part of the dream was to give transport to the masses.

Part of marketing is understanding what people want!

I want to use C++ because I know C++.

I say that in the same way that I said I want a response in English. It is because I talk English!

To do something you are familiar with is quicker than doing something totally foreign.

 RE: Wehowaaa - Limited views

To think knowledge in one area of life is directly applicable to other areas of life is not faster. It's just plain dumb!

Not knowing the relationship between C and C++ questions your C++ knowledge.

To think companies focuses on customer needs instead of what makes money is naive.

Have you picked up the phone and called IAR? Do they recommend C or C++ for a '51 target? Have you asked how much of the C++ concepts and libraries you can actually use?

Have you prepared critical questions to ask them, or do you make your neck as long as possible and tells your suppliers: please put a noose around my neck - I'm gullible?

This isn't about what you know - but what you don't know. If you focus your life around what you know, you will never grow. Right now you are a man with a hammer, desperately seeing everything as a nail.

Please define narrowminded...

 I wrote PART

I said PART of marketing
I said PART of the dream

Surely you would agree that it is always better to build upon what you know rather than always going for something different.

A skyscraper is built of same style blocks one upon another. If they were all different then the structure almost certainly wouldn't stand!

I do not need to define narrow minded - Just use your favourite search engine.

In this instance, dismissing C++ out of academic principal I would say is narrow minded.

 Academic ?

In this instance, dismissing C++ out of academic principal I would say is narrow minded.

Hello ? The other posters on this thread are experienced embedded developers. That means they have already written code for real-life projects that are being sold on the market. Their views and opinions stem from years of practical, hands-on experience with the 8051 architecture.

The person who has a purely academic point of view is you.

 READ THE POSTS

In this instance, dismissing C++ out of academic principal I would say is narrow minded.
NOBODY has "dismissed C++ out of academic principal" many have "dismissed C++ out of knowledge of the architecture of the '51"

Erik

 RE: READ THE POSTS

NOBODY has "dismissed C++ out of academic principal"

I think that this is just a paraphrase of:

NOBODY has ever dismissed goto out of academic principal

 RE: READ THE POSTS

Exactly what has goto with C/C++ to do?

 RE: READ THE POSTS

Exactly what has goto with C/C++ to do?

Refer to the 'Using goto in C/C++' debate.

So many people dismiss the use of it through academic belief and immediately preclude it's potential advantages.

FYI, I was likening it to the attitude I received concerning C++ on 8051 based embedded systems.

 Off track - Sorry

"I do not need to define narrow minded - Just use your favourite search engine"

Just tried doing a search for that on my favourite search engine and got nothing!?

Trouble is, my favourite search engine is http://www.booble.com ;)

Maybe you should have been more specific.

 RE: Wehowaaa - Limited views

Part of marketing is understanding what people want!

Of course. I would even say that all of marketing is understanding what people will want to buy, or what they can be made want to buy. It is all about business - if people will pay for it, then is is economically sensible for a company to make.

That, of course, does not mean at all that the product has to be technically sensible. What the customer does with the product does not concern the company, as long as they get paid.

I want to use C++ because I know C++.

We've already discussed this: If you know C++, then you also know C (if you do not know C, please stop claiming that you know C++).

I say that in the same way that I said I want a response in English. It is because I talk English!

I am sorry, but the hardware you have to work with isn't going to accomodate your wishes. Humans have this capability called "learning", while your hardware can only be used as-is, or replaced completely.

To do something you are familiar with is quicker than doing something totally foreign.

The concepts of C++ are totally foreign to your 8051. That is precisely why is does not make sense to try programming it in C++.

 offer to help

sir filip

you be needing project work soon?

i help you please

i say send info and i see what to do for work

if working c then you think be happy yes??

 RE: offer to help

I do not need to define narrow minded - Just use your favourite search engine.

I know what it means. I'm just very curious to know what you think it means.

It is an academcial goal to use as high-level language as possible for all development. It a practical rule to not use a higher-level tool than the target can handle in a good way. You call our arguments academical???

Many of us _are_ experienced C++ developers, which is something you seems to constantly ignore.

Don't you wonder just a little bit why I claim to be an experienced C++ developer, and still says that C is a better language to use for a '51 chip?

Don't you get a feeling that there _may_ be parts of the equation that you haven't seen yet?

How long was it since you left school?

How many real projects (embedded or not) have you worked with?

Haven't you noticed that real projects tend to have a large number of mutually exclusive requests - something that didn't exist in school assignments. In real projects, you always have to compromise!

 RE: offer to help

I noticed the following comment upthread:

As I have said before: The problem you are going to run into if you use the Ceibo + Keil combination is that the evaluation version of Keil C51 only allows a code size of 4 kB. Any complex string formatting function (this includes printf and cout) will easily need upwards of 10 kB code space.

Compiling the following program with a recent version of C51:

#include <stdio.h>

void main(void)
{
   printf("Hello world\n");

   while(1);
}

Gave the following map:

BASE        START       END         USED      MEMORY CLASS
==========================================================
X:000000H   X:000000H   X:007FFFH             XDATA
X:000000H   X:000000H   X:007FFFH             HDATA
C:000000H   C:000000H   C:007FFFH   000438H   CODE
C:000000H   C:000000H   C:007FFFH             CONST
C:000000H   C:000000H   C:007FFFH             ECODE
B00:0000H   C:000000H   C:007FFFH             HCONST
I:000000H   I:000000H   I:0000FFH   000001H   IDATA
I:000000H   I:000000H   I:00007FH   00001CH   DATA
I:000020H.0 I:000020H.0 I:00002FH.7 000001H.1 BIT

And in particular:

000003H   00035EH   00035CH   BYTE   UNIT     CODE           ?PR?PRINTF?PRINTF

Which shows the original statement to be out by more than an order of magnitude.

Presuming the person who made this statement is reasonably familiar with C51, how are we supposed to have any confidence in the commentary on the unsuitability of C++ when it would appear that none of the contributors have actually used any of the available implementations? Should we assume that their 'experience' really is sufficient?

If I am wrong in my assumption that none of the contributors to this thread have used C++ on an 8051 please do correct me. If you can provide any actual data to support the hypothesis that C++ is a non-starter on an 8051 I would be genuinely interested.

 At last - An unbiased viewpoint

Jack,

Finally someone responds with a positive point of view :)

Up to that time all responses have been leaning towards the "I know better than you because I've got experience" style.

What there seems to have been lacking is the desire to try something that they are unfamiliar with.

The words new, dog, tricks and old in a different order seem to be appropriate for some here.

 RE: At last - An unbiased viewpoint

Note that JS showed an example saying that the Keil C compiler + linker (the buggy tool you have been recommended to use) is quite good.

That should not be extrapolated into believing that the '51 is a processor well suited to C++.

There is still problems with dyanmic memory, virtual methods, templated code etc.

 Incorrect extrapolation (on your part)

I did not say, nor have I assumed, that the 8051 is well suited to C++.

I am hoping (and increasingly believing) that it CAN be successfully used.

Some investigation I have done has revealed that there is even a Java VM that runs on a derivative (the Dallas 80C400).

Java is interpreted, C++ is compiled. Both have the problems that you mention.

So if (yet another) supplier provides tools for such a high level language to be used, it implies that there are requirements that can be satisfied with such tools.

 RE: Incorrect extrapolation (on your part)

"Some investigation I have done has revealed that there is even a Java VM that runs on a derivative (the Dallas 80C400)."

True.

"TINI is available online at TINI Store for $67.00 which includes 1 MByte SRAM and 512 KBytes of Flash ROM."

Tiny footprint...

 Java vs C(++)

At this point I can contribute some real-life experience.

I have developed a couple of applications using Java on the Dallas 80C400 - Their name for the technology is TINI.

I had previously done a lot of work (more than 15 years worth) primarily in assembler and C on 8051 and V55 cores.

TINI was my first attempt of using such a high level language on the 8051 derivative (albeit a vastly souped-up one).

The result - The projects were written in time, to cost and within the constraints laid down by the hardware.

Fortunately, they were not time critical applications and they performed their function adequately and (most importantly) within specification requirements.

Then came another project.

The management wanted me to use the same basic platform; i.e., the 80C400 with TINI. Knowing what the project entailed, I was reluctant to us TINI on this project but I had my orders and decided to go along with the decision.

It very quickly became apparent that the setup just was not man enough for the job. I decided (unknown to the management at that time) to rewrite the application in C.

The result was that the application ran some 400 time faster in various critical sections than the equivalent TINI code. Yes, I do actually mean 400 times faster!

Fortunately (for me), the management agreed that I had made the right decision.

So ... my advice is this:

Yes you CAN consider and use C, C++, JAVA or any other high level language, but please also consider whether the resultant application is going to work in a satisfactory and acceptable manner for the customer.

 So it can be done

Ok,

It's becoming clear that I can write on the 8051 in C++.

It may be inefficient code and need more resources than code which others write. But if I can write an application quickly with the confidence brought about by using tools I know then it should be worth the wrath of some forum members.

I don't understand why there are some guys that are so negative about certain suggestions.

 RE: So it can be done

"I don't understand why there are some guys that are so negative about certain suggestions."

Trying to compile C++ with a C compiler:

I,ve installed the Compiler and I can,t get even
the simplest code to compile properely.

Anyone know where the fix for this bug is?

On receiving an answer that it is a C compiler:

Can someone answer my question in English please!

On experience with embedded compilers:

Why is the demonstration version so limited? It
looks very weak! Microsofts free compiler can do so
much more!

On receiving a good description of the problem, a note that the M$ compiler can't build for the '51 target, and that the C51 can't build C++ and that a trivial change to the code (to make it C code) would make the example buildable:

Someone give a more positive (and helpful)
response please!

After having received a number of descriptions that C and C++ are different languages:

Why have a demo version that won,t compile my
simple program?

After receiving a further note that C and C++ are different languages, and that a C compiler just can't compile C++:

Anyway, I need to know of alternatives and not
just get you can,t do it style comments.

On the question: Can't you switch to C? Do you really need C++?

You make these comments without knowledge or
appreciation of the requirement.

My contract requires me to produce code for an 8052
controller board that has a keypad and a display.

I need serious options please.

This implies that the chip 8052, or the keypad or the display is a direct implication why C++ is a requirement and not an option. It also implies that the answers you have received are not serious.

After receiving a number of notes that C++ are not the best of languages for the lowest end of microcontrollers, you translate unsuitable into impossible:

The general view from this forum is that C++ an
the 8052 don't mix.

From then on, it's not meaningful to follow the thread anymore.

As you can (probably not) see, you entered this thread in a very narrow-minded way. The perfect way of entering a forum and ask questions...

 RE: So it can be done

It's becoming clear that I can write on the 8051 in C++

It's becoming clear now ? I mentioned that there are C++ compilers (not free, neither beer nor speech) in my posting yesterday. Along with the fact that Keil C51 is not a C++ compiler, and that what you considered a "bug" was actually a lack of reading and understanding the documentation.

It took a while to get through ?

 RE: So it can be done

It's becoming clear that I can write on the 8051 in C++.

No. It's become overabundantly clear that you believe you can use C++ on an 8051. Now that was pretty evident from the beginning, but that didn't keep you from stressing this point at every opportunity.

But if I can write an application quickly

If you can do it. But there has been negligible evidence that you really understand the task you're so convinced you're capable of completing. Instead you blame every failure of your attempts at implementing your ideas on others --- the tools, their makers, the people in this forum. Something and somebody must obviously be faulty, incompetent and/or "academic", as long as you can deny it might be your fault. In my country this attitude is usually summarized by an old adage: If the farmer can't swim, his swim trunks are at fault.

with the confidence brought about by using tools I know

... except that you rather evidently don't know the tools relevant to the job at hand.

then it should be worth the wrath of some forum members.

You're mistaken if you think what's being directed at you qualifies as wrath. It's more like commiseration, for now.

I don't understand why there are some guys that are so negative about certain suggestions.

Indeed, you don't understand. But you're wrong about what it is you don't understand. You utterly fail to grasp the idea that people telling you that your suggestions are bad might be doing so not because they're "negative", but because their experience taught them.

While pretending to ask a question, you really came here with a prejudice expecting people to provide arguments supporting it. But then something happened that you hadn't contemplated before: people gave you answers that disagreed with your pre-set opinion. Well, guess what, that's one of the consequences of asking a question: you lose the right not to have to listen to answers you don't like.

Wisdom comes not from asking questions, but from actually listening to answers.

 Great C, but not C++

The problem you are going to run into if you use the Ceibo + Keil
and you reply

void main(void)
{
   printf("Hello world\n");

   while(1);
}

where does the Ceibo C++ come in, in the above mr smokied sardine

Erik

 RE: Great C, but not C++

The problem you are going to run into if you use the Ceibo + Keil
and you reply

void main(void)
{ printf("Hello world\n");

while(1);
}

where does the Ceibo C++ come in, in the above mr smokied sardine

Oh dear, here we go again.

I quoted two sentences as follows:

As I have said before: The problem you are going to run into if you use the Ceibo + Keil combination is that the evaluation version of Keil C51 only allows a code size of 4 kB. Any complex string formatting function (this includes printf and cout) will easily need upwards of 10 kB code space.

You snipped this down to half a sentence:

The problem you are going to run into if you use the Ceibo + Keil

Thereby removing all the content I was actually replying to.

You then quoted part of my response, this time snipping out all the text that gave meaning to the code snippet.

Go back and read my post again. If you still do not understand it let me know and I will explain it to you in whatever level of detail is necessary.

 RE: Great C, but not C++

Go back and read my post again. If you still do not understand it let me know and I will explain it to you in whatever level of detail is necessary.

I do not give a hoot about your post, the subject of this thread is NOT that printf works in C, which we all know, but C++ on the '51.

Erik

 RE: Great C, but not C++

Erik,

I think in this case you really have missed Jack's point. He was showing the m51 file to indicate the using printf() in Keil didn't increase the code by 10kB, but rather by 1kBish which was an order-of-magnitude less "badness" than the original statement. It had nothing to do with C++, but was just continuing illustration of what he sees as bad in the responses on this forum -- namely that sometimes the estimates people provide from experience can be exaggerated and overly-emphatic.

Also, just as a point of reference for your future usage: The name he's chosen (Jack Sprat) doesn't have anything to do with sardines. It's from an old nursery-rhyme (though I don't know it's origin) that begins like this: "Jack Sprat could eat no fat. His wife could eat no lean."

-Jay Daniel

 RE: Great C, but not C++

Also, just as a point of reference for your future usage: The name he's chosen (Jack Sprat) doesn't have anything to do with sardines.

I know that, but sardines are canned :)

Erik

 Incomplete analysis?

"[Jack Sprat] was showing the m51 file to indicate the using printf() in Keil didn't increase the code by 10kB, but rather by 1kBish"

But did it show that?

It showed that the size of ?PR?PRINTF?PRINTF is 1K-ish, but it doesn't consider what other stuff may also get pulled-in as a result of having printf that wouldn't other wise have been included.

I haven't had the time for a detailed look at the map file, but the summary line from building a simple "Hello, world" example as shown indicates that the total CODE space usage is on the order of 2K...

It probably also varies with the Memory Model chosen...

So: still not 10K, but it certainly does show that a simple printf can easily use up virtually the whole CODE size limitation of the Evaluation version...!

 RE: Incomplete analysis?

I haven't had the time for a detailed look at the map file, but the summary line from building a simple "Hello, world" example as shown indicates that the total CODE space usage is on the order of 2K...

A quick glance would be sufficient to spot the following line:

C:000000H   C:000000H   C:007FFFH   000438H   CODE

Which shows the total code size to be 1080 bytes.

 RE: Great C, but not C++

I do not give a hoot about your post, the subject of this thread is NOT that printf works in C, which we all know, but C++ on the '51.

As usual you are commenting on what you would like me to have said, or what you imagine I have said, rather than what I actually have said. If you had the wit to read and understand my post you might be able to make some sort of sensible contribution.

I'm quite happy for you to criticise anything I write on this forum, but please don't keep muddying the waters by criticising things I haven't written. It wastes even more bandwidth than I already expend trying to get you to stick to the facts.

 RE: Wehowaaa - Limited views

Ok, Mr Henry Ford wanted to make money but part of the dream was to give transport to the masses.

You do know about the dodge lawsuit, right? He was forced to continue to seek profit rather than divert it into more production to "help the masses." His dream was overrode by profit demands of being a corporation.

 RE: Wehowaaa - Limited views

I want to use C++ because I know C++.

Sure, but be honest and say "I have no idea of anything else, if C++ is right for this job or not does not matter"

NOW DO ANSWER have you ever done ANY small embeeded before, we all know that the answer is 'no' but it would be nice to hear it from you.

Erik

 Limited C++

"I've now noticed that IAR produce a C/C++ compiler for the 8051."

Note that it's not a full C++ Compiler - it's a version of Embeddeded C++

"Embedded C++ offers a subset of C++. It excludes size and/or speed consuming C++ features that are not relevant for embedded systems.
Embedded C++ lacks the following features of C++..."
For more, see http://www.iar.com/p7371/p7371_eng.php

I don't know how much that might "cramp your style" if you're used to a full-blown C++ compiler...

 RE: Limited C++

I don't know how much that might "cramp your style"

I'll get my own bias out of the way first: "Embedded C++" was really a political move. It was created by (in my opinion) a bunch of lazy compiler vendors. C++ is a bitch to compile at all, much less do a good job. And a lot of people simply didn't want to try. So, "Embedded C++" is really more about excluding newer and/or more difficult to compile features, rather than any real concern over "efficiency" or appropriateness for embedded programming. (Modern C++ compilers efficiently implement just about all of the features EC++ excludes.) That's just the excuse by which the limitation was sold.

Besides, even if feature X were harmful in embedded programming, you could simply not use it. (Compare with, say, bitfields in regular C -- widely regarded as not worth the effort and unused. That doesn't mean we need an "Embedded C" standard officially excluding it to give the marketing guys an excuse...)

On to details, from the IAR website, though I've inserted numbers for reference:

Embedded C++ lacks the following features of C++:

1) Templates
2) Multiple inheritance
3) Exception handling
4) Runtime type information
5) New cast syntax (operators dynamic_cast, static_cast, reinterpret_cast, and const_cast)
6) Namespaces

7) The Standard Template Library (STL) is excluded
8) Streams, strings, and complex numbers are supported without the use of templates
9) Library features which relate to exception handling and runtime type information (headers <except>, <stdexcept> and <typeinfo>), are excluded

(1), which implies (7), is critically limited to a "real C++" programmer. There's nothing inherently bad about templates. Poor use of them can bloat your code. But then, poor use of #defines can bloat your code, for much the same reason. That's a problem with the programmer, not the language feature.

(2) exists for a very specific reason in the real world. If you're an academic OO purist and you always have full source for every scrap of your project, you sneer at MI. If, on the other hand, you ever use a commercial library as well as writing your own code, you're often faced with the problem of inheriting from two separate trees of objects. MI is the onlly answer. It's also quite useful in some specific idioms, such as the mixin or the "abstract base class" -- what Java calls an "interfere" and which they added back in after their single-inheritance OO purity proved impractical.

(3) Pretty darn useful in an embedded system to make sure everything gets cleaned up with things go wrong. A robust system in EC++ is just going to have to reinvent this wheel from scratch, and won't have the power of a language feature. Early implementations could be bloated and slow, but compiler vendors learned how to implement it and programmers learned proper idioms like RAII for its use.

(5) Pure bias against new features as far as I can tell. If you do away with RTTI, then dynamic_cast does you no good. But the other three are just the three uses of traditional C casts, and there's no reason from the compiler vendor's point of view that they're hard to support. The only difference is that the syntax makes the programmer's intent obvious, where "(typename)" is sometimes too powerful for your own good. Like I said, lazy compiler vendors.

(6) An incredibly useful feature for anything more than the simplest program. One of the biggest gripes about C was always its lack of depth in structure: you're either static and hidden, or public and completely global. Hence the development of coding tics like always putting Module Code Abbreviations in mca_MyFunc() to try to avoid clashes in the global namespace, and conventions about _symbol and __symbol to hide stuff needed in your libraries. Those are just a poor man's attempt to create namespaces that clutters the code because they don't have proper language support. Again, the feature is not at all hard to implement, but it was newfangled at the time and the lazy compiler vendors strike again. They didn't already have it working at the time they defined the EC++ spec, out it went, baby and bathwater alike.

(8) OMG! A feature you can actually argue is not terribly useful in the majority of embedded work. But then, it also falls squarely under Stroustrup's "don't pay for what you don't use" principle. If you don't use the complex type or a string, why then, you won't link in any of libraries, would you? Wouldn't cost a thing for people that didn't need it. (Did I mention I find the EC++ backers extremely lazy?)

 RE: The jar for sarcasm remains open!

I'm a C++ programmer. I write programs in C++. If I am to write a program, then the optimum path will be in C++.

You probably want it to be the optimum path. But like most C++ programmers with poor C background you probably have no idea what a C++ application does to the system it runs on. My advice to you: Do not use C++ on an 8-bit micro as long as you do not exactly know what the result is going to be. You are now on an embedded system, so try to look at problems not only from the top level.

 RE: what compiler you install ???

void main(void)
{
 printf("Hello world!");
}

This is a "C" Compiler not a "C++" Compiler.
And no they are not the same thing.

 RE: what compiler you install ???

Interesting fact:
When clicking on 8051 and looking at language standards, Embedded C++ is not mentioned. Only C.

When clicking on LPCxxx and looking at language standards, both C and Embedded C++ is mentioned.

Forget me for being stupid, but might a vendor who already have C and C++ support (even for 8-bit processors such as the Atmel AVR series) have considered the '51 chips not suited for C++ development?

Now, that would be shocking...

 Bizarre

Ok,

At the start I didn't realise about the precise differences in product capabilities.

But (contrary to some posters belief) I've learnt some things.

I now know that not only is C++ available it can also be practical.

What I find most bizarre is the attitude of some posters of this thread who assume to know what my precise requirements and desires are.

They then start bickering on about how limited Embedded C++ is etc etc etc.

Remember people, C is even more limited!

It is (and should always be) a case of using the tools that are most appropriate for the situation.

To those who have been helpful, I thank you.

To those who have been otherwise (and I would think you know who you are), stay in your box.

 RE: Bizarre

I now know that not only is C++ available it can also be practical.

Did you try it out yourself, or did you conclude it from the advertisements of the compiler makers ?

What I find most bizarre is the attitude of some posters of this thread who assume to know what my precise requirements and desires are.

If you had asked the question

"I want to program an 8051 and I want to do so in no other programming language than C++, please tell me which compiler to use.", this thread would have been about three or four postings long.

But you seem to prefer to keep everyone in the dark and guessing.

You also seem to like pseudonymous posters with a disposition to trolling more than people who actually post under their real name.

I believe you actually came here for fun instead of advice. Some people like ... heated discussions. Was it fun so far ?

 My final thoughts on this issue

"Did you try it out yourself, or did you conclude it from the advertisements of the compiler makers ?"

I have now downloaded, installed and successfully compiled a couple of simple C++ programs.

FYI, at the start of the thread I was (as I admitted) not aware of the nuances. I could not have been as precise as you think I should have been. But I have had a busy 24 hours and I think learnt a lot.

Heated discussions. Hmmm. I think an individual text area for a message is not long enough to describe my thoughts concerning some of the responses I have had on this thread.

Fun is definitely not a word I would use in this context!

 RE: My final thoughts on this issue

FYI, at the start of the thread I was (as I admitted) not aware of the nuances.

Where did you admit to not knowing about the "nuances" between C and C++? As I read it, you expressed quite a lot of explicit irritation that you didn't got the "correct" answer.

Users with meaningful questions and reasonably polite behaviour do almost always get meaningful responses, and mostly in a polite way. The only irritating answers I use to see is a bit high percentage of bold-faced RTFM, which I think is too hard an initial answer and better reserved for repeat offenders. But people do get reasonable answers. If they expand their queries with more followup information, the answers are expanded to be more precise.

If a poster breaks his back to rub everyone backwards and complaining about stupid answers - because the answer wasn't the expected - then threads do go down the drain. You really entered this thread narrowminded and with a huge amount of attitude. Are you surprised at the outcome?

 Admission?

"Where did you admit to not knowing about the "nuances" between C and C++?"

He did finally admit it - Posted 20-Jun-2007 01:28: "At the start I didn't realise about the precise differences in product capabilities."

But that was after 2 days and several dozen posts of vehemently refusing to hear it!

Even now, he still doesn't seem to have grasped that the difference lies in the fact that C and C++ are different languages - it's not just a matter of "precise differences in product capabilities"!!

 RE: My final thoughts on this issue

FYI, at the start of the thread I was (as I admitted) not aware of the nuances.

The fact that you still call the difference between two separate programming languages a "nuance" is rather strong evidence that you're still just as unaware.

 RE: Bizarre

You also seem to like pseudonymous posters with a disposition to trolling more than people who actually post under their real name.

I was merely trying to point out the fact that 'experience' does not necessarily equal knowledge. You just happened to be the one who posted a particularly good example.

I'm curious - did you just pick a number out of thin air to try and make a point, or did you actually believe that printf() was at least 10k of code?

 RE: Bizarre

The interesting thing with printf - and you can see examples of it if you search this forum - is that the Keil tools are good at analyzing how you use it.

printf() can require linking of more or less code. In this case, you didn't actually perform any "formatting", so you got a minimalistic overhead.

The concept isn't new. Old MSDOS developers probably remember TurboC that constantly failed to print floating point numbers unless at least one floating point math function where referenced in the source. The MSDOS linkers didn't have enough information to know what formatting parameters that was used by printf.

 RE: Bizarre

The interesting thing with printf - and you can see examples of it if you search this forum - is that the Keil tools are good at analyzing how you use it.

printf() can require linking of more or less code. In this case, you didn't actually perform any "formatting", so you got a minimalistic overhead.

You think so?

Integer formatting:

#include <stdio.h>


void main(void)
{
   int d=1;

   printf("Hello world %d\n",d);

   while(1);
}

000003H   00035EH   00035CH   BYTE   UNIT     CODE           ?PR?PRINTF?PRINTF

No formatting:

#include <stdio.h>


void main(void)
{
   float f=1.0;

   printf("Hello world\n");

   while(1);
}


00051BH   000989H   00046FH   BYTE   UNIT     CODE           ?PR?PRINTF?PRINTF

Floating point formatting:

#include <stdio.h>


void main(void)
{
   float f=1.0;

   printf("Hello world %f\n",f);


   while(1);
}

00051BH   000989H   00046FH   BYTE   UNIT     CODE           ?PR?PRINTF?PRINTF

Doesn't seem to be much analysis going on there.

 RE: Bizarre

"Doesn't seem to be much analysis going on there."

There is obviously sufficient analysis going on to allow it to omit a load of stuff if the program uses no floating point.

Presumably, if the program contains floating point and uses printf, the compiler cannot safely assume that there aren't any dynamically-created floating-point formats - so it just has to include them, just in case...

 Totally off topic but ...

"There is obviously sufficient analysis going on to allow it to omit a load of stuff if the program uses no floating point."

From previous experience of Microsoft compiler technologies, I would say that it is not so much analyzing that the stuff can be omitted but rather that they should not be included.

Specifically - When floating point is required in a module, it makes reference(s) to any external functions that are required for the compiler chosen task.

At link time these external references would normally pull in the libraries that satisfy the external references.

So - It is not normally the formatting string of the printf that is interpreted by the compiler to determine whether the libraries that are included, but rather the fact that a floating point access is somewhere in the project.

 RE: Bizarre

There is obviously sufficient analysis going on to allow it to omit a load of stuff if the program uses no floating point.

Yes. But that doesn't require, or imply, any analysis of the printf() calls themselves.

Presumably, if the program contains floating point and uses printf, the compiler cannot safely assume that there aren't any dynamically-created floating-point formats - so it just has to include them, just in case.

Indeed.

 RE: Bizarre

Remember people, C is even more limited!

Just curious, but how is C more limited than C++?

That's like saying that assembly is more limited than C. Or, that the Russian language is more limited than German.

Jon

 Superiority

"Just curious, but how is C more limited than C++?"

C++ is (basically) a superset of C

Embedded C++ is (basically) a subset of C++

And Embedded C++ is (basically) a subset of C++

So, expressed in terms of facilities:

C < Embedded C++ < C++

I said it is more limited purely because it is considered to be lower level, less abstract etc

So it could be extended to the expression:

Assembler < C < Embedded C++ < C++

The extrapolation to "Russian is more limited than German" is clearly wrong.

But everyone knows that Esperanto is superior to all others ;)

 Whoops, mistake, correction

Just to correct my last post before I get abuse:

"Just curious, but how is C more limited than C++?"

C++ is (basically) a superset of C

Embedded C++ is (basically) a subset of C++

And Embedded C++ is (basically) a superset of C

So, expressed in terms of facilities:

C < Embedded C++ < C++

I said it is more limited purely because it is considered to be lower level, less abstract etc

So it could be extended to the expression:

Assembler < C < Embedded C++ < C++

The extrapolation to "Russian is more limited than German" is clearly wrong.

But everyone knows that Esperanto is superior to all others ;)

 Missing the point

You started this thread because you didn't understand that a C compiler cannot compile C++ source code - you even called this a "bug"

The point in mentioning that Embedded C++ doesn't support everything in "full" C++ was just to save you making the same mistake if you try to compile "full" C++ source code with an Embedded C++ compiler.

 Missing the point - But I'm learning

I may have started the thread thinking there was a bug.

Since then I've been reading manuals and scanning web sites.

I've been busy and think I've learnt a lot in a short time.

I now know more about the various programming languages and (contrary to the apparent wish of some posters to this thread) am now working on a project with confidence that it will do what the contract requires.

For example, I am already communicating with the display and showing text. Moreover, I am using classes.

I hope that I will continue to learn and as a consequence I can then make and provide balanced opinions in the future.

 RE: Missing the point - But I'm learning

So, what tool did you buy or are using the demo version of?

 RE: Missing the point - But I'm learning

So, what tool did you buy or are using the demo version of?

At the moment I'm considering both the IAR and Ceibo options.

Currently the limitations of the demonstration versions (of both) are sufficient high to allow me to do the basics.

 Good for you

"I may have started the thread thinking there was a bug."

You certainly did!
And look how stubbornly and vehemently you attacked those who tried to explain to you why it is not a bug, but it perfectly normal and expected behaviour!

"I now know more about the various programming languages"

Good.
Now that you understand, look back at your original dozen posts or so - look how you responded to the people who tried to explain this to you.
Is it surprising that you got their backs up?

 RE: Good for you

Is it surprising that you got their backs up?

Hmmmm. I might have upset one or two. But WTF. That's life.

More interesting than that is the evidence of bickering between respondents on this thread (and others).

 Compiler wars

"More interesting than that is the evidence of bickering between respondents on this thread"

I think if you go to any forum and find any thread that tries to compare different products, languages, styles, or whatever you'll end up with some of that...!

 RE: Compiler wars

I think if you go to any forum and find any thread that tries to compare different products, languages, styles, or whatever you'll end up with some of that...!

You're probably right with that.

But what I've witnessed, in the short time I've been here, is that there are one or two people on this forum who seem to go from thread to thread trying to win points over one another.

I will mention no names. You will probably know who I'm talking about!

And I got comments about my attitude!

 RE: Compiler wars

Currently the limitations of the demonstration versions (of both) are sufficient high to allow me to do the basics.

Which one generates the smallest code, and what processor are you building for?

 Not True

C++ is NOT (basically) a superset of C
Is was at one time. The different commities have caused both languges to diverge.
Kind of like English and American English.

Some identical expressions may work differently.

How limiting Embedded C++ is compared to C++ you will have to find out. Since IAR has a trial version You are set. Let us know the outcome. It maybe of use to someone else.
A post of how big cout << "Hello World" would be of intrest.

 RE: Not True

"C++ is NOT (basically) a superset of C"

Might be closer to say that they share a common subset?

 RE: Not True

C++ is NOT (basically) a superset of C
Is was at one time. The different commities have caused both languges to diverge.
Kind of like English and American English.

As was highlighted to me before on this thread 'if you know C++, then you also know C'.

That view does appear to be a generally accepted one.

I don't think I have ever seen the opposite of that mentioned; i.e., 'if you know C, then you know C++'.

This REALLY does imply to me that C can (for most practical purposes) be viewed as a subset of C++.

However, I do remember someone once trying to argue that because all pianos are made of wood, it must follow that all wood is made into pianos!

The likening of C and C++ to English and American English you suggest are, I think, just plain stupid.

Accents aside, it would be unusual for an American to not understand a Briton or a Briton to not understand an American.

Give a C program to someone who knows C++ - They will probably be able to follow it.

Give a C++ program to someone who knows C and no C++ - They may well be very confused with the classes, templates, operator overloading etc etc etc.

 RE: Not True

Give a C program to someone who knows C++ - They will probably be able to follow it.

Filip,

This statement is a common source of problems. There are numerous scenarios where this does not hold true. That is, an expression that is both valid C and C++ can have different meanings in each.

For example, imagine you see the following declaration in a source file:

extern int foo();

Without looking at another source file, can you tell me what this declaration means? That answer, of course, is that it depends on what language we're talking about. In C, this is a declaration for an unprototyped function having external linkage that takes an unspecified number and type of parameters. This means that within this C module, the following:

foo();
foo(x);
foo(3.14159);

would all compile just fine. C++ on the other hand, would consider this function to have been defined as extern int foo(void) and would not compile any attempts to pass parameters to it.

The statement that "C++ is not just a superset of C" is a way of saying that there are enough of these divergent paths taken in the languages that one should become fluent in each rather than saying "since I know C++, I also know C."

-Jay Daniel

 RE: Not True

As was highlighted to me before on this thread 'if you know C++, then you also know C'.
For the most part yes. But for the part that is not...
A K&R Book would be handy

That view does appear to be a generally accepted one.
Like the world is flat?

I don't think I have ever seen the opposite of that mentioned; i.e., 'if you know C, then you know C++'.
I can not argue with you there.

This REALLY does imply to me that C can (for most practical purposes) be viewed as a subset of C++.
Only for the most part

The likening of C and C++ to English and American English you suggest are, I think, just plain stupid.

Accents aside, it would be unusual for an American to not understand a Briton or a Briton to not understand an American.
I am not sure where you are from. But I as an American who went to England learn there is a little more of a difference then just the accent. They use words we do not. And some with a very different meaning like C / C++

Give a C program to someone who knows C++ - They will probably be able to follow it.
True

Give a C++ program to someone who knows C and no C++ - They may well be very confused with the classes, templates, operator overloading etc etc etc.
Very True

 Comparison of tools?

Since you said you were making goood progress, I asked about a week ago about a comparison between the two tools.

I'm still interested, so I repeat my question:

Which one generates the smallest code, and what processor are you building for?

 RE: Comparison of tools?

Which one generates the smallest code, and what processor are you building for?

Genuine interest - Or hope for failure?

Anyway, FYI ...

Building for an 80C535 - With a lot of spare port pins!

I decided to stick with the IAR because I felt that the development environment is more friendly. I cannot therefore give comparisons concerning code size etc.

As it happens, I ended up using a (rather flippant) suggestion from one of the original posters where I split the program into blocks and having indirect entry points (jump tables) to regions of ROM space. The IAR package is good for locating separate blocks of code. Better still, I didn't reach the limits of the demo version - Ha Ha IAR.

This method allowed me to do what I REALLY wanted to do; i.e., make modular self contained units suitable for class abstraction.

The really good news (for me) is that the demo version is now complete and I am expecting to release the final version to the customer next week.

Embedded systems - Not so difficult after all!

 RE: Comparison of tools?

I decided to stick with the IAR because I felt that the development environment is more friendly.

That was my impression too, when I worked with both, the CEIBO and the IAR package, but thats certainly a matter of taste.

Better still, I didn't reach the limits of the demo version - Ha Ha IAR.

When I tried the IAR demo version (about two years ago) it came as a full version that was only time limited. I think it could be used for 30 days without any restrictions or at least without any code size limit. Of course one was only allowed to use it for testing purpose, not for developing commercial products?!

I cannot [..] give comparisons concerning code size etc.

But I can. Here are my experiences:
The reason for me, to test the IAR compiler was the fact, that the generated code by the CEIBO compiler reached the 64 KB code size limit of the controller I was using these days. In fact I hit the 64 KB limit for the second time. The first time I could bring it down to about half the size by means of optimization, linker code packing and 'tricky' programming techniques that made the CEIBO create smaller code. That left me with about 30KB free code space (that I urgently needed) but also with quite undebuggable code... And after adding some more source code, the code size quickly aimed for the 64 KB again, as the code bloated somehow exponentially (at least that was my impression). So I decided to have the IAR compete against the CEIBO. Adapting the source code from my CEIBO project to the IAR was very easy but the result didn't turn out to be what I was hoping for.
CEIBO vs. IAR final result 64 KB to 63 KB. I considered this to be a draw...

My next step was to rewrite the whole stuff in pure C. That took me a while but it was worth it. In 'C only' the code size was less than 30 KB without linker code packing and with an acceptable optimization level!
I can't recall all the details as it has been a while ago but that made me ban both, the CEIBO and the IAR to the depths of my harddrive where they lie untouched since that day...

Summary: IMHO C++ on a 80C51 can not be recommended for 'complex' applications. But the only real advantage of C++ on a 80C51 that I see, that is as Filip said make modular self contained units suitable for class abstraction only turns out to be an advantage in complex applications, doesn't it?

Just my two cents...

Carsten

 RE: Comparison of tools?

Hi Carsten,

Nice to hear from somebody who's tried something similar :)

Yes, you're right about the IAR demo limitation - It is fully functional but limited to 30 days use and not to be used for commercial applications. Now the demo has been done successfully, I have the funds to buy the full package.

With regards to the Ceibo demo package, I wasn't sure that it was actually using the Keil compiler underneath???

When I looked at the code it produced (i.e., assembler listing files) it seemed more like that of the SDCC package - But I might well be wrong about that.

I would say that the word 'complex' in this environment is a relative term. Fortunately for me, code and data space are decent (512Kb each using banking) and speed is not critical. If the project goes further forward, I would probably recommend a higher speed core (probably Dallas) for the next boards to compensate for the extra overhead of the C++.

I can understand that for more pressured hardware, the use of C++ is probably not the best choice. As for me, I'm glad I pursued it.

 RE: Comparison of tools?

Hi Filip,

the CEIBO produces C code from your C++ source for the KEIL compiler. When you install the CEIBO package, you can work from the KEIL IDE writing your program in C++ . When you hit the compile button, the CEIBO makes C code out of your *.cpp files and then hands it over to the KEIL compiler. You never get to see the actual C code.

Well, 'complex' of course was meant with respect to the 8051 environment.
With 512 KB of available space, you certainly can handle a lot of C++ overhead. But usually much more code takes much more execution time when running on your system.
On the one hand, you state that speed is not critical on the other hand you say that you might need a faster core to compensate...
To get the desired performance you have to decide what's the better approach for you. When you are faster in development using C++ you can probably afford a (more expensive) high speed core. But when you're aiming to sell many units of your product, you might better be using C only, even if it takes you longer to write your program.
(Of course you could also switch to another core architecture. When the requirement is 'C++ and speed', an 8051 is not necessarily the first thing, to come in mind...)

As usual, there's not always just black and white but for me, C++ is no longer an option in my 8051 applications.

Carsten

 RE: Comparison of tools?

Hi Carsten,

Hmmm ... When I installed the Ceibo demo package it was on a clean PC (i.e., no Keil etc) and the only thing I got was the Ceibo IDE.

I've just looked back in the 'bin' folder and found the givaway SDCC.EXE and SDCCLIB.EXE. No Keil components to be found.

Ok ... I see ... It uses Keil if installed.

On the one hand, you state that speed is not critical on the other hand you say that you might need a faster core to compensate...

Sorry, what I mean is that future requirements for the project might need more processing - That might justify a faster core.

I take your point concerning costs but, fortunately for me here, this project will only ever be small(ish) quantities and the processor etc is not a real issue.

However, that said, I may venture into ARM ;)