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 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
Can someone answer my question in English please!
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.
"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 www.iar.com/.../p7371_eng.php
I don't know how much that might "cramp your style" if you're used to a full-blown C++ compiler...
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...
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 *** 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?)
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.
Did you try it out yourself, or did you conclude it from the advertisements of the compiler makers ?
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 ?
"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!
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 Please read the manual, 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?
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?
"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"!!
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.
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.
"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...
"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.
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
"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 ;)
Just to correct my last post before I get abuse:
And Embedded C++ is (basically) a superset of C
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.
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.
So, what tool did you buy or are using the demo version of?
"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?
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).
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.
"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...!
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!
Which one generates the smallest code, and what processor are you building for?
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.
"C++ is NOT (basically) a superset of C"
Might be closer to say that they share a common subset?
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.
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
View all questions in Keil forum