As the title suggests, I'd like to begin learning C++. I already have some past experience with programming, (Java background, so I don't know how much that'll help), so the learning curve won't be as bad as it would've.
I'm specifically looking for game programming. I know game theory, but since I don't know C++, (Java is terrible for games...), I haven't been able to apply it very well. Are there any decent resources, tutorials, books, eBooks, or something of the sort that I could use?
It's not optimized to do that. It also runs a VM when you run the Java environment, which is a huge RAM hog.
Having interpreted code is actually not a RAM hog it uses CPU to compile it and with JIT compilers this is really non issue it uses a bit more ram to store the byte code copy but its a non issue.
Java can be compiled to machine code like c++ if you are some twisted insane person who wants to remove pretty much the only large advantage Java has and that's ability to use the same .jar file for Linux OSX Windows FreeBSD without issue(for the most part).
checking YouTube for "C++ tutorial" turns up lots of stuff, dunno if any are good.
luckily, it probably shouldn't be too hard to apply knowledge from one to the other...
granted, yes, what is provided by the libraries is very different though, and there is a lot that will probably be new.
checking YouTube for "C++ tutorial" turns up lots of stuff, dunno if any are good.
luckily, it probably shouldn't be too hard to apply knowledge from one to the other...
granted, yes, what is provided by the libraries is very different though, and there is a lot that will probably be new.
Helps a bit, but not really...
I'm mostly interested in 2D game creation. I have a lead, so I'll see where it goes.
Having interpreted code is actually not a RAM hog it uses CPU to compile it and with JIT compilers this is really non issue it uses a bit more ram to store the byte code copy but its a non issue.
this statement doesn't really make sense.
but, most evidence is that the JVM does use a bit of RAM though, but this has more to do with how its memory management works (some people blame GC in general, but this isn't really right either, lack of either pass-by-value semantics or delete is probably a bigger issue here...).
for some apps, it doesn't matter so much, but for others it does.
whether or not this has much effect on performance is a secondary matter.
Java can be compiled to machine code like c++ if you are some twisted insane person who wants to remove pretty much the only large advantage Java has and that's ability to use the same .jar file for Linux OSX Windows FreeBSD without issue(for the most part).
ironically, this hasn't turned out to really be a big issue in-general.
if people can recompile for any popular targets, then the downside of not being able to run the same binary is not as big of an issue (more so that on many targets JARs just don't "look" like native binaries).
so, having it look more like a native program may be more of an advantage than having a JAR.
otherwise, as for C and C++, these give more direct access to OS APIs, which can be more helpful for things like games and similar.
Yes lets compile Java to native code because compiling to a crappier version of the same code another language like C/C++ generates is a good idea. If you're going to argue with me it isn't crappier, there's a reason you -have- pointers, references, all that stuff in C/C++, it isn't just for decoration and it's going to be done in an ass backwards way trying to do it with Java.
Not only that but the compilers are designed to optimize C/C++ code and that optimization will just not be there even ignoring the tags and keywords that other languages work off of, it's like trying to stuff a pancake into a box made for a coffee cup.
Ignoring that, if you want to make games I'd highly recommend starting with SDL or (preferably)SFML.
What I meant was just because its using a VM does not make it a ram hog It used to have a lot of CPU overhead but thanks to JIT that is a non issue.
Take c# as an example mono to be blunt is pretty dam terrible.
My suggestion is if you know Java already why not learn to make a game and learn OpenGL under it rather then learning C++ then learning OpenGL rendering ect.
I am not a big fan of C++ I would recommend D over it if not for the fact D lacks the sheer amount of books and documentation that C++ has.
If you want to turn this into a career yes learn C++ I am just saying Java is not that bad and if you know it already run with it and use LWJGL to create a basic game in a language you know. This assuming you know Java well if you have a basic knowledge go ahead and switch.
What I meant was just because its using a VM does not make it a ram hog It used to have a lot of CPU overhead but thanks to JIT that is a non issue.
except:
RAM use and CPU overhead are not the same thing (time and space are not exactly the same thing).
and, it is not that VMs are inherently RAM-hogs either, it is just, Java uses *lots* of memory for things which "seemed like a good idea at the time".
simple example, String:
each String has a class instance (requires memory for an object header and object payload, consisting of several fields);
lots of temporary String instances are created;
they store their characters in an array (requiring a secondary object head);
the arrays are UTF-16 (so the characters use up on-average ~ 2x as much space as if they were UTF-8, noting that "most" strings tend to consist primarily of ASCII characters, and for most common scripts it is break-even).
whereas, for C-style strings:
typically the string is just the raw characters (+ terminator byte), located somewhere in memory.
these sorts of costs can add up...
this isn't to say that Java code goes slow, only that its memory footprint tends to be larger.
Take c# as an example mono to be blunt is pretty dam terrible.
comparing something mediocre to terrible (and unrelated) does not make for a strong argument.
My suggestion is if you know Java already why not learn to make a game and learn OpenGL under it rather then learning C++ then learning OpenGL rendering ect.
a person could do either one.
although porting code between them is kind of a pain, it isn't really difficult for a programmer to know both and move between one and the other as-needed.
I am not a big fan of C++ I would recommend D over it if not for the fact D lacks the sheer amount of books and documentation that C++ has.
personally I mostly prefer just using C, but C++ does have a few merits.
I know C pretty well, just off-hand I don't know of any good C or C++ tutorials, and wouldn't be inclined to go searching the internet and reviewing them to look for any good ones.
D has a big drawback in that it requires manual effort to interface it with existing libraries (as-in, people needing to rewrite the headers into a form the compiler can understand). it is also a much less common language as well.
If you want to turn this into a career yes learn C++ I am just saying Java is not that bad and if you know it already run with it and use LWJGL to create a basic game in a language you know. This assuming you know Java well if you have a basic knowledge go ahead and switch.
It's not optimized to do that. It also runs a VM when you run the Java environment, which is a huge RAM hog.
4 GB of DDR3 RAM is quickly becoming the standard. The RAM hog that used 1 GB of RAM last year now uses a completely normal amount of RAM for most people.
except:
RAM use and CPU overhead are not the same thing (time and space are not exactly the same thing).
If you really knew what you were talking about you would know this is flat ass out wrong. RAM has a bus, it has to communicate with the CPU and RAM is actually a big bottleneck in why the CPU has to wait many times. Of course things like the hard drive are -much- slower but there is a reason that cache misses are a killer in applications, anyone acting like RAM is just instant lightspeed storage with no overhead really need to go read a lesson in how a CPU actually works with the registers and the ALU and all that. It literally is sending a highway message to the RAM everytime it has to set -anything- in it, or read -anything- in it. All tasks require CPU time one way or another because nothing in a computer operates without interfacing with the brain of the computer and wasting its time.
and, it is not that VMs are inherently RAM-hogs either, it is just, Java uses *lots* of memory for things which "seemed like a good idea at the time".
No the Java VM is inherently a RAM hog, it allocates a huge chunk of RAM(or a little chunk, depending on default program settings and stuff but you get the idea.) It allocates a chunk very similar to how a resizable array that just grown acts. Basically it allocates a chunk of RAM and whether the program is using it or not is completely irrelevent, it locks the memory for the VM program and allocates it to the program code as it needs it. This is why you can allocate like 4 GB of RAM to Minecraft and it will -lock- 4 GB of RAM from the os scheduling and yet minecraft may only be using 200 MB of it. A VM is a user controlled hog and will never compare to allocating memory bit by bit like a native code unmanaged program does. Why? Because it would be extremely ineffecient to reallocate memory through the program, through the VM, then through the OS with every damn allocation. So they skip a step and grab a banana bunch.
simple example, String:
each String has a class instance (requires memory for an object header and object payload, consisting of several fields);
lots of temporary String instances are created;
they store their characters in an array (requiring a secondary object head);
the arrays are UTF-16 (so the characters use up on-average ~ 2x as much space as if they were UTF-8, noting that "most" strings tend to consist primarily of ASCII characters, and for most common scripts it is break-even).
whereas, for C-style strings:
typically the string is just the raw characters (+ terminator byte), located somewhere in memory.
these sorts of costs can add up...
Complete oversimplication, in practice cstyle strings are literally nothing but character arrays. Sure if you want to get down to it they're of course smaller and more basic, why? Because they're litterally just a goddamn array. Strings are useful because they're a class with methods for intelligent manipulation, they also store a constant reference for you work with even if the pointer that it is, is moved to a different string in memory when you change the string. It's basically saving you the work of manually recreating each variable and making a new array(which you have to do with c-strings anyway.) You're talking about a few more bytes for a world of ease and actually performance -increases- when you're talking about using string searching and replace methods and other crap. Basically the only meritable thing here is the object overhead, the rest of it is all huge improvements over c-strings, and a few bytes are worth it and negligent to performance.
this isn't to say that Java code goes slow, only that its memory footprint tends to be larger.
No, Java goes slow depending on the task. JIT helps for certain things but for others it really is just a pain in the ass, Java renders like ass because of a lot of factors related to the VM and it wasting time and space handling rendering commands libraries. I've found all the windowing code and stuff Java has to throw in seems to mess a lot with the actual performance of programs as well since it's basically adding yet another abstraction layer on top of the OS.
Java is a pretty fast language for most things but games is definitely one of its weakest points, not to say they can't be done it just is not an ideal tool by far.
There's really no real difference between function calls in generic C/C++ OpenGL and most wrappers like LWJGL, performance is where most of the hit is. The code itself is basically 1:1 the same. I think the main goal for a game programmers hould be to pick a language, learn it well, then move on to visual programming with some kind of games library to learn with. No need to jump right into straight OpenGL without a good reason.
personally I mostly prefer just using C, but C++ does have a few merits.
I know C pretty well, just off-hand I don't know of any good C or C++ tutorials, and wouldn't be inclined to go searching the internet and reviewing them to look for any good ones.
using C for game development is idiotic and outddated, C++ literally does everything better than C and anything it doesn't you can, surprise, write C code right into it no problem. C of course is not a dead language, it has a lot of merit for things like drivers or lower level code that may not need the robustness of C++ or dealing with its compilers and things, it's certainly a huge step above assembly. But using C over C++ for games or app development or anything is like pure grade A dumb ass stuff.
D has a big drawback in that it requires manual effort to interface it with existing libraries (as-in, people needing to rewrite the headers into a form the compiler can understand). it is also a much less common language as well.
D is not popular because it didn't do anything better than C++ enough to dethrone it or C, I'm not sure why people even recommend very under-utilized languages like this. It's like telling someone to go learn whitespace or brain****, more of a novely than anything that will net you a job or ever get you on a hobby team. Not many people out there are going to know D, or want to work with a person on it.
If you really knew what you were talking about you would know this is flat ass out wrong. RAM has a bus, it has to communicate with the CPU and RAM is actually a big bottleneck in why the CPU has to wait many times. Of course things like the hard drive are -much- slower but there is a reason that cache misses are a killer in applications, anyone acting like RAM is just instant lightspeed storage with no overhead really need to go read a lesson in how a CPU actually works with the registers and the ALU and all that. It literally is sending a highway message to the RAM everytime it has to set -anything- in it, or read -anything- in it. All tasks require CPU time one way or another because nothing in a computer operates without interfacing with the brain of the computer and wasting its time.
well, except that, usually there is the whole cache thing, so it isn't so much about total RAM use, but more about the size of its working set.
yes, the JVM often suffers here as well.
No the Java VM is inherently a RAM hog, it allocates a huge chunk of RAM(or a little chunk, depending on default program settings and stuff but you get the idea.) It allocates a chunk very similar to how a resizable array that just grown acts. Basically it allocates a chunk of RAM and whether the program is using it or not is completely irrelevent, it locks the memory for the VM program and allocates it to the program code as it needs it. This is why you can allocate like 4 GB of RAM to Minecraft and it will -lock- 4 GB of RAM from the os scheduling and yet minecraft may only be using 200 MB of it. A VM is a user controlled hog and will never compare to allocating memory bit by bit like a native code unmanaged program does. Why? Because it would be extremely ineffecient to reallocate memory through the program, through the VM, then through the OS with every damn allocation. So they skip a step and grab a banana bunch.
by "VM" I didn't mean "JVM".
consider, for example, Lua or Python.
many other VMs do grab memory in much smaller chunks, and use more compact representations for data.
many VMs also don't use the "leak lots of memory and GC when none is left" strategy either.
Complete oversimplication, in practice cstyle strings are literally nothing but character arrays. Sure if you want to get down to it they're of course smaller and more basic, why? Because they're litterally just a goddamn array. Strings are useful because they're a class with methods for intelligent manipulation, they also store a constant reference for you work with even if the pointer that it is, is moved to a different string in memory when you change the string. It's basically saving you the work of manually recreating each variable and making a new array(which you have to do with c-strings anyway.) You're talking about a few more bytes for a world of ease and actually performance -increases- when you're talking about using string searching and replace methods and other crap. Basically the only meritable thing here is the object overhead, the rest of it is all huge improvements over c-strings, and a few bytes are worth it and negligent to performance.
but, this was specifically about saving bytes, not about raw performance.
C style strings do save bytes vs the other options, which was the main point here.
if C-style strings are packed into a string-table, they are much more compact than if they were allocated as objects.
taken further is if a person makes use of specialized LZ-style compression to make string-tables smaller (at the cost of needing to decompress the string in order to make use of its value).
No, Java goes slow depending on the task. JIT helps for certain things but for others it really is just a pain in the ass, Java renders like ass because of a lot of factors related to the VM and it wasting time and space handling rendering commands libraries. I've found all the windowing code and stuff Java has to throw in seems to mess a lot with the actual performance of programs as well since it's basically adding yet another abstraction layer on top of the OS.
Java is a pretty fast language for most things but games is definitely one of its weakest points, not to say they can't be done it just is not an ideal tool by far.
I don't disagree here.
There's really no real difference between function calls in generic C/C++ OpenGL and most wrappers like LWJGL, performance is where most of the hit is. The code itself is basically 1:1 the same. I think the main goal for a game programmers hould be to pick a language, learn it well, then move on to visual programming with some kind of games library to learn with. No need to jump right into straight OpenGL without a good reason.
well, I was not saying that OpenGL was much different between them, but the language surrounding it is different.
not like knowing both is all that difficult though, considering that at least a lot of "core language" stuff roughly overlaps.
using C for game development is idiotic and outddated, C++ literally does everything better than C and anything it doesn't you can, surprise, write C code right into it no problem. C of course is not a dead language, it has a lot of merit for things like drivers or lower level code that may not need the robustness of C++ or dealing with its compilers and things, it's certainly a huge step above assembly. But using C over C++ for games or app development or anything is like pure grade A dumb ass stuff.
only really for people who hate on C...
but, I am not saying pure C, but more like mixed C and C++.
C does retain the advantage that the compiler goes a little faster, and in many regions of code a person may not necessarily have much need for C++ features, and in these cases falling back to plain C may make more sense.
more so if writing lots of back-end library code which needs to be callable from C or other non-C++ languages, so it would largely need to be 'extern "C"' anyways.
also it is also easier to write parsers for C, meaning it is easier to write certain kinds of automated tools for it (such as "co-compilers" and similar, which may also parse the code, and then spit out new code or data). (a lot of this code is pretty "tooled up", so isn't really straight/vanilla C, FWIW, but has much less nasty syntax than Objective-C at least...).
not that a library can't provide "special features" for C++ code, like, say, using the vector code from C++ provides a bunch of methods and overloaded operators, which don't exist in the plain C version (where instead a person uses function calls or similar).
yeah, for front-end code, C++ makes a lot more sense.
the main reason I don't use it more at present is mostly for the pain it would be to really support the C++ ABI from my scripting-language, so any region of code written in straight C++ is largely invisible as far as the scripting language is concerned (except as far as it provides a C-callable API). this is a harder sell as at this point there is almost as much script-language code in the project as there is C++ code. so, it is basically a 3-way split language wise.
the main merit the script language has is that it can load itself directly from source-files, be edited at runtime, and has 'eval'.
a drawback though is that its performance is a bit worse than either C or C++ (limiting its use in performance-critical areas), and the implementation lacks maturity (write code, sometimes stumble on compiler bugs, ...).
D is not popular because it didn't do anything better than C++ enough to dethrone it or C, I'm not sure why people even recommend very under-utilized languages like this. It's like telling someone to go learn whitespace or brain****, more of a novely than anything that will net you a job or ever get you on a hobby team. Not many people out there are going to know D, or want to work with a person on it.
I'm specifically looking for game programming. I know game theory, but since I don't know C++, (Java is terrible for games...), I haven't been able to apply it very well. Are there any decent resources, tutorials, books, eBooks, or something of the sort that I could use?
Want a place to advertise your Minecraft server? try MyMCStatus.net now!
It's not optimized to do that. It also runs a VM when you run the Java environment, which is a huge RAM hog.
Having interpreted code is actually not a RAM hog it uses CPU to compile it and with JIT compilers this is really non issue it uses a bit more ram to store the byte code copy but its a non issue.
Java can be compiled to machine code like c++ if you are some twisted insane person who wants to remove pretty much the only large advantage Java has and that's ability to use the same .jar file for Linux OSX Windows FreeBSD without issue(for the most part).
don't know of any specific tutorials though.
(not really looked into them, as I already know how to write code...).
was looking and found some of this:
http://en.wikipedia.org/wiki/C++
http://en.wikipedia.org/wiki/Comparison_of_Java_and_C++
probably doesn't help specifically though.
checking YouTube for "C++ tutorial" turns up lots of stuff, dunno if any are good.
luckily, it probably shouldn't be too hard to apply knowledge from one to the other...
granted, yes, what is provided by the libraries is very different though, and there is a lot that will probably be new.
Helps a bit, but not really...
I'm mostly interested in 2D game creation. I have a lead, so I'll see where it goes.
this statement doesn't really make sense.
but, most evidence is that the JVM does use a bit of RAM though, but this has more to do with how its memory management works (some people blame GC in general, but this isn't really right either, lack of either pass-by-value semantics or delete is probably a bigger issue here...).
for some apps, it doesn't matter so much, but for others it does.
whether or not this has much effect on performance is a secondary matter.
ironically, this hasn't turned out to really be a big issue in-general.
if people can recompile for any popular targets, then the downside of not being able to run the same binary is not as big of an issue (more so that on many targets JARs just don't "look" like native binaries).
so, having it look more like a native program may be more of an advantage than having a JAR.
otherwise, as for C and C++, these give more direct access to OS APIs, which can be more helpful for things like games and similar.
besides generic language stuff, maybe looking into SDL and OpenGL could also make sense.
http://en.wikipedia.org/wiki/Simple_DirectMedia_Layer
http://en.wikipedia.org/wiki/OpenGL
these would be for sound and graphics and similar...
Not only that but the compilers are designed to optimize C/C++ code and that optimization will just not be there even ignoring the tags and keywords that other languages work off of, it's like trying to stuff a pancake into a box made for a coffee cup.
Ignoring that, if you want to make games I'd highly recommend starting with SDL or (preferably)SFML.
What I meant was just because its using a VM does not make it a ram hog It used to have a lot of CPU overhead but thanks to JIT that is a non issue.
Take c# as an example mono to be blunt is pretty dam terrible.
My suggestion is if you know Java already why not learn to make a game and learn OpenGL under it rather then learning C++ then learning OpenGL rendering ect.
I am not a big fan of C++ I would recommend D over it if not for the fact D lacks the sheer amount of books and documentation that C++ has.
If you want to turn this into a career yes learn C++ I am just saying Java is not that bad and if you know it already run with it and use LWJGL to create a basic game in a language you know. This assuming you know Java well if you have a basic knowledge go ahead and switch.
except:
RAM use and CPU overhead are not the same thing (time and space are not exactly the same thing).
and, it is not that VMs are inherently RAM-hogs either, it is just, Java uses *lots* of memory for things which "seemed like a good idea at the time".
simple example, String:
each String has a class instance (requires memory for an object header and object payload, consisting of several fields);
lots of temporary String instances are created;
they store their characters in an array (requiring a secondary object head);
the arrays are UTF-16 (so the characters use up on-average ~ 2x as much space as if they were UTF-8, noting that "most" strings tend to consist primarily of ASCII characters, and for most common scripts it is break-even).
whereas, for C-style strings:
typically the string is just the raw characters (+ terminator byte), located somewhere in memory.
these sorts of costs can add up...
this isn't to say that Java code goes slow, only that its memory footprint tends to be larger.
comparing something mediocre to terrible (and unrelated) does not make for a strong argument.
a person could do either one.
although porting code between them is kind of a pain, it isn't really difficult for a programmer to know both and move between one and the other as-needed.
personally I mostly prefer just using C, but C++ does have a few merits.
I know C pretty well, just off-hand I don't know of any good C or C++ tutorials, and wouldn't be inclined to go searching the internet and reviewing them to look for any good ones.
D has a big drawback in that it requires manual effort to interface it with existing libraries (as-in, people needing to rewrite the headers into a form the compiler can understand). it is also a much less common language as well.
the OP can do this if he wants.
4 GB of DDR3 RAM is quickly becoming the standard. The RAM hog that used 1 GB of RAM last year now uses a completely normal amount of RAM for most people.
If you really knew what you were talking about you would know this is flat ass out wrong. RAM has a bus, it has to communicate with the CPU and RAM is actually a big bottleneck in why the CPU has to wait many times. Of course things like the hard drive are -much- slower but there is a reason that cache misses are a killer in applications, anyone acting like RAM is just instant lightspeed storage with no overhead really need to go read a lesson in how a CPU actually works with the registers and the ALU and all that. It literally is sending a highway message to the RAM everytime it has to set -anything- in it, or read -anything- in it. All tasks require CPU time one way or another because nothing in a computer operates without interfacing with the brain of the computer and wasting its time.
No the Java VM is inherently a RAM hog, it allocates a huge chunk of RAM(or a little chunk, depending on default program settings and stuff but you get the idea.) It allocates a chunk very similar to how a resizable array that just grown acts. Basically it allocates a chunk of RAM and whether the program is using it or not is completely irrelevent, it locks the memory for the VM program and allocates it to the program code as it needs it. This is why you can allocate like 4 GB of RAM to Minecraft and it will -lock- 4 GB of RAM from the os scheduling and yet minecraft may only be using 200 MB of it. A VM is a user controlled hog and will never compare to allocating memory bit by bit like a native code unmanaged program does. Why? Because it would be extremely ineffecient to reallocate memory through the program, through the VM, then through the OS with every damn allocation. So they skip a step and grab a banana bunch.
Complete oversimplication, in practice cstyle strings are literally nothing but character arrays. Sure if you want to get down to it they're of course smaller and more basic, why? Because they're litterally just a goddamn array. Strings are useful because they're a class with methods for intelligent manipulation, they also store a constant reference for you work with even if the pointer that it is, is moved to a different string in memory when you change the string. It's basically saving you the work of manually recreating each variable and making a new array(which you have to do with c-strings anyway.) You're talking about a few more bytes for a world of ease and actually performance -increases- when you're talking about using string searching and replace methods and other crap. Basically the only meritable thing here is the object overhead, the rest of it is all huge improvements over c-strings, and a few bytes are worth it and negligent to performance.
No, Java goes slow depending on the task. JIT helps for certain things but for others it really is just a pain in the ass, Java renders like ass because of a lot of factors related to the VM and it wasting time and space handling rendering commands libraries. I've found all the windowing code and stuff Java has to throw in seems to mess a lot with the actual performance of programs as well since it's basically adding yet another abstraction layer on top of the OS.
Java is a pretty fast language for most things but games is definitely one of its weakest points, not to say they can't be done it just is not an ideal tool by far.
There's really no real difference between function calls in generic C/C++ OpenGL and most wrappers like LWJGL, performance is where most of the hit is. The code itself is basically 1:1 the same. I think the main goal for a game programmers hould be to pick a language, learn it well, then move on to visual programming with some kind of games library to learn with. No need to jump right into straight OpenGL without a good reason.
using C for game development is idiotic and outddated, C++ literally does everything better than C and anything it doesn't you can, surprise, write C code right into it no problem. C of course is not a dead language, it has a lot of merit for things like drivers or lower level code that may not need the robustness of C++ or dealing with its compilers and things, it's certainly a huge step above assembly. But using C over C++ for games or app development or anything is like pure grade A dumb ass stuff.
D is not popular because it didn't do anything better than C++ enough to dethrone it or C, I'm not sure why people even recommend very under-utilized languages like this. It's like telling someone to go learn whitespace or brain****, more of a novely than anything that will net you a job or ever get you on a hobby team. Not many people out there are going to know D, or want to work with a person on it.
well, except that, usually there is the whole cache thing, so it isn't so much about total RAM use, but more about the size of its working set.
yes, the JVM often suffers here as well.
by "VM" I didn't mean "JVM".
consider, for example, Lua or Python.
many other VMs do grab memory in much smaller chunks, and use more compact representations for data.
many VMs also don't use the "leak lots of memory and GC when none is left" strategy either.
but, this was specifically about saving bytes, not about raw performance.
C style strings do save bytes vs the other options, which was the main point here.
if C-style strings are packed into a string-table, they are much more compact than if they were allocated as objects.
taken further is if a person makes use of specialized LZ-style compression to make string-tables smaller (at the cost of needing to decompress the string in order to make use of its value).
I don't disagree here.
well, I was not saying that OpenGL was much different between them, but the language surrounding it is different.
not like knowing both is all that difficult though, considering that at least a lot of "core language" stuff roughly overlaps.
only really for people who hate on C...
but, I am not saying pure C, but more like mixed C and C++.
C does retain the advantage that the compiler goes a little faster, and in many regions of code a person may not necessarily have much need for C++ features, and in these cases falling back to plain C may make more sense.
more so if writing lots of back-end library code which needs to be callable from C or other non-C++ languages, so it would largely need to be 'extern "C"' anyways.
also it is also easier to write parsers for C, meaning it is easier to write certain kinds of automated tools for it (such as "co-compilers" and similar, which may also parse the code, and then spit out new code or data). (a lot of this code is pretty "tooled up", so isn't really straight/vanilla C, FWIW, but has much less nasty syntax than Objective-C at least...).
not that a library can't provide "special features" for C++ code, like, say, using the vector code from C++ provides a bunch of methods and overloaded operators, which don't exist in the plain C version (where instead a person uses function calls or similar).
yeah, for front-end code, C++ makes a lot more sense.
the main reason I don't use it more at present is mostly for the pain it would be to really support the C++ ABI from my scripting-language, so any region of code written in straight C++ is largely invisible as far as the scripting language is concerned (except as far as it provides a C-callable API). this is a harder sell as at this point there is almost as much script-language code in the project as there is C++ code. so, it is basically a 3-way split language wise.
the main merit the script language has is that it can load itself directly from source-files, be edited at runtime, and has 'eval'.
a drawback though is that its performance is a bit worse than either C or C++ (limiting its use in performance-critical areas), and the implementation lacks maturity (write code, sometimes stumble on compiler bugs, ...).
I was not exactly recommending D.
a "major drawback" isn't exactly a merit.