|
I've made a couple different posts about game programming, though everyone that read them seemed to not really know how to piece everything together to finally get off the ground writing their own game within the Windows Console.
I've been creating a series of posts back at my blog about creating a Window's console game from scratch in C. This post will act as a culmination of many different posts throughout my blog in the form of an open source game engine called AsciiEngine.
AsciiEngine is a free open source game engine for Windows XP, Vista, and Win7 that allows the user to easily create and display images within a Windows console. The engine also automates the tedious task of customizing aspects of the console, such as a font or palette color. By using AsciiEngine, users can easily construct interactive programs (games!) without the overhead of setting up all of the various system components required to run a game within the Windows console.
AsciiEngine actually runs within the Windows console. No GDI or anything, just displaying colored text within the console! This makes for a very interesting way to create games. I feel coding a game in the Windows console is a wonderful way for beginning programmers to take off in creating something very cool without using black box libraries; if you make a game in the console on your own you really should understand everything that's going on in your program. AsciiEngine intends to provide a good reference point for anyone trying to make something from scratch on their own, as well as a jumping off point for others who don't want to necessarily learn all of what's going on to get things up and running in the Console.
Screenshot of the AsciiEngine demo. Pressing enter pastes sun images onto random locations.
Features include:
- Game loop integrated into Game State Manager via function pointers
- Game State Manager
- Simple framerate controller
- Various console related functions for easy customization of the console window
- Complete graphics function set for drawing 2D images
- Input template complete for simple keystroke detection
- Simple image format that allows for variable size
- Integrated hash table for storing images
- Extremely simple creation/deletion of images
- Implementation of my simple 2D collision library
- Implementation of my simple 2D vector library
- Highly organised object manager using the factory pattern
- Allows for easy creation/handling/deletion of game objects
- Incredibly simple to create new object types
I can recall a time in the past when I first started programming. A lot of my troubles stemmed from figuring out how all the basic programming tools (loops, functions, etc.) could fit together to construct an actual game. Hopefully my efforts here can help anyone else in the same position. I know there's a lot of people that would love to know how to code their own games, but feel like it's hard to learn in a practical way.
I really loved making my own Ascii game, and would be really excited to see anything anyone makes
Here's some screenshots of a game I made when I didn't know hardly anything about programming. This game was made my first semester of college, it's called TerraNisi. It wasn't actually made with AsciiEngine, but it'd be incredibly simple to make it within AsciiEngine:
Intro picture!Screenshot of some gameplay Only the most cutest and funny villain evar.
Link to TerraNisi: LINK Link to AsciiEngine Info: LINK Link to AsciiEngine: LINK
Feel free to email me at: r.gaul@digipen.edu if you have any questions about making a game. For some reason getting other people interested in game programming is just so fun, so don't be shy in asking for help with programming or anything else! I'm also completely open to any criticism/suggestions on the project.
|
This is beautiful. I'll check it out for sure, sounds loads of fun :D
|
So, you wrote this? Nice work! How many colors does it support? And what is the max resolution? Also, does it support text input, like if you wanted to have a picture, and the user can also enter text at a prompt for commands?
|
On July 04 2012 07:50 fabiano wrote: This is beautiful. I'll check it out for sure, sounds loads of fun :D Hey sweet! Do post back here to show off what you've done
On July 04 2012 07:54 Mossen wrote: So, you wrote this? Nice work! How many colors does it support? And what is the max resolution? Also, does it support text input, like if you wanted to have a picture, and the user can also enter text at a prompt for commands? Yes I did write this. It supports quite a few colors by default, though you can only have 16 colors active in your palette. Luckily I've figured out (with help from programmers unkown on the internet) how to set a custom color palette.
There's no functionality within AsciiEngine for command line input currently, but it'd be very easy to create. I wrote a post on creating a custom scripting language, you can pretty easily write your own parser for input commands. The functionality to show what the user is writing on the screen would also be really easy to make as well -- I put something like this into TerraNisi, but it only supported one character at a time for simplicity.
Edit: Any resolution.
|
You should try reverse-engineering Dwarf Fortress.
|
It certainly is a unique way to develop games. The issue I have is that although you can create some pretty fun games this way, there isn't really a market for sharing or selling them. I don't know why but that gets to me when I'm making a game; unless I know it could potentially go somewhere I find it hard to invest the time.
I've been finding that Android is actually a really nice platform for creating beginner games at the moment. The only tricky bit is setting up your development environment but there is a full tutorial online on how to set up Eclipse IDE for Android development: http://developer.android.com/sdk/installing/installing-adt.html
The game engine I've been using is called AndEngine and is designed for 2D graphics only: http://www.andengine.org/
And if you're into 3D graphics there's a nice free engine called JPCT-AE: http://www.jpct.net/jpct-ae/
At the end of the day you need to understand programming and how to structure a program in order to make games from scratch. It's a fallacy that anyone can download some tools and make a game... it just doesn't work that way.
In saying that your game looks awesome Reminds me of the past. Very quirky idea.
|
Your artwork is impressive. You have a gift.
No console for me though, I'm an OpenGL/GLFW convert XD
|
|
Let's make games together cecil. I need someone with ideas and programming knowledge to demand art from me.
|
the last picture looks like a portrait in Mario N64 .
|
Cool and all, but I'm surprised you say that writing console based games is a good start for beginners because they don't have to use black box libraries, yet the point of your post is to talk about your black box library, AsciiEngine. I mean, in the same sense that AsciiEngine sets up a lot of boring stuff for you so you can focus on making the game, so does SDL, difference being that SDL supports "proper graphics". I would think most beginner developers would get more benefit, and have more fun, makind SDL games over Ascii games.
Personally I feel beginner programmers who want to become more advanced should generally not use premade engines but instead learn to make their own since that gives a completely different perspective on what is possible. To a reasonable degree of course, using SDL or your asciiengine is fine since they help with background annoying stuff, while using stuff like Unity is, IMO, abstracting the developer too far away from the groundwork.
|
On July 04 2012 17:29 Tobberoth wrote: Cool and all, but I'm surprised you say that writing console based games is a good start for beginners because they don't have to use black box libraries, yet the point of your post is to talk about your black box library, AsciiEngine. I mean, in the same sense that AsciiEngine sets up a lot of boring stuff for you so you can focus on making the game, so does SDL, difference being that SDL supports "proper graphics". I would think most beginner developers would get more benefit, and have more fun, makind SDL games over Ascii games.
Going by the same reasoning I'd recommend Pygame over SDL for even more fun (and rapid) development. It's basically an SDL wrapper, but you get the advantage of using Python which is as accessible as programming languages get.
|
On July 04 2012 18:50 Talin wrote:Show nested quote +On July 04 2012 17:29 Tobberoth wrote: Cool and all, but I'm surprised you say that writing console based games is a good start for beginners because they don't have to use black box libraries, yet the point of your post is to talk about your black box library, AsciiEngine. I mean, in the same sense that AsciiEngine sets up a lot of boring stuff for you so you can focus on making the game, so does SDL, difference being that SDL supports "proper graphics". I would think most beginner developers would get more benefit, and have more fun, makind SDL games over Ascii games. Going by the same reasoning I'd recommend Pygame over SDL for even more fun (and rapid) development. It's basically an SDL wrapper, but you get the advantage of using Python which is as accessible as programming languages get. Well yeah, that's what I meant. If you're a beginning programmer who want to make games, going to C is probably not a good idea. There are SDL wrappers for all languages imaginable, so it's really easy to get started with.
|
Does this mean Howl's Moving Castle is just a fanfiction of your game?
|
Kyrgyz Republic1462 Posts
On July 04 2012 17:29 Tobberoth wrote: Cool and all, but I'm surprised you say that writing console based games is a good start for beginners because they don't have to use black box libraries, yet the point of your post is to talk about your black box library, AsciiEngine. I mean, in the same sense that AsciiEngine sets up a lot of boring stuff for you so you can focus on making the game, so does SDL, difference being that SDL supports "proper graphics". I would think most beginner developers would get more benefit, and have more fun, makind SDL games over Ascii games.
Personally I feel beginner programmers who want to become more advanced should generally not use premade engines but instead learn to make their own since that gives a completely different perspective on what is possible. To a reasonable degree of course, using SDL or your asciiengine is fine since they help with background annoying stuff, while using stuff like Unity is, IMO, abstracting the developer too far away from the groundwork.
That is what I was thinking when I first decided that I'd like to make games, and well, I have spent A LOT of time building my own 3D engine, and although that indeed gave me a better understanding of how those things work, that has not helped me to actually make a game and obviously it really sucked compared to OGRE or Unity :-)
I think that as long as you understand what someone's library is doing, not necessarily how, that is sufficient. That is if your goal is to make a working product, and not become a "better programmer" :-)
|
Kyrgyz Republic1462 Posts
I wonder if it is possible to gather a group of enthusiasts here on TL and make a funny little game project...
|
On July 04 2012 23:48 Random() wrote: I wonder if it is possible to gather a group of enthusiasts here on TL and make a funny little game project...
To gather a group? Probably. To actually get something finished? Much less likely.
But it would be a fun experience nonetheless (I'd be up for it personally!).
|
On July 04 2012 17:29 Tobberoth wrote: Cool and all, but I'm surprised you say that writing console based games is a good start for beginners because they don't have to use black box libraries, yet the point of your post is to talk about your black box library, AsciiEngine. I mean, in the same sense that AsciiEngine sets up a lot of boring stuff for you so you can focus on making the game, so does SDL, difference being that SDL supports "proper graphics". I would think most beginner developers would get more benefit, and have more fun, makind SDL games over Ascii games. That does make sense, but since this is open source if someone wanted, they could use it simply as a reference point for starting their own project. That's the point I was trying to make, if that makes any sense.
|
On July 04 2012 12:13 fire_brand wrote: Let's make games together cecil. I need someone with ideas and programming knowledge to demand art from me. You may make art for my games :D
|
Nice work. Do you use an in game editor to draw art?
|
That was cute
|
I don't have much to add other than I really like your blog and your threads and I hope you continue to post them.
Cheers!
|
That's pretty cool. Good job. I made a multi-colored text adventure game before to run in a console. But it wasn't anything like this. I really the retro look. Hmm I feel inspiration coming lol. I been thinking about programming something retro lately.
|
Nice work dude, I remember I used to build game like these in QBasic around 14 years ago, so this is a bit nostalgic for me . ALT+219, ALT+176, ALT+177 and ALT+178 were the way to go to draw something :D After that I started using the draw function. The only issue I think I had were the different resolution ratios.
|
I've updated the engine!
New stuff:
On July 05 2012 00:10 Talin wrote:Show nested quote +On July 04 2012 23:48 Random() wrote: I wonder if it is possible to gather a group of enthusiasts here on TL and make a funny little game project... To gather a group? Probably. To actually get something finished? Much less likely. But it would be a fun experience nonetheless (I'd be up for it personally!). Sounds like you guys should get on it!
On July 05 2012 22:06 Spikeke wrote: That's pretty cool. Good job. I made a multi-colored text adventure game before to run in a console. But it wasn't anything like this. I really the retro look. Hmm I feel inspiration coming lol. I been thinking about programming something retro lately. You should join the dudes I quoted above me perhaps?
On July 05 2012 14:22 memcpy wrote: Nice work. Do you use an in game editor to draw art? I was using a tool someone else wrote to save time. I think I might make my own today, maybe tomorrow, maybe not at all. We'll see
|
what tool is that?
also if anyone here is open to starting a small project i'm down. maybe cecil can help delegate?
|
On July 06 2012 06:35 opsayo wrote:what tool is that? also if anyone here is open to starting a small project i'm down. maybe cecil can help delegate? http://forums.tigsource.com/index.php?topic=14588.0
I could perhaps help out a little bit, but I don't have the time to run anything
|
Nice ascii art.
Must say though, programming in C is a suicide mission, there is no reason why not to use C++ instead. I met a few C fanatics in my life and their preference for C(over C++ or other language) was purely emotional.
|
Speaking of groups, we're still on time to get in the next Ludum Dare if people are up for it
It's basically a week-long game dev competition (actually it's usually a 48hour one, the current one is an exception). It starts on Monday! It would give us some useful constraints in terms of a theme and a deadline, and competitions are fun, and if we end up sucking at least we only sunk 6 days into it.
|
FEAR THE MIGHTY CALCIFER!
Great blog.
|
On July 07 2012 04:14 LastWish wrote: Nice ascii art.
Must say though, programming in C is a suicide mission, there is no reason why not to use C++ instead. I met a few C fanatics in my life and their preference for C(over C++ or other language) was purely emotional.
The design of C is soooo much better than C++.
A lot of people think that C++ is probably one of the most terribly designed languages ever made. A fraction of that think the same for C.
|
On July 08 2012 22:01 sluggaslamoo wrote:Show nested quote +On July 07 2012 04:14 LastWish wrote: Nice ascii art.
Must say though, programming in C is a suicide mission, there is no reason why not to use C++ instead. I met a few C fanatics in my life and their preference for C(over C++ or other language) was purely emotional. The design of C is soooo much better than C++. A lot of people think that C++ is probably one of the most terribly designed languages ever made. A fraction of that think the same for C.
Can you elaborate?
|
On July 07 2012 04:14 LastWish wrote: Nice ascii art.
Must say though, programming in C is a suicide mission, there is no reason why not to use C++ instead. I met a few C fanatics in my life and their preference for C(over C++ or other language) was purely emotional. I've got the language down well enough so that I can dev things out pretty efficiently. I also know the limitations well enough to workaround efficiently (for example setting up object orientation with polymorphism and inheritance in a very clean way).
I'll be doing a lot of projects in C++ for the rest of my life, so I'll hammer a C one out while I have the free time to do so.
|
On July 08 2012 23:15 LastWish wrote:Show nested quote +On July 08 2012 22:01 sluggaslamoo wrote:On July 07 2012 04:14 LastWish wrote: Nice ascii art.
Must say though, programming in C is a suicide mission, there is no reason why not to use C++ instead. I met a few C fanatics in my life and their preference for C(over C++ or other language) was purely emotional. The design of C is soooo much better than C++. A lot of people think that C++ is probably one of the most terribly designed languages ever made. A fraction of that think the same for C. Can you elaborate?
I love C++, and I much prefer it to C. But the failings of C++ from a design perspective are pretty obvious.
Since it is a fairly low-level language, it's not fair to hang issues like "no garbage collection" and such on it. Of course it doesn't have garbage collection; it's not supposed to. Some people will hate on implicit constructor calls, temporaries, operator overloading, or other such things, but those are personal issues, not real problems.
Most of the actual problems with C++ stem from either incomplete features (templates with no concepts) or things that are necessary for C interop. For example, pointers. Pointers are good, but the syntax for them is pretty unpleasant. For example, one could imagine a `ptr<Typename>` syntax rather than `Typename*` syntax. It's more obvious what goes with what and everything; you don't have the `const Typename *` vs `Typename * const` issue that forces you to read backwards. It's clear that `const ptr<Typename>` has the pointer being const, while `ptr<const Typename>` has the object being pointed to as const.
C-style casts are another thing that C++ shouldn't have had.
There are a lot of just generally ugly syntax issues. C++ prefers to use an operator rather than a keyword for things. The C++11 lambda feature is a great feature, but it is induced with the oddball `[]` syntax rather than a keyword.
iostreams also suck balls. The only advantage they have over C-style IO is that they're type-safe (and therefore extensible). The C++ standards committee really needs to come up with a better, extensible stream API.
std::basic_string is a poorly-designed class. It has no real support for Unicode-encodings (though then again, neither does much else in C++). It has too many member functions that could have just been standard algorithms. And so forth.
|
On July 05 2012 00:43 CecilSunkure wrote:Show nested quote +On July 04 2012 17:29 Tobberoth wrote: Cool and all, but I'm surprised you say that writing console based games is a good start for beginners because they don't have to use black box libraries, yet the point of your post is to talk about your black box library, AsciiEngine. I mean, in the same sense that AsciiEngine sets up a lot of boring stuff for you so you can focus on making the game, so does SDL, difference being that SDL supports "proper graphics". I would think most beginner developers would get more benefit, and have more fun, makind SDL games over Ascii games. That does make sense, but since this is open source if someone wanted, they could use it simply as a reference point for starting their own project. That's the point I was trying to make, if that makes any sense.
There are plenty of open source engines out there. AsciiEngine is not special in this regard.
Personally, I've never understood why modern games would bother with this. There is no functional difference between so-called ASCII art and a regular tile-map. It's ultimately the same thing: draw a series of images of fixed size in grid locations. If you really want your tiles to be text glyphs, then put text glyphs in your tilemap. At least then, you'll have reasonable freedom to pick a good font that serves your needs.
|
On July 09 2012 06:26 NicolBolas wrote:Show nested quote +On July 05 2012 00:43 CecilSunkure wrote:On July 04 2012 17:29 Tobberoth wrote: Cool and all, but I'm surprised you say that writing console based games is a good start for beginners because they don't have to use black box libraries, yet the point of your post is to talk about your black box library, AsciiEngine. I mean, in the same sense that AsciiEngine sets up a lot of boring stuff for you so you can focus on making the game, so does SDL, difference being that SDL supports "proper graphics". I would think most beginner developers would get more benefit, and have more fun, makind SDL games over Ascii games. That does make sense, but since this is open source if someone wanted, they could use it simply as a reference point for starting their own project. That's the point I was trying to make, if that makes any sense. There are plenty of open source engines out there. AsciiEngine is not special in this regard. Personally, I've never understood why modern games would bother with this. There is no functional difference between so-called ASCII art and a regular tile-map. It's ultimately the same thing: draw a series of images of fixed size in grid locations. If you really want your tiles to be text glyphs, then put text glyphs in your tilemap. At least then, you'll have reasonable freedom to pick a good font that serves your needs. Nobody has written anything for the Windows console quite like this, and it's a whole lot of fun to create something anyways. The point isn't to make something special, but to try and provide something someone can learn from, while learning new things myself as well.
|
For beginner game makers who want to do real programming (and for advanced users for fast game prototyping) I recommend trying out the Löve2D engine.
You have to program in Lua to use it. It's easier to learn than C imo (but you'll be a worse programmer if you only learn Lua of course ). Lua is a script language so you don't have to compile, you just put your code in a text file to run it.
Löve2D uses SDL, OpenGl, OpenAL, box2d.. etc. Very easy to use. Your games will be platform independent with it. Try it: http://www.love2d.org
After installing löve, check out one of my projects: https://love2d.org/forums/viewtopic.php?f=5&t=9649
|
On July 09 2012 06:25 NicolBolas wrote:Show nested quote +On July 08 2012 23:15 LastWish wrote:On July 08 2012 22:01 sluggaslamoo wrote:On July 07 2012 04:14 LastWish wrote: Nice ascii art.
Must say though, programming in C is a suicide mission, there is no reason why not to use C++ instead. I met a few C fanatics in my life and their preference for C(over C++ or other language) was purely emotional. The design of C is soooo much better than C++. A lot of people think that C++ is probably one of the most terribly designed languages ever made. A fraction of that think the same for C. Can you elaborate? I love C++, and I much prefer it to C. But the failings of C++ from a design perspective are pretty obvious. Since it is a fairly low-level language, it's not fair to hang issues like "no garbage collection" and such on it. Of course it doesn't have garbage collection; it's not supposed to. Some people will hate on implicit constructor calls, temporaries, operator overloading, or other such things, but those are personal issues, not real problems. Most of the actual problems with C++ stem from either incomplete features (templates with no concepts) or things that are necessary for C interop. For example, pointers. Pointers are good, but the syntax for them is pretty unpleasant. For example, one could imagine a `ptr<Typename>` syntax rather than `Typename*` syntax. It's more obvious what goes with what and everything; you don't have the `const Typename *` vs `Typename * const` issue that forces you to read backwards. It's clear that `const ptr<Typename>` has the pointer being const, while `ptr<const Typename>` has the object being pointed to as const. C-style casts are another thing that C++ shouldn't have had. There are a lot of just generally ugly syntax issues. C++ prefers to use an operator rather than a keyword for things. The C++11 lambda feature is a great feature, but it is induced with the oddball `[]` syntax rather than a keyword. iostreams also suck balls. The only advantage they have over C-style IO is that they're type-safe (and therefore extensible). The C++ standards committee really needs to come up with a better, extensible stream API. std::basic_string is a poorly-designed class. It has no real support for Unicode-encodings (though then again, neither does much else in C++). It has too many member functions that could have just been standard algorithms. And so forth.
Couldn't have put it much better myself.
I was actually waiting for someone else to respond because I know a lot of others think the same thing. I'm glad it was a C++ programmer objective enough to point out the issues.
Your exactly right in that we can't hold things like memory management and other low level functionality against C++, and a lot of C++ enthusiasts think that that's the reason people don't like C++.
My qualms are pretty much exclusively about syntax. Its just so inconsistent, its as if Strousup had never heard of POLS. You could even start with how creating abstract classes requires an = 0 on the end of your methods, and you can have a static method that has a static block, which the compiler needs to cascade that "permission" down. Now think about how the sometimes the compiler requires you to use a static block for no reason (or at least not a very good one) and you got yourself a pile of supposedly more maintainable (because its OO) but actually un-maintainable code. You could spend 10 years learning C++ and still learn some new things about it. This causes mayhem when you are with a team of developers.
|
On July 09 2012 06:26 NicolBolas wrote:Show nested quote +On July 05 2012 00:43 CecilSunkure wrote:On July 04 2012 17:29 Tobberoth wrote: Cool and all, but I'm surprised you say that writing console based games is a good start for beginners because they don't have to use black box libraries, yet the point of your post is to talk about your black box library, AsciiEngine. I mean, in the same sense that AsciiEngine sets up a lot of boring stuff for you so you can focus on making the game, so does SDL, difference being that SDL supports "proper graphics". I would think most beginner developers would get more benefit, and have more fun, makind SDL games over Ascii games. That does make sense, but since this is open source if someone wanted, they could use it simply as a reference point for starting their own project. That's the point I was trying to make, if that makes any sense. There are plenty of open source engines out there. AsciiEngine is not special in this regard. Personally, I've never understood why modern games would bother with this. There is no functional difference between so-called ASCII art and a regular tile-map. It's ultimately the same thing: draw a series of images of fixed size in grid locations. If you really want your tiles to be text glyphs, then put text glyphs in your tilemap. At least then, you'll have reasonable freedom to pick a good font that serves your needs.
Dwarf Fortress is a pretty good game
|
I always wanted to program some ASCII game where you capture monsters and are able to interbreed then, creating hybrids. It should work at such a basic level, simulating chemistry and organs, that you can really get some neat unpredictable results.
I coded some partial text based stuff way in the past. It is so tedious. Often I think about trying to start it. But then I realize how much time it would all take and how underwhelming and disappointing the end result would be.
|
On July 09 2012 10:53 sluggaslamoo wrote:Show nested quote +On July 09 2012 06:26 NicolBolas wrote:On July 05 2012 00:43 CecilSunkure wrote:On July 04 2012 17:29 Tobberoth wrote: Cool and all, but I'm surprised you say that writing console based games is a good start for beginners because they don't have to use black box libraries, yet the point of your post is to talk about your black box library, AsciiEngine. I mean, in the same sense that AsciiEngine sets up a lot of boring stuff for you so you can focus on making the game, so does SDL, difference being that SDL supports "proper graphics". I would think most beginner developers would get more benefit, and have more fun, makind SDL games over Ascii games. That does make sense, but since this is open source if someone wanted, they could use it simply as a reference point for starting their own project. That's the point I was trying to make, if that makes any sense. There are plenty of open source engines out there. AsciiEngine is not special in this regard. Personally, I've never understood why modern games would bother with this. There is no functional difference between so-called ASCII art and a regular tile-map. It's ultimately the same thing: draw a series of images of fixed size in grid locations. If you really want your tiles to be text glyphs, then put text glyphs in your tilemap. At least then, you'll have reasonable freedom to pick a good font that serves your needs. Dwarf Fortress is a pretty good game Which can be played tile-based just as good as it can ascii based... and it looks way better to boot.
|
On July 09 2012 10:51 sluggaslamoo wrote: My qualms are pretty much exclusively about syntax. Its just so inconsistent, its as if Strousup had never heard of POLS. You could even start with how creating abstract classes requires an = 0 on the end of your methods, and you can have a static method that has a static block, which the compiler needs to cascade that "permission" down. Now think about how the sometimes the compiler requires you to use a static block for no reason (or at least not a very good one) and you got yourself a pile of supposedly more maintainable (because its OO) but actually un-maintainable code. You could spend 10 years learning C++ and still learn some new things about it. This causes mayhem when you are with a team of developers.
I have no idea what you're talking about here with the "static block" and "permission" thing. What do you mean by "static block", and what does that have to do with pure virtual syntax? And where does the compiler start forcing you to use these "static blocks" "for no reason"?
As for the Principle of Least Surprise (which I assume is what you're talking about with POLS. It's a good idea to spell the acronym out the first time), you seem to forget that Stroustrup (that's how his named is spelled) was not creating a language from scratch. The value semantics issue and the need for temporaries and such are all derived from the fact that C has value semantics and implicit object copying.
|
Indeed, C++ language needed to be back compatible with standard C and therefore a lot of problems arised.
I'm not saying that the syntax is perfect... mainly because of the template maddness(the boost library serves well as an example). But the language comes with handy stuff that many modern languages cut down on:
- Over C, simply it's object oriented - thus makes your code more readable, intuitive; must have for big projects
- Operator overloading(even assigning, copy constructing, new...)
- Control over copy constructing(cloning) and pointer assignment
- Multi-class inheritance and friend class membership
- Destructors, smart pointers(while garbage collector is cool, if you make your program well using destuctors it will make your program performance much more predictable)
- Although const can be a double edged sword, if you used it correctly it can make you program better - it's really impossible to make a read-only collection or class(or nested) in Java or C#
Many companies(even those I've worked in) make their own Standard libraries and utilities usually based on stl which makes programming in C++ really neat and sweet
|
On July 10 2012 02:44 NicolBolas wrote:Show nested quote +On July 09 2012 10:51 sluggaslamoo wrote: My qualms are pretty much exclusively about syntax. Its just so inconsistent, its as if Strousup had never heard of POLS. You could even start with how creating abstract classes requires an = 0 on the end of your methods, and you can have a static method that has a static block, which the compiler needs to cascade that "permission" down. Now think about how the sometimes the compiler requires you to use a static block for no reason (or at least not a very good one) and you got yourself a pile of supposedly more maintainable (because its OO) but actually un-maintainable code. You could spend 10 years learning C++ and still learn some new things about it. This causes mayhem when you are with a team of developers. I have no idea what you're talking about here with the "static block" and "permission" thing. What do you mean by "static block", and what does that have to do with pure virtual syntax? And where does the compiler start forcing you to use these "static blocks" "for no reason"? As for the Principle of Least Surprise (which I assume is what you're talking about with POLS. It's a good idea to spell the acronym out the first time), you seem to forget that Stroustrup (that's how his named is spelled) was not creating a language from scratch. The value semantics issue and the need for temporaries and such are all derived from the fact that C has value semantics and implicit object copying.
As this is starting to detract from the actual topic I'm gonna chuck this in a spoiler
+ Show Spoiler +As with most of my posts I rush them out and make silly mistakes, I always spell stroustrup strousup when I'm not thinking, no need to get pedantic about spelling. Just because it was built on top of C, doesn't mean he couldn't change some things, the changes he did make, just made it messy. Why do we use iostream and cout? What's the point? Pure virtual methods require an = 0 on the end. Not a huge issue, but it is just one of the many inconsistencies within syntax. Its unnecessary. When you are doing some complex OO designs or use some OO libraries eventually you may come across this issue. (sorry I meant const not static). Here is an example method in a trivial C++ battleships game I did a really really long time ago. public: const Cell& Board::operator [] (const Coordinate& c) const; In the "Liskov branch" of OOP I am required to make things as abstracted/encapsulated/type-safe as possible, in order to add maintainability, by reducing fear of side-effects. Thus const is used for everything that should be immutable, leading to large amount of the modifiers used above, regardless of how pragmatic or inelegant it is in real life. Declaring the same thing in another language requires half the verbosity, so I blame C++ for how ugly this looks. What's worse is someone can use the "mutable" keyword to "un-const" it. 1. Two const keywords in the one method declaration (excluding parameters), the behaviour is differentiated by the position of the keyword const in the definition, syntactically this is awful design. const before the block implies an immutable block, but what it really means is that `self` is immutable within that block. (I forgot the real term for "const block" its been many years so cut me some slack here ) 2. const Coordinate&. I get that type safety is a big deal, but we have 4 ways of declaring almost exactly the same thing. We could have Coordinate, Coordinate*, Coordinate&, const Coordinate*, const Coordinate&, and const Coordinate. They all have their slight nuances, but it doesn't really matter, it is really the same parameter. The fact that C++ requires you to match that parameter perfectly causes mayhem, it is just like having a goto statement, instead of forcing people to just declare things with a single entry and exit point. If you really (really REALLY) want to duplicate a data structure in memory via way of passing an argument, then just duplicate the friggin data structure before you pass it in, and for the rest of them, assume an immutable reference or immutable pointer to a mutable object. And if you REALLY want an immutable pointer, then assign a new pointer before passing the argument. Sure its derived from C, but C wasn't designed to be OO, so it didn't matter (as much). Why can't we just have one way of declaring the requirement of an immutable object, so programmers won't get pedantic about mitigating side-effects and causing all sorts of problems. Indeed other languages did just that. 3. Usage of operator and [], why can't it just be Board::[]? 4. Why do nest classes inside a namespace block, but I don't nest method implementations inside a class block, but I nest method implementations inside the class block in the header, but I don't nest public methods inside public block? Why does the public keyword automatically nest methods under it, and why does it have a ":" on the end? Why doesn't it follow standard C convention? About the compiler forcing me to use const "const block" creates an annoying permission problem because of the way C++ handles immutability and type-safety. I haven't used C++ in a long time, but iirc if you declare a "const block", often the compiler will force you to declare other methods "const" that use it. When you have a bunch of these, it actually becomes almost impossible to implement methods that are re-usable, or even do anything useful, because you try to modify `self` and the compiler cracks it because you are required to use this const block. Also One cannot simply avoid using ‘const’ on class methods because ‘const’ is infectious. An object which has been made ‘const’, for example by being passed as a parameter in the ‘const &’ way, can only have those of its methods that are explicitly declared ‘const’ called (because C++’s calling system is too simple to work out which methods not explicitly declared ‘const’ don’t actually change anything). Therefore class methods that don’t change the object are best declared ‘const’ so that they are not prevented from being called when an object of the class has somehow acquired ‘const’ status. In later versions of C++, an object or variable which has been declared ‘const’ can be converted to changeable by use of ‘const_cast’ which is a similar bodge to ‘mutable’ and using it likewise renders ‘const’ virtually useless. I just found this, he explains it way better than I do. http://duramecho.com/ComputerInformation/WhyHowCppConst.htmlAlso I just fail to see how the OO capabilities of C++ lead to the goals of OO. OO is largely about reducing costs and overhead through maintainability and re-usability. Because of the clunkiness and inconsistency, you often find yourself breaking things down into non-reuseable methods. So your code base often just doesn't end up any more maintable than a regular C program. Add onto this the amount of verbosity in C++, often I can implement an OO program using ADT's in C and have a smaller, more maintable, more readable code-base than C++. Hope I explained things a little better this time.
|
Const block? Do you mean constant methods? In this regard the compiler only enforces one thing: const methods must not call non-const methods. The reason for this is extremely obvious XD
|
On July 10 2012 23:41 LastWish wrote:Indeed, C++ language needed to be back compatible with standard C and therefore a lot of problems arised. I'm not saying that the syntax is perfect... mainly because of the template maddness(the boost library serves well as an example). But the language comes with handy stuff that many modern languages cut down on: - Over C, simply it's object oriented - thus makes your code more readable, intuitive; must have for big projects
- Operator overloading(even assigning, copy constructing, new...)
- Control over copy constructing(cloning) and pointer assignment
- Multi-class inheritance and friend class membership
- Destructors, smart pointers(while garbage collector is cool, if you make your program well using destuctors it will make your program performance much more predictable)
- Although const can be a double edged sword, if you used it correctly it can make you program better - it's really impossible to make a read-only collection or class(or nested) in Java or C#
Many companies(even those I've worked in) make their own Standard libraries and utilities usually based on stl which makes programming in C++ really neat and sweet
I just want to go over your list. I'm not directing this at you, I just think these are invalid reasons that people hype up about C++.
1. Unlike Java, I rarely see people use the OO functionaliy of C++ like polymorphism to the fullest extent simply because of how clunky it is and how many problems it causes. Usage of ADT's in C often look and work better than the use of objects in C++, its kind of sad.
2. Operator overloading exists in every language . I think you mean operator overriding? I don't know what's worse, adding some quirky functionality instead of just plain reducing the verbosity of the language, or the fact that you can actually override an operator in a performance focused language. "Sup Array, why you so slow? And why is my Integer not adding?"
3. Another thing I have to think about, because apparently its really hard to just create a method and call it copy().
4. a) friend = omfg r u srs? really? b) Diamond problem, not saying multiple implementation inheritance is bad, but in C++ its done really badly.
5. Ok fine
6. See above
|
On July 11 2012 16:18 Mstring wrote: Const block? Do you mean constant methods? In this regard the compiler only enforces one thing: const methods must not call non-const methods. The reason for this is extremely obvious XD
Hey its been a while ok xD
That's right, I remember now. And yeah the reason IS obvious when you remember how to do it . Anyway my stance on it still stands, it causes un-reusability of code.
|
C++ is the only tool that works for my purposes so I don't complain :D
I've seen some production C++ code; I can understand how some practices might cause problems in a team environment. Luckily I'm a one man team. Code reusability? XD
|
On July 11 2012 16:20 sluggaslamoo wrote:Show nested quote +On July 10 2012 23:41 LastWish wrote:Indeed, C++ language needed to be back compatible with standard C and therefore a lot of problems arised. I'm not saying that the syntax is perfect... mainly because of the template maddness(the boost library serves well as an example). But the language comes with handy stuff that many modern languages cut down on: - Over C, simply it's object oriented - thus makes your code more readable, intuitive; must have for big projects
- Operator overloading(even assigning, copy constructing, new...)
- Control over copy constructing(cloning) and pointer assignment
- Multi-class inheritance and friend class membership
- Destructors, smart pointers(while garbage collector is cool, if you make your program well using destuctors it will make your program performance much more predictable)
- Although const can be a double edged sword, if you used it correctly it can make you program better - it's really impossible to make a read-only collection or class(or nested) in Java or C#
Many companies(even those I've worked in) make their own Standard libraries and utilities usually based on stl which makes programming in C++ really neat and sweet I just want to go over your list. I'm not directing this at you, I just think these are invalid reasons that people hype up about C++. 1. Unlike Java, I rarely see people use the OO functionaliy of C++ like polymorphism to the fullest extent simply because of how clunky it is and how many problems it causes. Usage of ADT's in C often look and work better than the use of objects in C++, its kind of sad. 2. Operator overloading exists in every language . I think you mean operator overriding? I don't know what's worse, adding some quirky functionality instead of just plain reducing the verbosity of the language, or the fact that you can actually override an operator in a performance focused language. "Sup Array, why you so slow? And why is my Integer not adding?" 3. Another thing I have to think about, because apparently its really hard to just create a method and call it copy(). 4. a) friend = omfg r u srs? really? b) Diamond problem, not saying multiple implementation inheritance is bad, but in C++ its done really badly. 5. Ok fine 6. See above
Many of the things you address(overall in this thread) are connected to bad programming habits/inexperience. It's like you would argue that StarCraft allows many strategies/build orders but many of them simply don't work on professional level. Blame the people not the language.
Back to the list:
- 1. I don't know what you are talking about, only problem you really have to worry about are virtual destructors, other than that your inheritance works just like in Java.
- 2. Operator overloading is not present in Java. That's why I prefer C# over Java because I can never construct a pretty intuitive class:
Take for example Complex or Vector class: It will always be: resultVector = baseVector.mul(vector1.add(vector2)); Instead of: resultVector = baseVector * (vector1 + vector2); The more complex expression you write the more messy it gets. C# does have operator overloading for many operators, but still you still can't for example overload assigment(=) or "new" keword. While this will not be the every day use, one day you will find use for it: a) assigment(=): for example a class that stores it's history values. Simply you overload assigment and upon execution store the previous value to an array of some sort. b) new keyword: for example you want to make a class that for some reason needs to be a pool(like is used very frequently in large arrays and is small by itself). You can overload the new keyword to do work for you and you don't have to give a shit for the rest of the program.
- 3. It's just impractical to create copy() or Clone() method on every occasion for every class. I tried to solve this problem in C# by using reflection - guess what reflection is a slow dirty pig.
- 4. Yeah diamond problem mainly and it's really common, I agree that the syntactic solution for this was not very pleasant. However you can do it! And it's not really that hard, by the way I don't know any other compilable language that you could deal with this... and using some form of proxy classing instead is a headache.
Friend classes are just nice and sometimes they come handy. It's not really that big of a problem, but if you need them and don't have them again you have to use ugly proxy class pattern.
- 6. Take for example C# language:
We have some kind of class "Item" which has publicly settable/gettable properties(or fields or whatever) Cost and Type. Now you have them in a collection for example a List<Item>. You want to pass them this list to a function TotalCost that would compute the total cost. There is no way you can make the members of this collection not editable. Even if you use some form of ReadOnlyList<Item>, once you can get the Item you can set the Cost at will. In C++ however you simple use make: int TotalCost(const vector<Item> &items); What you were addressing were pointer const problems: const char *arr const; Now these are really ugly and unintuitive, however in C++ you try to avoid using pointers or pointer arrays as much as you can. Class function const: class Calculator{ ... int TotalCost(const vector<Item> &items) const; }; Now many of these const functions of the class are a pain and could be auto-detected by a compiler(one day perhaps): TotalCost impl{ func1 func2 func3 } -> func1, func2, func3 all do const operations on class Calculator therefore auto-const. Pretty easy to imagine, probably a little harder to implement... Function const parameter maddness: In C++ 95% of time you will be using just: const type ¶meter and type ¶meter; obviously some primitive types(int) don't need to use &. No big deal just some good practices that make you programming life easy and fun.
Once again I think there are many bad programmers in the world.. hence I may be one of them and not know it! Blame the people not the language.
|
+ Show Spoiler +On July 11 2012 18:13 LastWish wrote:Show nested quote +On July 11 2012 16:20 sluggaslamoo wrote:On July 10 2012 23:41 LastWish wrote:Indeed, C++ language needed to be back compatible with standard C and therefore a lot of problems arised. I'm not saying that the syntax is perfect... mainly because of the template maddness(the boost library serves well as an example). But the language comes with handy stuff that many modern languages cut down on: - Over C, simply it's object oriented - thus makes your code more readable, intuitive; must have for big projects
- Operator overloading(even assigning, copy constructing, new...)
- Control over copy constructing(cloning) and pointer assignment
- Multi-class inheritance and friend class membership
- Destructors, smart pointers(while garbage collector is cool, if you make your program well using destuctors it will make your program performance much more predictable)
- Although const can be a double edged sword, if you used it correctly it can make you program better - it's really impossible to make a read-only collection or class(or nested) in Java or C#
Many companies(even those I've worked in) make their own Standard libraries and utilities usually based on stl which makes programming in C++ really neat and sweet I just want to go over your list. I'm not directing this at you, I just think these are invalid reasons that people hype up about C++. 1. Unlike Java, I rarely see people use the OO functionaliy of C++ like polymorphism to the fullest extent simply because of how clunky it is and how many problems it causes. Usage of ADT's in C often look and work better than the use of objects in C++, its kind of sad. 2. Operator overloading exists in every language . I think you mean operator overriding? I don't know what's worse, adding some quirky functionality instead of just plain reducing the verbosity of the language, or the fact that you can actually override an operator in a performance focused language. "Sup Array, why you so slow? And why is my Integer not adding?" 3. Another thing I have to think about, because apparently its really hard to just create a method and call it copy(). 4. a) friend = omfg r u srs? really? b) Diamond problem, not saying multiple implementation inheritance is bad, but in C++ its done really badly. 5. Ok fine 6. See above Many of the things you address(overall in this thread) are connected to bad programming habits/inexperience. It's like you would argue that StarCraft allows many strategies/build orders but many of them simply don't work on professional level. Blame the people not the language. Back to the list: - 1. I don't know what you are talking about, only problem you really have to worry about are virtual destructors, other than that your inheritance works just like in Java.
- 2. Operator overloading is not present in Java. That's why I prefer C# over Java because I can never construct a pretty intuitive class:
Take for example Complex or Vector class: It will always be: resultVector = baseVector.mul(vector1.add(vector2)); Instead of: resultVector = baseVector * (vector1 + vector2); The more complex expression you write the more messy it gets. C# does have operator overloading for many operators, but still you still can't for example overload assigment(=) or "new" keword. While this will not be the every day use, one day you will find use for it: a) assigment(=): for example a class that stores it's history values. Simply you overload assigment and upon execution store the previous value to an array of some sort. b) new keyword: for example you want to make a class that for some reason needs to be a pool(like is used very frequently in large arrays and is small by itself). You can overload the new keyword to do work for you and you don't have to give a shit for the rest of the program.
- 3. It's just impractical to create copy() or Clone() method on every occasion for every class. I tried to solve this problem in C# by using reflection - guess what reflection is a slow dirty pig.
- 4. Yeah diamond problem mainly and it's really common, I agree that the syntactic solution for this was not very pleasant. However you can do it! And it's not really that hard, by the way I don't know any other compilable language that you could deal with this... and using some form of proxy classing instead is a headache.
Friend classes are just nice and sometimes they come handy. It's not really that big of a problem, but if you need them and don't have them again you have to use ugly proxy class pattern.
- 6. Take for example C# language:
We have some kind of class "Item" which has publicly settable/gettable properties(or fields or whatever) Cost and Type. Now you have them in a collection for example a List<Item>. You want to pass them this list to a function TotalCost that would compute the total cost. There is no way you can make the members of this collection not editable. Even if you use some form of ReadOnlyList<Item>, once you can get the Item you can set the Cost at will. In C++ however you simple use make: int TotalCost(const vector<Item> &items); What you were addressing were pointer const problems: const char *arr const; Now these are really ugly and unintuitive, however in C++ you try to avoid using pointers or pointer arrays as much as you can. Class function const: class Calculator{ ... int TotalCost(const vector<Item> &items) const; }; Now many of these const functions of the class are a pain and could be auto-detected by a compiler(one day perhaps): TotalCost impl{ func1 func2 func3 } -> func1, func2, func3 all do const operations on class Calculator therefore auto-const. Pretty easy to imagine, probably a little harder to implement... Function const parameter maddness: In C++ 95% of time you will be using just: const type ¶meter and type ¶meter; obviously some primitive types(int) don't need to use &. No big deal just some good practices that make you programming life easy and fun.
Once again I think there are many bad programmers in the world.. hence I may be one of them and not know it! Blame the people not the language.
Once again I think there are many bad programmers in the world.. hence I may be one of them and not know it!
Now you know! :D
+ Show Spoiler +kidding. but cmon man its ok to argue C++ because I don't use it a lot and haven't used it for years maybe ill slip up like i did in my first post, but now you are arguing pure OOP with someone who lives and breathes OOP
|
Just because it was built on top of C, doesn't mean he couldn't change some things, the changes he did make, just made it messy. Why do we use iostream and cout? What's the point?
He (Stroustrup) didn't invent std::iostreams. It's important to differentiate between the language and the language's standard library.
Indeed, iostreams violate one of Stroustrup's basic ideas with C++: you only pay for what you use. iostreams have a lot of tools for extensibility, character and encoding conversions, etc. But if you just want to format a floating-point value into a string, you're still paying for all of the cost of those points of extensibility (namely, the virtual function overhead for writing characters to streams).
3. Usage of operator and [], why can't it just be Board::[]?
Because it makes the parser much easier to write. And it makes it clear to the reader of the code that you're overloading an operator.
4. Why do nest classes inside a namespace block, but I don't nest method implementations inside a class block, but I nest method implementations inside the class block in the header, but I don't nest public methods inside public block?
Why does the public keyword automatically nest methods under it, and why does it have a ":" on the end? Why doesn't it follow standard C convention?
... what?
Public doesn't define a block. That's why it ends in a `:`. It's use is much more like the `case` statement, which also doesn't define a block. The public specification continues until another specification statement is reached. There is no block or scope involved.
It's funny that you say that C++ is more verbose, then you say that it's not verbose enough in that you should have to explicitly scope `public` methods or otherwise use `public` with every method definition.
Also, C++ has the `using` directive if you want to import a name into a namespace.
"const block" creates an annoying permission problem because of the way C++ handles immutability and type-safety. I haven't used C++ in a long time, but iirc if you declare a "const block", often the compiler will force you to declare other methods "const" that use it.
When you have a bunch of these, it actually becomes almost impossible to implement methods that are re-usable, or even do anything useful, because you try to modify `self` and the compiler cracks it because you are required to use this const block.
First of all, there's no "const block". I have no idea what you're talking about. The `const` you put at the end of a member declaration/definition defines how this is accessed. Think of a method as:
ReturnType MemberName(Parameters paramName) this {}
Except that `this` isn't explicit because it's a member.
When you use `const`, you're saying this:
ReturnType MemberName(Parameters paramName) const this {}
This making all uses of `this` const. That is not a "const block"; that's a "const member function". The `const` is part of the function signature, not a modifier to the "block".
Second, if you're having problems maintaining const correctness, that's your fault. If you call a `const` member, that function shouldn't need to modify the object it is a member of. If it did, then it wouldn't be `const`. So if you run into this problem, it's because your design is wonky.
Don't blame the tool for your own design errors.
Unlike Java, I rarely see people use the OO functionaliy of C++ like polymorphism to the fullest extent simply because of how clunky it is and how many problems it causes. Usage of ADT's in C often look and work better than the use of objects in C++, its kind of sad.
So?
OOP (by which I mean the use of derived classes in place of base classes through virtual functions) is one mechanism of allowing old code to call new code. That's one way to handle this sort of thing. C++ offers this, but it also offers templates, which is another mechanism for allowing old code to call new code.
Java has only one mechanism; C++ has two. So obviously, you're going to see less OOP-style derived classes when you have viable alternatives you could use instead.
Has it occurred to you that maybe they don't use OOP derived classes as much in C++ because there are better ways to reuse old code in many cases? That a template function which can work on any type, even those not explicitly defined to use it, is better than OOP? Or that maybe the OOP class model isn't the most flexible model in the world?
OOP is not God; don't worship it.
Also, I have never seen abstract data types in C that support easy virtual function overriding by outside parties. In general, if overriding happens, it's all done within the library. If you're an outside user, the best you get is a callback here and there.
ADTs are fine for exposing an object to the user. But they generally don't allow the user to customize that object with their own functions or alter the behavior of other functions that use that object.
|
On July 12 2012 05:13 NicolBolas wrote: Also, I have never seen abstract data types in C that support easy virtual function overriding by outside parties. In general, if overriding happens, it's all done within the library. If you're an outside user, the best you get is a callback here and there. Really? Why not? I'd think of it as simple as a pointer swap, and as long as you keep the interface constant it shouldn't be super hard (unless perhaps internal like the data definitions were hidden).
|
Also, I have never seen abstract data types in C that support easy virtual function overriding by outside parties. In general, if overriding happens, it's all done within the library. If you're an outside user, the best you get is a callback here and there.
ADTs are fine for exposing an object to the user. But they generally don't allow the user to customize that object with their own functions or alter the behavior of other functions that use that object
And all of those features are necessary because?
Virtual function overriding has nothing to do with OO and causes fragility within a program, the exact opposite of what OO is trying to achieve.
Has it occurred to you that maybe they don't use OOP derived classes as much in C++ because there are better ways to reuse old code in many cases? That a template function which can work on any type, even those not explicitly defined to use it, is better than OOP? Or that maybe the OOP class model isn't the most flexible model in the world?
OOP is not God; don't worship it.
Did you learn OOP from C++? If that's the case I can end this right here. Stroustrup invented this funky clunky paradigm and labelled it "OOP" when it really isn't, instead lets call it "Stroustrup-Liskov programming". OOP was invented by Alan Kay, guess what, he had no input on C++. They also hate each other, but its funny that Stroustrup tried to create an OOP language without any input from the guy who actually invented OOP.
Its also interesting how biology came up with a much more elegant solution to OO than mathematics did.
It doesn't even make sense from a pure OO paradigm sense, so it's no wonder you don't think its good. If you understand OOP from C++, you don't understand OOP at all.
First of all, there's no "const block". I have no idea what you're talking about. The `const` you put at the end of a member declaration/definition defines how this is accessed. Think of a method as:
...
This making all uses of `this` const. That is not a "const block"; that's a "const member function". The `const` is part of the function signature, not a modifier to the "block".
Yeah, but it looks like a modifier to the block.
Like I said, I forgot the term because it's been 4 years. Big deal, it seems you knew exactly what I was talking about, even though you said you don't know what I'm talking about.
My point is... what's the point of it? If I define a const member function, I can only use const member functions. Its stupid. There are sooo many better ways of doing this, that would also enable me to re-use more code.
Second, if you're having problems maintaining const correctness, that's your fault. If you call a `const` member, that function shouldn't need to modify the object it is a member of. If it did, then it wouldn't be `const`. So if you run into this problem, it's because your design is wonky.
I blame the tool for forcing me to use a wonky design (read the link in my last post). Just like Java forces me to use interfaces because implementation inheritance causes fragility, instead of just having duck-typing, traits, mixins.
I don't have problems maintaining const correctness, I have problems with const correctness making things impossible to read. Like I said previously, you don't need 4 ways of defining the almost exact same parameter when you can just use an immutable object, and there are 6 different ways you could ask for that parameter, those 4 different ways mean that you need to waste time manipulating your arguments to fit that signature.
In Object Oriented Programming, calling a ‘method’ (the Object Oriented name for a function) of an object gives an extra complication. As well as the variables in the parameter list, the method has access to the member variables of the object itself which are always passed directly not as copies. For example a trivial class, ‘Class1’, defined as
class Class1 { void Method1(); int MemberVariable1;} has no explicit parameters at all to ‘Method1’ but calling it in an object in this class might alter ‘MemberVariable1’ of that object if ‘Method1’ happened to be, for example,
void Class1::Method1() { MemberVariable1=MemberVariable1+1;} The solution to that is to put ‘const’ after the parameter list like
class Class2 { void Method1() const; int MemberVariable1;} which will ban Method1 in Class2 from being anything which can attempt to alter any member variables in the object.
Of course one sometimes needs to combine some of these different uses of ‘const’ which can get confusing as in
const int*const Method3(const int*const&)const;
where the 5 uses ‘const’ respectively mean that the variable pointed to by the returned pointer & the returned pointer itself won’t be alterable and that the method does not alter the variable pointed to by the given pointer, the given pointer itself & the object of which it is a method!.
Because it makes the parser much easier to write. And it makes it clear to the reader of the code that you're overloading an operator.
Overriding, not overloading.
I think its pretty clear from Board::[] that its an operator override. Second of all that's how other languages do it. Thirdly, writing language parsers is incredibly easy, just a little bit time consuming. It's pretty easy to parse anything.
Java has only one mechanism; C++ has two. So obviously, you're going to see less OOP-style derived classes when you have viable alternatives you could use instead.
Guess what? Java sucks too! This isn't a C++ vs Java debate.
... what?
Public doesn't define a block. That's why it ends in a `:`. It's use is much more like the `case` statement, which also doesn't define a block. The public specification continues until another specification statement is reached. There is no block or scope involved.
It's funny that you say that C++ is more verbose, then you say that it's not verbose enough in that you should have to explicitly scope `public` methods or otherwise use `public` with every method definition.
duhhhh, that's exactly what I mean. Yes, case is inconsistent too!
I think I made that pretty clear, public should precede a block {}. It takes ONE extra character, omfg. When C++ is not being verbose, its being inconsistent, it's almost never concise and consistent at the same time.
namespace foo { class Bar {
public: <<< wtf? method } }
It should be.
namespace foo { class Bar {
public { method }
} }
OR
namespace blah:
class Blah:
public: method
He (Stroustrup) didn't invent std::iostreams. It's important to differentiate between the language and the language's standard library.
Umm... yes he did.
The original iostream library was written to challenge the claim that a terse, type safe I/O system needed special language support. [1] It was developed at Bell Labs by Bjarne Stroustrup and shipped with the original C++ compiler, CFront and described in the first edition of Stroustrup's The C++ Programming Language.
Omg, no wonder its fucking terrible!
Although I thought I had made it pretty clear how C++ is inconsistent, and its added features are pretty near useless, in my previous post. Honestly, I think Stroustrup was on crack when he designed this language.
A C++ programmer may still be learning new things about the language after 10 years (which is bad). Why is this bad? have fun working in a large team of C++ developers. I listed 4 problems for a single line of code, that don't exist in other languages, you haven't really covered them.
|
Great Post! I dig the ASCII and opensource vibe. Although I'm not what I would call a programmer, I know my way around a command line (bash) and games that can run without a graphical environment always turn me on. =]
That said I'd like to address this vvv
On July 09 2012 19:56 Tobberoth wrote:Show nested quote +On July 09 2012 10:53 sluggaslamoo wrote:On July 09 2012 06:26 NicolBolas wrote:On July 05 2012 00:43 CecilSunkure wrote:On July 04 2012 17:29 Tobberoth wrote: Cool and all, but I'm surprised you say that writing console based games is a good start for beginners because they don't have to use black box libraries, yet the point of your post is to talk about your black box library, AsciiEngine. I mean, in the same sense that AsciiEngine sets up a lot of boring stuff for you so you can focus on making the game, so does SDL, difference being that SDL supports "proper graphics". I would think most beginner developers would get more benefit, and have more fun, makind SDL games over Ascii games. That does make sense, but since this is open source if someone wanted, they could use it simply as a reference point for starting their own project. That's the point I was trying to make, if that makes any sense. There are plenty of open source engines out there. AsciiEngine is not special in this regard. Personally, I've never understood why modern games would bother with this. There is no functional difference between so-called ASCII art and a regular tile-map. It's ultimately the same thing: draw a series of images of fixed size in grid locations. If you really want your tiles to be text glyphs, then put text glyphs in your tilemap. At least then, you'll have reasonable freedom to pick a good font that serves your needs. Dwarf Fortress is a pretty good game Which can be played tile-based just as good as it can ascii based... and it looks way better to boot.
A) Many people (like myself) find inherent beauty in the 'graphics' that were available before modern 'graphics'. Not unlike Brood War it's beauty lies in it's clearly understood limits, and when an artist navigates within those limits, but in a way that has never been seen before it more clearly shows the skill of the artist. B) Headless systems (without a monitor) sometimes need games too. These systems are usually logged into from a text-based interface which cannot display graphics that are not made up of ASCII characters. Admittedly this is more common among *nix computers I believe it can apply to windows as well.
|
On July 13 2012 01:48 DJXR wrote:Great Post! I dig the ASCII and opensource vibe. Although I'm not what I would call a programmer, I know my way around a command line (bash) and games that can run without a graphical environment always turn me on. =] That said I'd like to address this vvv Show nested quote +On July 09 2012 19:56 Tobberoth wrote:On July 09 2012 10:53 sluggaslamoo wrote:On July 09 2012 06:26 NicolBolas wrote:On July 05 2012 00:43 CecilSunkure wrote:On July 04 2012 17:29 Tobberoth wrote: Cool and all, but I'm surprised you say that writing console based games is a good start for beginners because they don't have to use black box libraries, yet the point of your post is to talk about your black box library, AsciiEngine. I mean, in the same sense that AsciiEngine sets up a lot of boring stuff for you so you can focus on making the game, so does SDL, difference being that SDL supports "proper graphics". I would think most beginner developers would get more benefit, and have more fun, makind SDL games over Ascii games. That does make sense, but since this is open source if someone wanted, they could use it simply as a reference point for starting their own project. That's the point I was trying to make, if that makes any sense. There are plenty of open source engines out there. AsciiEngine is not special in this regard. Personally, I've never understood why modern games would bother with this. There is no functional difference between so-called ASCII art and a regular tile-map. It's ultimately the same thing: draw a series of images of fixed size in grid locations. If you really want your tiles to be text glyphs, then put text glyphs in your tilemap. At least then, you'll have reasonable freedom to pick a good font that serves your needs. Dwarf Fortress is a pretty good game Which can be played tile-based just as good as it can ascii based... and it looks way better to boot. A) Many people (like myself) find inherent beauty in the 'graphics' that were available before modern 'graphics'. Not unlike Brood War it's beauty lies in it's clearly understood limits, and when an artist navigates within those limits, but in a way that has never been seen before it more clearly shows the skill of the artist. B) Headless systems (without a monitor) sometimes need games too. These systems are usually logged into from a text-based interface which cannot display graphics that are not made up of ASCII characters. Admittedly this is more common among *nix computers I believe it can apply to windows as well.
Man, given a few minor changes bash would make an awesome scripting language for games (espec text based ones), its so freaking fast but still feels similar to many of the modern dynamic languages. I actually created a grammar for a language inspired by bash, but I never got around to converting the resulting AST into another language.
On a side note, the best way to know if your language is good or not, is to leave it alone for a few months and come back to it. If you can't read it, you need to go back to the drawing board. I thought my language was so awesome when i wrote it, then I looked back at the examples 3 months later and no idea what it did, hah. Maybe ill finish it some day.
|
Bjarne only wrote streams, which laid a lot of the foundation but didn't have a lot of stuff that was in the initial version of iostream. Also it's considered rude to source a material from gamedev (who did sourced material to an interpretation of the C++ book) and not give credit >_>
On the other hand, here's the direct quote from the book itself:
"The stream library as described in the first edition of this book was designed and implemented by me. Jerry Schwarz transformed it into the iostreams library (Chapter 21) using Andrew Koenig's manipulator technique (sec21.4.6) and other ideas. The iostreams library was further refined during standardization, when the bulk of the work was done by Jerry Schwarz, Nathan Myers, and Norihiro Kumagai."
- The C++ Programming Language, Bjarne Stroustrup Page 11
Further discussion of the evolution of iostream:
C++ View: Jerry Schwarz reviewed the history of IOStream in the preface of the book Standard C++ IOStream and Locales. I guess that there must be many interesting stories in the process of transiting from classic stream into the standard IOStream. Can you tell us some?
Bjarne Stroustrup: I do not want to try to add to Jerry's description of the transition from my streams to the current iostreams. Instead, I'd like to emphasize that the original streams library was a very simple and very efficient library. I designed and built it in a couple of months.
The key decisions was to separate formatting from buffering, and to use the type-safe expression syntax (relying on operators << and >>). I made these decisions after discussions with my colleague Doug McIlroy at AT&T Bell Labs. I chose << and >> after experiments showed alternatives, such as < and >, comma, and = not to work well. The type safety allowed compile-time resolution of some things that C-style libraries resolve at run-time, thus giving excellent performance. Very soon after I started to use streams, Dave Presotto transparently replaced the whole buffering part of my implementation with a better one. I didn't even notice he'd done that until he later told me!
The current iostreams library will never be small, but I believe that aggressive optimization techniques will allow us to regain the efficiency of the original in the many common cases where the full generality of iostreams is not used. Note that much of the complexity in iostreams exist to serve needs that my original iostreams didn't address. For example, standard iostreams with locales can handle Chinese characters and strings in ways that are beyond the scope of my original streams. http://www2.research.att.com/~bs/01chinese.html (it's down for me but http://webcache.googleusercontent.com/search?q=cache:http://www2.research.att.com/~bs/01chinese.html worked)
Tbh I can't believe you're still posting things suggesting that C++ code is unmaintainable. I think it must be your goal on this forum to come in to Cecil's posts and start C vs. C++ wars.
Why not start your own blog post targeting it with first party sourced material and go from there?
|
|
|
|