I wasn't complaining, just making a simple observation. Actually, none of my friends are geeks. I must be the only geek without them. I can only joke about Dilbert comics at work! Sitting at a bar with friends, I would just get a blank stare.
I'm not MS fanboy, but WTF? What should MS be "getting"? Why does this joker think MS should just give their code to the Open Source community? Does he want the keys to my house next? People today have such an inflated sense of entitlement.
Do I know what it means? Um, yeah, I've been writing embedded systems for 15 years. First, C++ does not require you to write OO programs. Second, there is no reason to believe an OO program is larger than an equivalent non-OO program. Third, listing the size of the entire C++ library means nothing. You don't have to, and certainly shouldn't use the ENTIRE library. Fourth, that is the C++ shared library for a HOSTED system. Like C, the C++ standard provides for free standing systems. My C++ library for our targeted system is much smaller than that. And Fifth, 1MB? Valuable? Some of the embedded systems I've been involved in have 1/2 GB of memory or more. Embedded does not necessarily mean resource starved. Clearly, as I stated, know-nothing nonsense. You don't seem to know jack about C++, OO, or embedded systems.
I had a recruiter email me once, to which I replied "no thanks, I prefer to do my own looking." He got very irate and proceeded to threat to send my name to every recruiter and company he knew and worked with to "black-list" me. I told him to go ahead, and would happily return the favor.
That's one difference between the two languages. In C++, const has local scope by default. In C, const is extern by default. About "taking the address": see #2 of my full comment.
I got your point. First off, it is quite easy to write multi-platform code without resorting to the preprocessor (though I don't have a major issue with people who do so). Second off, the article and the OP's comment were about using #define for constants in C++. It had nothing to do other uses (though they aren't necessary either). And I don't have a beard, nor do children and there comments make me cry.
Well, the parse tree isn't stored in the final code. If you mean the symbol table built into the code file, then the local symbols may be striped out without harm. Regardless, the local symbols are not normally loaded in RAM anyways.
Regards,
DrX
Of course. I write code that must run on a great many platforms, included custom-made embedded single board computers. Have for years. What's your point?
There is no reason to assume that just because his project is embedded that he is using C and not C++. The C++ standard defines the same support for stand-alone (non-hosted) systems as C does. C++ is used in a great many embedded systems. We use it all the time.
I use C++ for embedded systems all the time (along with C and Ada). Compilers will "inline" constants just as well as #defines are. By "symbol table" I assume you are talking about the global symbol table used by the dynamic link-loader. Since constants are local by default I would not worry about this, as they will not appear in the table. And don't listen to the commenter saying you should use C instead of C++ for embedded systems. That's just know-nothing nonsense.
I'm sorry, but you really don't know what the hell you are talking about. There is no requirement by the C++ standard that the constant be "stored in memory." They are often "hard coded" inline and not stored, unless they are 1) large or 2) have their address taken.
DrX
Most apps? I think you are living in a PC-centric world (and even then I do not believe its true). Ever write a real-time embedded system? Its pretty much impossible to prove you can meet several hard dead-lines with a single thread. And most systems in this realm do not use time-slicing (which I assume you mean when you wrote "multi-tasking"). Not all multitasking OSes are time-sliced. In the real-time world we usually use OSes that do cooperative multitasking that are priority preemptive. Unless a higher priority task wakes, or the owning task blocks, a task has to processor until it gives it up (kind of how Windows 3 worked). It's wrong to assume that all programs and programmers use a hosted system (Windows, Unix, etc.). Actually, there are more embedded systems in the world than PCs, Macs, and such. People who rail against multi-threading have no concept there are systems out there unlike their home computers.
You can Bzzt all you want, then take a look at the standards. Neither the C, nor the C++ standards, guarantee any such behavior. C streams are flushed on exit or direct calls to fflush. C++ streams are flush via endl or flush(). As a matter of fact, it is undefined behavior in C++ to exit a program having NEVER sent endl to your stream. If you want to run your mouth off and make such BS claims, at least have a backbone and don't post as an AC.
Slashdot Mirror
I wasn't complaining, just making a simple observation. Actually, none of my friends are geeks. I must be the only geek without them. I can only joke about Dilbert comics at work! Sitting at a bar with friends, I would just get a blank stare.
Saying cable modem is just as bad.
I'm not MS fanboy, but WTF? What should MS be "getting"? Why does this joker think MS should just give their code to the Open Source community? Does he want the keys to my house next? People today have such an inflated sense of entitlement.
No, it wouldn't.
Do I know what it means? Um, yeah, I've been writing embedded systems for 15 years. First, C++ does not require you to write OO programs. Second, there is no reason to believe an OO program is larger than an equivalent non-OO program. Third, listing the size of the entire C++ library means nothing. You don't have to, and certainly shouldn't use the ENTIRE library. Fourth, that is the C++ shared library for a HOSTED system. Like C, the C++ standard provides for free standing systems. My C++ library for our targeted system is much smaller than that. And Fifth, 1MB? Valuable? Some of the embedded systems I've been involved in have 1/2 GB of memory or more. Embedded does not necessarily mean resource starved. Clearly, as I stated, know-nothing nonsense. You don't seem to know jack about C++, OO, or embedded systems.
Bravo!
You stab 'em. we slab 'em.
I had a recruiter email me once, to which I replied "no thanks, I prefer to do my own looking." He got very irate and proceeded to threat to send my name to every recruiter and company he knew and worked with to "black-list" me. I told him to go ahead, and would happily return the favor.
That's one difference between the two languages. In C++, const has local scope by default. In C, const is extern by default. About "taking the address": see #2 of my full comment.
Um, yeah. That's was my point: const should be using instead of #define in C++. Ever heard of reading? What's your point?
I got your point. First off, it is quite easy to write multi-platform code without resorting to the preprocessor (though I don't have a major issue with people who do so). Second off, the article and the OP's comment were about using #define for constants in C++. It had nothing to do other uses (though they aren't necessary either). And I don't have a beard, nor do children and there comments make me cry.
Well, the parse tree isn't stored in the final code. If you mean the symbol table built into the code file, then the local symbols may be striped out without harm. Regardless, the local symbols are not normally loaded in RAM anyways.
Regards,
DrX
Of course. I write code that must run on a great many platforms, included custom-made embedded single board computers. Have for years. What's your point?
There is no reason to assume that just because his project is embedded that he is using C and not C++. The C++ standard defines the same support for stand-alone (non-hosted) systems as C does. C++ is used in a great many embedded systems. We use it all the time.
I use C++ for embedded systems all the time (along with C and Ada). Compilers will "inline" constants just as well as #defines are. By "symbol table" I assume you are talking about the global symbol table used by the dynamic link-loader. Since constants are local by default I would not worry about this, as they will not appear in the table. And don't listen to the commenter saying you should use C instead of C++ for embedded systems. That's just know-nothing nonsense.
If you are using C++ and #define, I guarantee you that YOUR code is a disaster waiting to happen. DrX
I'm sorry, but you really don't know what the hell you are talking about. There is no requirement by the C++ standard that the constant be "stored in memory." They are often "hard coded" inline and not stored, unless they are 1) large or 2) have their address taken. DrX
alloca is not part of Standard C, you know...
What acrobatics? Did we watch the same movie?
Yes, I do think him for answering my question.
Please, tell me where that is from. It's been driving me nuts trying to remember the source of the reference!
So, does your sig. have a trailer?
I heard that a DVD with all four version of Blade Runner is coming out this year. Anyone know if that is true, and when it will happen?
Most apps? I think you are living in a PC-centric world (and even then I do not believe its true). Ever write a real-time embedded system? Its pretty much impossible to prove you can meet several hard dead-lines with a single thread. And most systems in this realm do not use time-slicing (which I assume you mean when you wrote "multi-tasking"). Not all multitasking OSes are time-sliced. In the real-time world we usually use OSes that do cooperative multitasking that are priority preemptive. Unless a higher priority task wakes, or the owning task blocks, a task has to processor until it gives it up (kind of how Windows 3 worked). It's wrong to assume that all programs and programmers use a hosted system (Windows, Unix, etc.). Actually, there are more embedded systems in the world than PCs, Macs, and such. People who rail against multi-threading have no concept there are systems out there unlike their home computers.
You can Bzzt all you want, then take a look at the standards. Neither the C, nor the C++ standards, guarantee any such behavior. C streams are flushed on exit or direct calls to fflush. C++ streams are flush via endl or flush(). As a matter of fact, it is undefined behavior in C++ to exit a program having NEVER sent endl to your stream. If you want to run your mouth off and make such BS claims, at least have a backbone and don't post as an AC.