C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  C++ sucks for games Goto page 1, 2, 3 ... 51, 52, 53  Next          C++Talk.NET Forum Index -> C++ language (comp.lang.c++) View previous topic :: View next topic   Author Message Neo-LISPer Guest Posted: Mon Oct 25, 2004 12:11 pm    Post subject: C++ sucks for games Hey Recently, I researched using C++ for game programming and here is what I found: C++ game developers spend a lot of their time debugging corrupted memory. Few, if any, compilers offer completely safe modes. Unsurprisingly, there is a very high failure rate among projects using C++ for modern game development. You can not even change function definitions while the program is running and see the effects live (the ultimate debugging tool). Alternatively, you can't execute a small portion of the program without compiling and linking the whole thing, then bringing your game into a specific state where your portion of the code is being executed. The static type system locks you into a certain design, and you can't *test* new ideas, when they come to you, without redesigning your whole class hierarchy. C++ is so inflexible, even those who do use it for games, have to write their game logic in some other language (usually very slow, inexpressive and still garbage collected). They also have to interface the two languages. C++ lacks higher-order functions. Function objects emulate them poorly, are slow and a pain to use. Additionally, C++ type system does not work well with function objects. C++ programs can not "think" of new code at run-time, and plug that new code into themselves in compiled form. Not easily, anyway. C++ coding feels very repetitive, for example, when writing class accessors, you often have to write const and non-const methods with completely identical function bodies. Just look at STL. When programming in C++ you feel like a blind person trying to draw something. You don't _see_ the data structures that your procedures will operate on. Lisp programming is much more visual. Constructors and smart pointers make it hard to tell cheap operations from expensive ones. C++ lacks automatic memory management and so it encourages copying objects around to make manual memory management manageable. Reference-counting schemes are usually slower than modern garbage collectors and also less general. Most important, C++ syntax is irregular, and you often find yourself typing repetitive patterns again and again - a task easily automated in languages with simpler syntax. There are even books on C++ patterns, and some C++ experts take pride in being able to execute those patterns with computer-like precision - something a computer should be doing to begin with. C++ programs are slow: even though the compilers are good at micro-optimizing the code, programmers waste their time writing repetitive patterns in C++ and debugging memory corruption instead of looking for better algorithms that are far more important for speed than silly micro-optimizations. It's hard to find good programmers for C++ projects, because most of the good programmers graduated to languages like Lisp or avoided C++ altogether. C++ attracts unimaginative fellows with herd mentality. For creative projects, you want to avoid them like a plague. It is my opinion that all of the above makes C++ a very bad choice for commercial game development. Back to top Nils O. Selåsdal Guest Posted: Mon Oct 25, 2004 12:14 pm    Post subject: Re: C++ sucks for games Neo-LISPer wrote: Quote: Hey ... creative projects, you want to avoid them like a plague. Quote: It is my opinion that all of the above makes C++ a very bad choice for commercial game development. My opinion to others: Do not feed the trolls. Please! Back to top Maahes Guest Posted: Mon Oct 25, 2004 12:24 pm    Post subject: Re: C++ sucks for games hmm. I remember vividly doing lisp at uni. I think the assignment was a simple long division problem. I remember that only a few people in the entire class managed to work out a way of achieving it... I problem that is a newbie would do in C without breaking a sweat. After that, no-one ever used lisp again... ...except the Jax & Daxter developers. Their game engine runs on an interpretted lisp platform (I believe) and has spawned some of the most impressive platformers I've ever seen... So the moral is.... I don't know, but I won't be switching to Lisp any time soon... Maybe its good once you get the hang of it... But I think it may be too recursive & bottom-up programming for most brains to want to deal with... "Neo-LISPer" <neo_lisper (AT) yahoo (DOT) com> wrote Quote: Hey Recently, I researched using C++ for game programming and here is what I found: C++ game developers spend a lot of their time debugging corrupted memory. Few, if any, compilers offer completely safe modes. Unsurprisingly, there is a very high failure rate among projects using C++ for modern game development. You can not even change function definitions while the program is running and see the effects live (the ultimate debugging tool). Alternatively, you can't execute a small portion of the program without compiling and linking the whole thing, then bringing your game into a specific state where your portion of the code is being executed. The static type system locks you into a certain design, and you can't *test* new ideas, when they come to you, without redesigning your whole class hierarchy. C++ is so inflexible, even those who do use it for games, have to write their game logic in some other language (usually very slow, inexpressive and still garbage collected). They also have to interface the two languages. C++ lacks higher-order functions. Function objects emulate them poorly, are slow and a pain to use. Additionally, C++ type system does not work well with function objects. C++ programs can not "think" of new code at run-time, and plug that new code into themselves in compiled form. Not easily, anyway. C++ coding feels very repetitive, for example, when writing class accessors, you often have to write const and non-const methods with completely identical function bodies. Just look at STL. When programming in C++ you feel like a blind person trying to draw something. You don't _see_ the data structures that your procedures will operate on. Lisp programming is much more visual. Constructors and smart pointers make it hard to tell cheap operations from expensive ones. C++ lacks automatic memory management and so it encourages copying objects around to make manual memory management manageable. Reference-counting schemes are usually slower than modern garbage collectors and also less general. Most important, C++ syntax is irregular, and you often find yourself typing repetitive patterns again and again - a task easily automated in languages with simpler syntax. There are even books on C++ patterns, and some C++ experts take pride in being able to execute those patterns with computer-like precision - something a computer should be doing to begin with. C++ programs are slow: even though the compilers are good at micro-optimizing the code, programmers waste their time writing repetitive patterns in C++ and debugging memory corruption instead of looking for better algorithms that are far more important for speed than silly micro-optimizations. It's hard to find good programmers for C++ projects, because most of the good programmers graduated to languages like Lisp or avoided C++ altogether. C++ attracts unimaginative fellows with herd mentality. For creative projects, you want to avoid them like a plague. It is my opinion that all of the above makes C++ a very bad choice for commercial game development. Back to top Hendrik Belitz Guest Posted: Mon Oct 25, 2004 12:31 pm    Post subject: Re: C++ sucks for games Neo-LISPer wrote: Quote: Some senseless stuff Besides your poor trolling attempts (most of your arguments just show that you have no knowledge of C++) you don't even tell us what the alternative to C++ in game programming could be. -- To get my real email adress, remove the two onkas -- Hendrik Belitz - Abort, Retry, Fthagn? - Back to top JKop Guest Posted: Mon Oct 25, 2004 1:08 pm    Post subject: Re: C++ sucks for games Quote: C++ game developers spend a lot of their time debugging corrupted memory. Few, if any, compilers offer completely safe modes. AKA Retarded mode. Quote: Unsurprisingly, there is a very high failure rate among projects using C++ for modern game development. There's a 90% failure rate for lions when hunting. They still eat. I would presume that that "very high failure rate" becomes a bit lower when you're dealing with proficient C++ programmers. Quote: You can not even change function definitions while the program is running and see the effects live (the ultimate debugging tool). Nothing to do with the language. Such a debugging tool could be developed, why not develop it? I myself wouldn't use it. Quote: Alternatively, you can't execute a small portion of the program without compiling and linking the whole thing, then bringing your game into a specific state where your portion of the code is being executed. That's because there's no such thing as "half a program". If you really want this, copy-paste it to another file and just append: int main(){} to the end of it. Quote: The static type system locks you into a certain design, and you can't *test* new ideas, when they come to you, without redesigning your whole class hierarchy. Bullshit. Vague bullshit. Quote: C++ is so inflexible, even those who do use it for games, have to write their game logic in some other language (usually very slow, inexpressive and still garbage collected). They also have to interface the two languages. Provide an example. I myself forsee no reason or motive to do or have to do this. Quote: C++ lacks higher-order functions. Function objects emulate them poorly, are slow and a pain to use. Additionally, C++ type system does not work well with function objects. "function objects". Get over it! It's just syntatic sugar! Quote: C++ programs can not "think" of new code at run-time, and plug that new code into themselves in compiled form. Not easily, anyway. "think of new code at run-time". That's because it takes intelligence to write code, something which computers lack. As for the code coming from somewhere else, well it's done extremely easily actually - we call it dynamic linkage. Quote: C++ coding feels very repetitive, for example, when writing class accessors, you often have to write const and non-const methods with completely identical function bodies. Just look at STL. Incorrect. If both function bodies are identical, then there's no need to write a non- const version. If there exists both a const version and a non-const version, then this indicates that one version alters the object, while the other doesn't. Conclusion: different code. You could also make the non-const version call the const version, and then just do something extra. Quote: When programming in C++ you feel like a blind person trying to draw something. You don't _see_ the data structures that your procedures will operate on. Lisp programming is much more visual. "procedures"? Never heard of them. I've heard of "functions" alright. I must say I don't... see... your argument, no pun intended. If you have a function which takes in an object of a certain class, or as you call it "data structure", then... (actually, it's so simple I'm not even going to finish this paragraph). Quote: Constructors and smart pointers make it hard to tell cheap operations from expensive ones. Bullshit. Vague bullshit. Quote: C++ lacks automatic memory management and so it encourages copying objects around to make manual memory management manageable. int auto k = 4; int* auto p_w = new int(4); Quote: Reference-counting schemes are usually slower than modern garbage collectors and also less general. Which "garbage collector"? "less general" = vague bullshit. Quote: Most important, C++ syntax is irregular, and you often find yourself typing repetitive patterns again and again - a task easily automated in languages with simpler syntax. I don't see your argument. I've never encountered such. Quote: There are even books on C++ patterns, and some C++ experts take pride in being able to execute those patterns with computer-like precision - something a computer should be doing to begin with. There's books on a lot of things. Quote: C++ programs are slow: even though the compilers are good at micro-optimizing the code, programmers waste their time writing repetitive patterns in C++ and debugging memory corruption instead of looking for better algorithms that are far more important for speed than silly micro-optimizations. Define "programmers". I myself don't fit into the inuendo of a definition in the above. Quote: It's hard to find good programmers for C++ projects, because most of the good programmers graduated to languages like Lisp or avoided C++ altogether. C++ attracts unimaginative fellows with herd mentality. For creative projects, you want to avoid them like a plague. MS-DOS was written in C++. Window XP was written in C++. Linux was written in C++. Come to think of it, what *wasn't* written in C++? Quote: It is my opinion that all of the above makes C++ a very bad choice for commercial game development. My opinion differs. -JKop Back to top Mikael Brockman Guest Posted: Mon Oct 25, 2004 1:16 pm    Post subject: Re: C++ sucks for games JKop <NULL (AT) NULL (DOT) NULL> writes: Quote: C++ game developers spend a lot of their time debugging corrupted memory. Few, if any, compilers offer completely safe modes. AKA Retarded mode. Unsurprisingly, there is a very high failure rate among projects using C++ for modern game development. There's a 90% failure rate for lions when hunting. They still eat. I would presume that that "very high failure rate" becomes a bit lower when you're dealing with proficient C++ programmers. You can not even change function definitions while the program is running and see the effects live (the ultimate debugging tool). Nothing to do with the language. Such a debugging tool could be developed, why not develop it? I myself wouldn't use it. Alternatively, you can't execute a small portion of the program without compiling and linking the whole thing, then bringing your game into a specific state where your portion of the code is being executed. That's because there's no such thing as "half a program". If you really want this, copy-paste it to another file and just append: int main(){} to the end of it. The static type system locks you into a certain design, and you can't *test* new ideas, when they come to you, without redesigning your whole class hierarchy. Bullshit. Vague bullshit. C++ is so inflexible, even those who do use it for games, have to write their game logic in some other language (usually very slow, inexpressive and still garbage collected). They also have to interface the two languages. Provide an example. I myself forsee no reason or motive to do or have to do this. C++ lacks higher-order functions. Function objects emulate them poorly, are slow and a pain to use. Additionally, C++ type system does not work well with function objects. "function objects". Get over it! It's just syntatic sugar! C++ programs can not "think" of new code at run-time, and plug that new code into themselves in compiled form. Not easily, anyway. "think of new code at run-time". That's because it takes intelligence to write code, something which computers lack. As for the code coming from somewhere else, well it's done extremely easily actually - we call it dynamic linkage. C++ coding feels very repetitive, for example, when writing class accessors, you often have to write const and non-const methods with completely identical function bodies. Just look at STL. Incorrect. If both function bodies are identical, then there's no need to write a non- const version. If there exists both a const version and a non-const version, then this indicates that one version alters the object, while the other doesn't. Conclusion: different code. You could also make the non-const version call the const version, and then just do something extra. When programming in C++ you feel like a blind person trying to draw something. You don't _see_ the data structures that your procedures will operate on. Lisp programming is much more visual. "procedures"? Never heard of them. I've heard of "functions" alright. I must say I don't... see... your argument, no pun intended. If you have a function which takes in an object of a certain class, or as you call it "data structure", then... (actually, it's so simple I'm not even going to finish this paragraph). Constructors and smart pointers make it hard to tell cheap operations from expensive ones. Bullshit. Vague bullshit. C++ lacks automatic memory management and so it encourages copying objects around to make manual memory management manageable. int auto k = 4; int* auto p_w = new int(4); Reference-counting schemes are usually slower than modern garbage collectors and also less general. Which "garbage collector"? "less general" = vague bullshit. Most important, C++ syntax is irregular, and you often find yourself typing repetitive patterns again and again - a task easily automated in languages with simpler syntax. I don't see your argument. I've never encountered such. There are even books on C++ patterns, and some C++ experts take pride in being able to execute those patterns with computer-like precision - something a computer should be doing to begin with. There's books on a lot of things. C++ programs are slow: even though the compilers are good at micro-optimizing the code, programmers waste their time writing repetitive patterns in C++ and debugging memory corruption instead of looking for better algorithms that are far more important for speed than silly micro-optimizations. Define "programmers". I myself don't fit into the inuendo of a definition in the above. It's hard to find good programmers for C++ projects, because most of the good programmers graduated to languages like Lisp or avoided C++ altogether. C++ attracts unimaginative fellows with herd mentality. For creative projects, you want to avoid them like a plague. MS-DOS was written in C++. Window XP was written in C++. Linux was written in C++. Come to think of it, what *wasn't* written in C++? Linux comes to mind. Back to top JKop Guest Posted: Mon Oct 25, 2004 1:25 pm    Post subject: Re: C++ sucks for games Quote: Come to think of it, what *wasn't* written in C++? Linux comes to mind. Really? What was it written in? -JKop Back to top Catalin Pitis Guest Posted: Mon Oct 25, 2004 1:29 pm    Post subject: Re: C++ sucks for games "JKop" <NULL (AT) NULL (DOT) NULL> wrote Quote: Come to think of it, what *wasn't* written in C++? Linux comes to mind. Really? What was it written in? C Also MSDOS and MS WIndows were developed in C, as far as I know. Catalin Back to top JKop Guest Posted: Mon Oct 25, 2004 1:31 pm    Post subject: Re: C++ sucks for games Catalin Pitis posted: Quote: "JKop" <NULL (AT) NULL (DOT) NULL> wrote in message news:o97fd.40000$Z14.14510 (AT) news (DOT) indigo.ie... Come to think of it, what *wasn't* written in C++? Linux comes to mind. Really? What was it written in? C Also MSDOS and MS WIndows were developed in C, as far as I know. Catalin HHHHHHaaaaaaaaaaaaaaaaa ha ha haaaaaaaaaaaaaaaaaaaaaaaa HHaaaaaaaaaaaaaaaaa HHHHHAaaaaaaaaaa ha ha ha OOOHhhhhhhhhh, it's too much. Didn't we switch from coal to oil yyeeaarrss ago? -JKop Back to top Catalin Pitis Guest Posted: Mon Oct 25, 2004 1:42 pm    Post subject: Re: C++ sucks for games "JKop" <NULL (AT) NULL (DOT) NULL> wrote Quote: Catalin Pitis posted: "JKop" <NULL (AT) NULL (DOT) NULL> wrote in message news:o97fd.40000$Z14.14510 (AT) news (DOT) indigo.ie... Come to think of it, what *wasn't* written in C++? Linux comes to mind. Really? What was it written in? C Also MSDOS and MS WIndows were developed in C, as far as I know. Catalin HHHHHHaaaaaaaaaaaaaaaaa ha ha haaaaaaaaaaaaaaaaaaaaaaaa HHaaaaaaaaaaaaaaaaa HHHHHAaaaaaaaaaa ha ha ha OOOHhhhhhhhhh, it's too much. Didn't we switch from coal to oil yyeeaarrss ago? -JKop It seems not :D Catalin Back to top Hendrik Belitz Guest Posted: Mon Oct 25, 2004 1:50 pm    Post subject: Re: C++ sucks for games Catalin Pitis wrote: Quote: "JKop" <NULL (AT) NULL (DOT) NULL> wrote in message news:o97fd.40000$Z14.14510 (AT) news (DOT) indigo.ie... Come to think of it, what *wasn't* written in C++? Linux comes to mind. Really? What was it written in? C Also MSDOS and MS WIndows were developed in C, as far as I know. Catalin You're totally correct in this. But most higher-order toolkits are written in C++. BTW: I don't know a single piece of "real" software that was written in LISP (AFAIK even Emacs only uses LISP as an extension and scripting language: Something that is really bad bevhaviour according to the original troll .. eerrh ... poster). I am also awaiting good examples for LISP 3D-Engines, LISP- OS kernels, LISP device drivers, LISP text processors or LISP numerical toolkits. Feel free to copy your whole project source code for these topics to your news-transfer-daemon /dev/null... -- To get my real email adress, remove the two onkas -- Hendrik Belitz - Abort, Retry, Fthagn? - Back to top Stefan Scholl Guest Posted: Mon Oct 25, 2004 1:57 pm    Post subject: Re: C++ sucks for games On 2004-10-25 15:08:22, JKop wrote: Quote: MS-DOS was written in C++. Window XP was written in C++. Linux was written in C++. You're funny! :-) Back to top Christopher Benson-Manica Guest Posted: Mon Oct 25, 2004 2:07 pm    Post subject: Re: C++ sucks for games In comp.lang.c++ JKop <NULL (AT) null (DOT) null> wrote: Quote: C++ game developers spend a lot of their time debugging corrupted memory. Few, if any, compilers offer completely safe modes. AKA Retarded mode. (inspired response to obvious troll) What part of "Do not feed the trolls" was hard to understand? -- Christopher Benson-Manica | I *should* know what I'm talking about - if I ataru(at)cyberspace.org | don't, I need to know. Flames welcome. Back to top cr88192 Guest Posted: Mon Oct 25, 2004 2:14 pm    Post subject: Re: C++ sucks for games "Catalin Pitis" <catalin.pitis (AT) iquestint (DOT) com.renameme> wrote Quote: "JKop" <NULL (AT) NULL (DOT) NULL> wrote in message news:o97fd.40000$Z14.14510 (AT) news (DOT) indigo.ie... Come to think of it, what *wasn't* written in C++? Linux comes to mind. Really? What was it written in? C Also MSDOS and MS WIndows were developed in C, as far as I know. afaik dos was assembler... Back to top Alex Drummond Guest Posted: Mon Oct 25, 2004 2:22 pm    Post subject: Re: C++ sucks for games Disclaimer: I don't dislike C++, but the responses to the OP's (mostly valid) criticisms are pretty uninformed. Quote: The alternative, garbage collection, tends to corrupt memory too. Have you heard of a high-availability Visual Basic program? Game programmers need efficient and deterministic garbage collection. If they don't code it themselves, following healthy styles, they will corrupt memory. Erm no, garbage collection does not corrupt memory unless the garbage collector is buggy. Have you ever seen a VB program segfault? If you have special requirements for garbage collection, you just need a garbage collector tuned to your requirements (e.g. the real-time garbage collectors available in some implementations of various languages). Quote: Alternatively, you can't execute a small portion of the program without compiling and linking the whole thing, then bringing your game into a specific state where your portion of the code is being executed. Test isolation would help that. If objects are decoupled, you can write a test that plays with only one of them. Playing with unit test cases, and adding them very easily, is a great way to preserve all those little experiments, and convert them into constraints. Unit tests help you to /test/ code, but not to debug it. When you've found a bug, you still need to do the work of actually fixing the code. This is much easier if you have an environment which supports dynamic redefinition and interative compilation. Quote: The static type system locks you into a certain design, and you can't *test* new ideas, when they come to you, without redesigning your whole class hierarchy. Then don't use the static type system. Not using the static type system would entail not using C++ (unless you intend to represent all your data as void * and fill your program with casts). Quote: C++ is so inflexible, even those who do use it for games, have to write their game logic in some other language (usually very slow, inexpressive and still garbage collected). They also have to interface the two languages. You make that sound like a bad thing. Most programs have two languages (consider the glorious union of VB and SQL). Games need a scripting layer to decouple designing the game play from its engine. Most other applications with an engine use this model, too. Clearly a separate scripting language is not desirable if you can avoid it (performance and code overhead from interfacing the two languages, being constrained by an enforced separation between interelated parts of the program, etc.) It is difficult to avoid having a separate scripting language in C++ because it doesn't support incremental compilation. It's certainly not impossible to avoid it (Half-Life doesn't have one, for example), but you pay the price: make a trivial mistake in your Half-Life mod code and the fix-reload-test cycle can be a couple of minutes long. Quote: When programming in C++ you feel like a blind person trying to draw something. You don't _see_ the data structures that your procedures will operate on. Lisp programming is much more visual. That's because you are familiar with Lisp. Indeed, it's much easier to express complex data structures in Lisp. Quote: C++ lacks higher-order functions. Function objects emulate them poorly, are slow and a pain to use. Additionally, C++ type system does not work well with function objects. So what? It also makes the Prototype Pattern a pain in the nuts. These issues are not in the domain, they are just implementation alternatives. This makes no sense. Higher order functions are a win, period. Function objects are just less powerful than higher order functions (assuming that these functions are closures). If you've been paying attention to R&D in programming languages for the past 20-30 years, you'll notice that higher order functions are one abstraction mechanism that just about every new language has adopted (often prior to the development of C++). They're so useful that some people have invested a lot of time into hacking some kind of HOF facility into C++ (c.f. the Boost Lambda Library). Quote: C++ lacks automatic memory management and so it encourages copying objects around to make manual memory management manageable. Reference-counting schemes are usually slower than modern garbage collectors and also less general. Prefer pass-by-reference above all other kinds, because its cognitively efficient and usually execution efficient. "Usually" being the operative word. You're also missing the OP's point completely. If you pass by reference, you enormously increase the complexity of your memory management code. Sure, C++ has lots of ways to encapsulate this complexity, but you still have to deal with it, and the common methods of doing this amount to using a buggy and rather inefficient GC. Alex Phlip wrote: Quote: "Neo-LISPer" <neo_lisper (AT) yahoo (DOT) com> wrote in message news:87k6tf9ev3.fsf (AT) yahoo (DOT) com... Hey Recently, I researched using C++ for game programming and here is what I found: As other industries using C++ - even for highly graphical, rich-content physics simulations - report fewer of these problems, the game programming culture itself might be to blame. C++ game developers spend a lot of their time debugging corrupted memory. Few, if any, compilers offer completely safe modes. The alternative, garbage collection, tends to corrupt memory too. Have you heard of a high-availability Visual Basic program? Game programmers need efficient and deterministic garbage collection. If they don't code it themselves, following healthy styles, they will corrupt memory. Unsurprisingly, there is a very high failure rate among projects using C++ for modern game development. That's because there's a high failure rate period, and most games use C++. You can not even change function definitions while the program is running and see the effects live (the ultimate debugging tool). There are those who don't need to debug. The game programming industry has only begun to adopt unit testing in a very few shops. Alternatively, you can't execute a small portion of the program without compiling and linking the whole thing, then bringing your game into a specific state where your portion of the code is being executed. Test isolation would help that. If objects are decoupled, you can write a test that plays with only one of them. Playing with unit test cases, and adding them very easily, is a great way to preserve all those little experiments, and convert them into constraints. The static type system locks you into a certain design, and you can't *test* new ideas, when they come to you, without redesigning your whole class hierarchy. Then don't use the static type system. C++ is so inflexible, even those who do use it for games, have to write their game logic in some other language (usually very slow, inexpressive and still garbage collected). They also have to interface the two languages. You make that sound like a bad thing. Most programs have two languages (consider the glorious union of VB and SQL). Games need a scripting layer to decouple designing the game play from its engine. Most other applications with an engine use this model, too. C++ lacks higher-order functions. Function objects emulate them poorly, are slow and a pain to use. Additionally, C++ type system does not work well with function objects. So what? It also makes the Prototype Pattern a pain in the nuts. These issues are not in the domain, they are just implementation alternatives. C++ programs can not "think" of new code at run-time, and plug that new code into themselves in compiled form. Not easily, anyway. So, uh, use the scripting layer? C++ coding feels very repetitive, for example, when writing class accessors, you often have to write const and non-const methods with completely identical function bodies. Just look at STL. It sounds like you need to tell us you are less than perfectly adept at C++. Have you used it for games? When programming in C++ you feel like a blind person trying to draw something. You don't _see_ the data structures that your procedures will operate on. Lisp programming is much more visual. That's because you are familiar with Lisp. Constructors and smart pointers make it hard to tell cheap operations from expensive ones. All cheap and expensive operations are impossible to predict and hard to tell apart. Profile. C++ lacks automatic memory management and so it encourages copying objects around to make manual memory management manageable. Reference-counting schemes are usually slower than modern garbage collectors and also less general. Prefer pass-by-reference above all other kinds, because its cognitively efficient and usually execution efficient. Most important, C++ syntax is irregular, and you often find yourself typing repetitive patterns again and again - a task easily automated in languages with simpler syntax. There are even books on C++ patterns, and some C++ experts take pride in being able to execute those patterns with computer-like precision - something a computer should be doing to begin with. C++ syntax is somewhat irregular. But it's lack of a 'read_mind' keyword disturbs me most. C++ programs are slow: even though the compilers are good at micro-optimizing the code, programmers waste their time writing repetitive patterns in C++ and debugging memory corruption instead of looking for better algorithms that are far more important for speed than silly micro-optimizations. How could that complaint be specific to C++? It's hard to find good programmers for C++ projects, because most of the good programmers graduated to languages like Lisp or avoided C++ altogether. C++ attracts unimaginative fellows with herd mentality. For creative projects, you want to avoid them like a plague. That's because educating someone to write low-risk C++ is difficult. Vendors have clogged our markets with low-quality languages that purport to allow inept programmers to write code at a lower risk than C++ provides. Games must have high performance, so C++ is the leading language for now. Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ language (comp.lang.c++) All times are GMT Goto page 1, 2, 3 ... 51, 52, 53  Next Page 1 of 53   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.