This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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!";
}

Parents
  • 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.

Reply
  • 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.

Children
No data