Transition to c++?
BlitzMax Forums/BlitzMax Programming/Transition to c++?
| ||
| Hey Guys, Looking for some advice. Blitz3D was my introduction to programming several years ago and was the reason I fell in love with programming. Since then I've learned BlitzMAX, c# and a few other languages and now I'd like to tackle c++. c++ seems like the standard language for professional game development and upon developing my game engine the source could we be more usable for professionals if it were to be written in c++. Should I transition? Is moving from BlitzMAX to c++ difficult? What are the primary differences? Thanks |
| ||
| Hello, Best way to answer that is to try will and go for the basics in C++. The differences are many, quite many to mention here. But the most important ones (I think) for you that come From Bmax are that Bmax uses a Garbage Collector (i.e. automatic memory handling) while C++ does not, that the members of the class have degrees of protection (public, private, etc) and that you have to do separate files for the classes, one for the definition or interface of the class (.h) declaring members and member function headers, and other file where you actually write the code for the member functions. It's a long way tho, to start in C++. Is a beast of a language, complex, with pitfalls but very powerful. |
| ||
| Just do it! And when you're done you wont regret it! |
| ||
| c++ seems like the standard language for professional game development and upon developing my game engine the source could we be more usable for professionals if it were to be written in c++. Should I transition? Is moving from BlitzMAX to c++ difficult? What are the primary differences? The one-word answers are "no", "yes" and "lots". First and foremost, do not transition because you want to be more "standard". This is only of even the slightest use if you intend to be sharing work at the source-level, i.e. either open-source projects or full code-licensing. If you intend to sell binary blobs the way most people here do, C++ is almost completely unusable, because it does not obey any kind of ABI standardisation. The only languages to use for interfacing with other code in a standard way are C, and anything that explicitly says it uses a C-compatible FFI (yes, C++ can export C-compatible names using 'extern "C"', but that's arguably more hassle than using C itself). Secondly, if you're not going to be sharing work at the source-level, there's no reason why your code has to be written with the same standards in mind as the code of your clients, because they will never see it. Your production standards become the only thing of any significance in that scenario. Thirdly, <opinion>the language itself is not worth using.</opinion> It's a hacked-together disjointed mess of parts that don't work properly together. There is no significant performance boost over using other super-optimised languages (i.e. to write C++ code that's as fast as C, you have to drop all the ++ parts anyway), while there is a vast increase in the number of bugs you're able to introduce since the language is nigh-unreadable even to experts (even to machines! C++ has an undecidable grammar!), and provides literally zero support for memory management or memory safety. You are almost guaranteed to be an order of magnitude less productive in C++ than in more high-level languages due to the ever-present need to hunt down and fix memory bugs (various academic studies put the figure at around 20x less productivity compared to a language like OCaml or Scheme). Fourthly, C++'s features suck, to be brutally honest. Its attempts at adding high-level features are mostly either nonsensical or incomplete (e.g. its exception system doesn't work in a way even slightly useful to a high-level programmer; its multiple-inheritance system was designed by someone who, bluntly, didn't understand OOP; its template system tries to actively hurt performance of generic programs and is a mockery of real metaprogramming; there is no GC of any sort). Fifthly, you do not need C++'s features (summed up: adding high-level "stuff" to C). You'll end up with a far safer and probably more consistent and readable program if you simply write in a high-level language and port out the performance bottlenecks to C, one function at a time, after profiling. If you want to take advantage of both worlds (high level management with low-level micromanagement), pick two tools that can actually do each one well and integrate them with one another. e.g. Lua or Guile are designed to be integrated directly with C code. However, many high-level languages will surprise you with the speed they can actually deliver (e.g. Java, Haskell, and LinearML have all been demonstrated to be able to outperform C and C++ if the code is well-written). Performance is provided by a compiler's optimiser, not usually by hand-coded tweaks. Basically, in the modern era, there is precisely one reason to learn C++ and that is if you need to work on existing C++ code. Creating new C++ code is almost a socially irresponsible act: we have enough wasted programmer time and bugs to fix as it is. If you aren't required to work on existing C++ code, that's probably a good thing, since the majority of C++ coders are also low-paid bottom-tier workers. Yes, that too is a game industry standard, but the game industry's standards are not really something to look up to for the most part. There are plenty, plenty of good alternatives to C++ for use at the moment. e.g.: - C (really) - D (edit: thanks ziggy) - Java (on desktop) - OCaml - Haskell - Vala - Common Lisp - Objective-C (is still at least as useful on Windows/Linux as raw C++ is) With the exception of C and Objective-C, these are really high-level enough that you can probably ignore the two-layer suggestion above. And of course there are any number of others; and those are only the superfast ones. I dislike C++, and have made that fairly clear around here in the past, so my comments should be seen as biased. However, I would not make them if I did not believe they were true. My TL;DR advice is that it is never in an indie or small developer's best interests to work in C++, and unnecessary to have more than a reading knowledge of the language. Last edited 2012 |
| ||
| @Yasha What do you think about c++11 ? Same thing or a better iteration. |
| ||
| It's not quite as bad as Yasha makes out. I just use it in the same way as I use BlitzMax - just learn the C++ syntax for the equivalent BlitzMax language features, and you're away. You don't have to use everything in the language, just what you need to. As for memory management, you can use boost pointers which pretty much takes care of it all, or you can just remember to 'delete' everything you 'new'! For small scale projects such as your typical indie/hobbyist game, this isn't such a burden. If you want to write native, object-oriented game code for iOS, Android, and Windows Phone 8, then C++ is your only choice. Also, if you want a programming job in the games industry, you will pretty much have to know it. |
| ||
| @Yasha What do you think about c++11 ? Same thing or a better iteration. I think it adds a lot of cool features, which can be used to write code that is certainly nicer to look at than C++98 ("auto", new function syntax, lambdas, "constexpr", initializer lists are all very nice features). However, the core of C++98 is still there with all of the same problems, and the large selection of new syntax makes the language even more complicated to read, and potentially even more bug-prone as a result. The new features themselves also seem to have been added in the same haphazard way as the original feature set... lots of redundancy, lots of genericity of design without forcing the language to actually have a form of its own (e.g. the multiple types of broken-by-default lambda, showcasing the same sort of disregard for FP that the inheritance system does for OOP). Fundamentally it's more of the same. That means it adds more good stuff, just like most people are happy about the way it originally added an object system to C; but also more confusion. If the language keeps evolving in this direction, though, it could get a lot better. It's definitely absorbing good ideas, and showing signs of a proper divergence with C now, which is important if it ever wants to become "safe". EDIT: wow I spent a long time typing that. Last edited 2012 |
| ||
| To the list of good alternatives to C++ I would put at the top of the list the D programming language. It's wonderful and highly advisable on its current status. |
| ||
| I avoided C because if you go out of bounds of an array the compiler or program doesnt tell you, so I created a macro that helps #define sizeofarray(x) sizeof(x)/sizeof(x[0]) #define arrayvalue(arr,pos) sizeofarray(arr)>pos ? (arr[pos]) : 0 #define setarray(arr,pos,val) sizeofarray(arr)>pos ? (arr[pos]=val) : printf("tried to set array out of bounds %d\n",pos) arrayvalue simply gets the value and returns zero if the position is out of bounds setarray prints an error message if you try to set a position that is out of bounds |
| ||
Important change:#define arrayvalue(arr,pos) ( sizeofarray(arr)>(pos) ? (arr[pos]) : 0 )
#define setarray(arr,pos,val) ( sizeofarray(arr)>(pos) ? (arr[pos]=val) : printf("tried to set array out of bounds %d\n",pos) )Parentheses around the whole macro body, and pos. Otherwise, when you try to use the macro in the same way as the [] operator like this: int x = 1 - myArray[9]; // Assuming myArray has 20 elements and [9] has value 42, x == 41 int y = 1 - arrayvalue(myArray, 9); // Same values, y == 0 using the original definition of arrayvalue Always, always force precedence with parentheses in macro expressions, because there are nasty pitfalls. Remember that the macro expands to exactly what you wrote, not a "complete" expression like an inlined function would. |
| ||
| yes very true thanks |
   |