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

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

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

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

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

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

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

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

  • 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

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

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

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