Bug in compiler

"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++.

"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++.

"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++.

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".

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?

"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++...

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

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

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?

"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...

;-)

"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

"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?"

"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"...?

en.wikipedia.org/.../Snake_oil

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.

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.

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.

"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.