How do you return a function from a macro!?(in C)
Yes, very 
. However, depending on what parts you use and the compiler, it can cause speed issues as well as bloat. I am trying to avoid C++ for my os for a few reasons, bloat and self-hosting, will be easier to compile a C compiler for my OS than a C++ compiler. I am also trying to keep the size of my OS small, yet portable, so C is my best option.
. However, depending on what parts you use and the compiler, it can cause speed issues as well as bloat. I am trying to avoid C++ for my os for a few reasons, bloat and self-hosting, will be easier to compile a C compiler for my OS than a C++ compiler. I am also trying to keep the size of my OS small, yet portable, so C is my best option.
...if you don't know the language well. It's true that careless use of C++ can cause quite inefficient code, but that is true for every language. C++ is just much, much more than C, and people tend to carry over their "styles" from C or Java, which doesn't result in good C++ code.Ready4Dis wrote:However, depending on what parts you use and the compiler, it can cause speed issues as well as bloat.
Used well, C++ can be made more efficient than C, both in speed and in time-to-release (which is the important point with the other 80% of the code, as we know). It just takes longer to get "fluent" in C++.
Every good solution is obvious once you've found it.
Not trying to start a flame war, both have their uses, but I have never seen C++ more efficient speed wise than C, time-to-release, yes, it can be MUCH more efficient, as can re-useability and readability. A long while back me and a buddy were writing a ray-tracing engine, we used C++ because it was much simpler to implement, especially with multiple object types (for tracing said rays). Well, we inherited from the base class, overloaded virtual functions for collisions, etc and it worked very nicely, although seemed slower that what we were aiming. One day I decided to see how much worse C was, so I wrote generic structs with pointers to function, and type information, and a ton of casting and if statements everywhere. We saw our speed more than double, and have left everything in C since. I do use C++ in a lot of my game programming, most things can be optimised algorithmically, in which case their is no noticeable speed difference, however, for something very time critical, I still stick with C and in some cases assembly depending on how time critical (and how well the compiler optimizes). I normally won't optimize a section of code unless it is found to be the source of most of the time spent using a profiler however, no need was time optimizing something that runs once in a 100th of a second. Anywho, like I said, I use C++ a lot in my programming, it makes development time much faster, finding bugs are ussually easier (due to being easier to follow program flow without all the hacks!), and a lot of other things much nicer (and I do have a few includes that I re-use in a lot of my apps, a memory tracker to keep track of new/delete calls for memory leaks, a generic linked list and dynamic array class, as well as a few other nifty things).Solar wrote:...if you don't know the language well. It's true that careless use of C++ can cause quite inefficient code, but that is true for every language. C++ is just much, much more than C, and people tend to carry over their "styles" from C or Java, which doesn't result in good C++ code.Ready4Dis wrote:However, depending on what parts you use and the compiler, it can cause speed issues as well as bloat.
Used well, C++ can be made more efficient than C, both in speed and in time-to-release (which is the important point with the other 80% of the code, as we know). It just takes longer to get "fluent" in C++.
An STL sort() beats a C-style qsort() by almost one order of magnitude (because the compare function can be inlined). That's just one example.Ready4Dis wrote:Not trying to start a flame war, both have their uses, but I have never seen C++ more efficient speed wise than C...
Means, you took the traditional beginner's road (object oriented), which sadly enough is still taught by many introductionary books, and didn't use the real power of C++ when it comes to efficiency, which is templates...Well, we inherited from the base class, overloaded virtual functions for collisions, etc...
Poor C++ code.One day I decided to see how much worse C was, so I wrote generic structs with pointers to function, and type information, and a ton of casting and if statements everywhere. We saw our speed more than double...
Dynamic array class? What's wrong with <vector>?...a generic linked list and dynamic array class...
Every good solution is obvious once you've found it.
I removed a lot of stuff from here, don't want to change topic or start a langauge war. Just a few things:
What's a good way to use templates on data types for a precompiled engine. templates are compile time entities and cannot be used in a precompiled engine, where virtual functions can, unless I am missing something (it happens pretty often).
Is the STL part of the C++ standard, or is it a standard in and of itself?
C++ is very useful, templates do NOT slow down code in any way, shape or form, and I recommend using them, but avoid virtual functions unless necessary, or if it's a piece of code that isn't time critical. I will say that templates can lead to a bloated kernel if not careful, because it will generate the same code many many times, again use discretion. I'm not saying that C++ can't be as efficient as C, it's just very easy to produce in-efficient code really fast. I do programming on microchips, where memory real-estate and cpu speed are very limited, so these things carry over into my x86 programming as well.
What's a good way to use templates on data types for a precompiled engine. templates are compile time entities and cannot be used in a precompiled engine, where virtual functions can, unless I am missing something (it happens pretty often).
Is the STL part of the C++ standard, or is it a standard in and of itself?
C++ is very useful, templates do NOT slow down code in any way, shape or form, and I recommend using them, but avoid virtual functions unless necessary, or if it's a piece of code that isn't time critical. I will say that templates can lead to a bloated kernel if not careful, because it will generate the same code many many times, again use discretion. I'm not saying that C++ can't be as efficient as C, it's just very easy to produce in-efficient code really fast. I do programming on microchips, where memory real-estate and cpu speed are very limited, so these things carry over into my x86 programming as well.
Lots of stuff deleted here, too, to honor your edit.
The STL is part of the C++ standard library. (Which is larger than just the STL; actually the "S"TL became part of the standard pretty late in the standartization process.) It is, unless I am very much mistaken, specified in the same ISO standard as the C++ language itself.
I know for a fact that the C library is part of the C language standard.
The STL is part of the C++ standard library. (Which is larger than just the STL; actually the "S"TL became part of the standard pretty late in the standartization process.) It is, unless I am very much mistaken, specified in the same ISO standard as the C++ language itself.
I know for a fact that the C library is part of the C language standard.
Last edited by Solar on Wed Jan 03, 2007 8:50 am, edited 1 time in total.
Every good solution is obvious once you've found it.
Guess my edit wasn't fast enough, lol.
Anyways, sort function using inlines in C is easy, just write a macro.
Ok, maybe MUCH was a bad word, but I was just saying that it CAN be significant difference if you're not careful.
I wasn't trying to say that C++ didn't have such a thing, I just like to use mine because it has everything I need, and nothing I don't. The vector class is perfectly acceptable, and is optimized and looked over by many. I was just saying that there won't be any noticeable performance difference because I obviously wouldn't be using it if I modified the list very often, there are better ways (linked lists). My array doesn't resize on each add of an element, it pre-allocates a number of elements in advance (this number is dynamic and can be set, so if you did want it to allocate each time to conserve memory, set it to zero). Very similar to how a vector works i'm sure.
I am writing a linker for my OS, however I am using a pre-made assembler and C compiler, I also wrote a project manager with highlighting that will be converted for my OS when it's done. I am trending towards writing my own assembler, but will probably not delve into a C or C++ compiler because it would require way to much time at this point.
Ok, we agree, C++ standard lib is way to much for a kernel, that was mostly my point in the start, then it kinda wandered.
One small example for you: My 3d rendering core for my games: It is a simple class that has functions for setting up a screen, and rendering objects to the screen. I use virtual functions right now. My game on the other hand, doesn't care if this rendering .dll is opengl, direct3d, or a software rendering engine, functions pointers and virtual functions are about the only way to handle this (I could just return a pointer to EACH function if I really was bored, but hey, that's more effort than the return is worth at this point). This isn't really a big speed issue, because I don't draw many individual polygon's, mostly allocate large lists and fill them in, and draw them with a single draw call. But, is there a better way, not including void pointers or an array of functions
. This is why I got confused to your statement about templates and my bad c++ code. Sure it was bad, but one of the goals was also ease of use and updating, which got thrown out due to it being to slow, and only the higher level interface to the core was made to be easy to use and update.
Anyways, sort function using inlines in C is easy, just write a macro
.Ok, maybe MUCH was a bad word, but I was just saying that it CAN be significant difference if you're not careful.
I wasn't trying to say that C++ didn't have such a thing, I just like to use mine because it has everything I need, and nothing I don't. The vector class is perfectly acceptable, and is optimized and looked over by many. I was just saying that there won't be any noticeable performance difference because I obviously wouldn't be using it if I modified the list very often, there are better ways (linked lists). My array doesn't resize on each add of an element, it pre-allocates a number of elements in advance (this number is dynamic and can be set, so if you did want it to allocate each time to conserve memory, set it to zero). Very similar to how a vector works i'm sure.
I am writing a linker for my OS, however I am using a pre-made assembler and C compiler, I also wrote a project manager with highlighting that will be converted for my OS when it's done. I am trending towards writing my own assembler, but will probably not delve into a C or C++ compiler because it would require way to much time at this point.
Ok, we agree, C++ standard lib is way to much for a kernel, that was mostly my point in the start, then it kinda wandered.
One small example for you: My 3d rendering core for my games: It is a simple class that has functions for setting up a screen, and rendering objects to the screen. I use virtual functions right now. My game on the other hand, doesn't care if this rendering .dll is opengl, direct3d, or a software rendering engine, functions pointers and virtual functions are about the only way to handle this (I could just return a pointer to EACH function if I really was bored, but hey, that's more effort than the return is worth at this point). This isn't really a big speed issue, because I don't draw many individual polygon's, mostly allocate large lists and fill them in, and draw them with a single draw call. But, is there a better way, not including void pointers or an array of functions
. This is why I got confused to your statement about templates and my bad c++ code. Sure it was bad, but one of the goals was also ease of use and updating, which got thrown out due to it being to slow, and only the higher level interface to the core was made to be easy to use and update.
C standard: ISO 9899:1999 (most recent), chapter 7 iirc is the c library.Solar wrote:The STL is part of the C++ standard library. (Which is larger than just the STL; actually the "S"TL became part of the standard pretty late in the standartization process.) It is, unless I am very much mistaken, specified in the same ISO standard as the C++ language itself.
I know for a fact that the C library is part of the C language standard.
C++ standard: ISO 14882:2003 (most recent), chapter 20-27 iirc is the STL.