Another C++ question:
If "class::function" defines a function, and if on a program I call the function by using "objectname.classfunction", then I could say that the "::" operator is only used in class definitions, so outside the program body.
But then, if you're not using namespaces, if you want to use a function of the std library you have to use "std::cout". But it's not a definition, it's just a call.
Is "std" considered a "class", and so is the "::" operator used when you need a function in a class but without being able to call it from an object of that class?
Btw, the bad/good thing in using ancient C++ books is that they are usually C tutorials that at some point explain some C++ "perks". The more I follow the pattern the more C++ really looks like C with some minor programming extensions that only exist for ease of use.
Like classes. They exist in C and are called structures. As far as I understand the only difference is that the elements of structures are always public (and so usable from outside), while C++ classes can have both private and public elements. This helps reducing bugs, but it's also not THAT big of a difference.
The same about certain features that are C++ but were ported in the new C standard, like more strict type checking, or the possibility to use // comments. So where are the big differences?
Now I'm currently trying to figure out what makes references different from pointers. It's another feature that seems more subtle than significant (basically: references allow you to skip using the * pointer every time such a variable is used? Big deal.)
References are basically pointers which are guaranteed to be non-NULL.
:: is the scoping operator. Classes and namespaces both introduce a new scope, so the :: operator is used to refer into them.
A C++ struct is a class w/ default visibility public rather than private, yes. That's very, very different from a C struct, however, which cannot have methods. In particular, virtual methods.
Plenty of people use C++ as basically a slightly improved C, but the 'big differences' are more conceptual than directly obvious in the syntax. C++ (and OOP languages in general) makes it easier to do things like polymorphism and generic programming.
Things like references tie into it in that it lets you pass by reference instead of value, which makes it easier to treat types generically, where not everything will necessarily be a pointer. Combined with templates you can write containers and algorithms that work on a user-specified type, so you could write one sorting routine that automatically works on ints, floats, strings, etc.
Isn't this done by using a class with different constructors (so overloading the operator)?Originally Posted by Fugitive
Could someone give a look to the question I asked in the previous page (about what goes where)?
It's often done via std::sort.
That said, the templated class required for it is a bit of a pain, and leads to non-trivial code bloat. It's not uncommon for large applications to have their own templated sort routines available which make different sorts (heh) of assumptions. E.g., array_pod_sort() in LLVM optimizes for that environment's common case.
The general takeaway from that should be "use std::sort() unless you have a really good reason why not."
An example might make it clearer. This is an implementation of the standard shuffle algorithm with templates:
That function alone will automatically work for any indexable container, with nearly any type of object inside the container (as long as it works with std::swap). You don't need to write separate versions for a plain array of ints, an std::vector of FooBar class objects, a Boost::multi_index set of booleans, etc.Code:template <typename T> void shuffle(T& t) { for(int i = t.size() - 1; i > 0; i--) { int j = rand() % i; std::swap(t[i], t[j]); } }
Code:std::vector<int> v(20); // ... fill v with values... shuffle(v);
Well, I've yet to reach the part on the books where templates are explained, so I have no idea what they are yet ;)
I was simply trying to figure out what I can do with my subset of knowledge, and I think different values are usually passed through constructors. Though I'm not sure, so I'm going checking.
...so, what happens if I have a private variable "a" in a "class", of object "object".
I know that "object.a = 1" produces an error because "a" is private and so can't be seen.
But what if I use "object::a = 1" ?
Or, duh, "class::a = 1". If the variable isn't copied for each object in the class.
* small post that was informative but probably slightly wrong, so I deleted it *
Very quickly...scoping rules. There are 3 keywords: private, protected, public.
When defining a member of a class (what you just called a variable):
public means that all code anywhere can read and write to this member directly;
private means that no code anywhere but the class' own code can read and write to this member directly;
protected means that only the class and its subclasses can read/write to it directly.
There is no syntactical way to bypass this. The normal way to bypass this is the normal OOP pattern of creating public "setters" and "getters" on a private member:
(psuedo-code my c++ is rusty)
class XXX {
private string porn;
public string getPorn() { return porn; } // this is the publicly accessible getter
public void setPort(string updatedPorn) { porn = updatedPorn }; // setter
};
As you can see, the 3 scoping keywords can be added to methods as well as members, with the same effect.
You were also asking about std::cout and such. The topic to read up is called "static class variables" and "static class methods". You use these to make global variables and functions, just like the C days. Use these sparingly...in today's world, you should only use such technique to make a "Singleton" object, usually for the purpose of making a "Factory" object. These are OOP design patterns that you should read up on, once you get the hang of making an object class.
Some of that I knew, though I think they used also "static". Not sure if it's gone out of standard.
Anyone can give a small list of tricky or obscure or usually neglected but still important language features so that I could use then to compare between the different books? It would be handy.
That's not generally how you want to compare books unless you really want to make a habit of always using tricky and obscure corner cases of the language standard. Good entry level books usually intentionally steer very clear of those sorts of things. Note that because they are important doesn't mean that you'll ever realize they're there in day to day programming.
No, but it lets me see how well a book explains things, and how complete it is.
Anyway, looking at roguelike makes you continuously discover small features that need to be stolen ;)
See this:
On screen chat bubbles! Brilliant idea! (and source code to see how they work)
Continuing this conversation here.
Maybe I should go with the Use + direction. But what if I want to be able to cast a spell directly on an enemy at long range? In that case the direction system doesn't cut it and I'd have to use the 'Target tile' system that I'm working on.
Maybe the best compromise is using:
I. Bump into an object with direction keys, perform default action, or if there are several actions get an action menu such as:
1. Disarm
2. Unlock
3. Bash
II. Use separate targeting system for long-range actions
That looks like a great feature. I could see using it both with monsters and NPCs.No, but it lets me see how well a book explains things, and how complete it is.
Anyway, looking at roguelike makes you continuously discover small features that need to be stolen ;)
See this:
On screen chat bubbles! Brilliant idea! (and source code to see how they work)
Use+direction is indispensable if you are interacting with objects nearby. What if you have one door north of you and another west, which one to open? Or two chests.
For long range you can look at Cataclysm again, even the tutorial. Long range is based on Line of Sight, so you draw a line to a target with the usual formula to draw lines in digital spaces.
They are different things. "Bump into object" is movement based, and all movement-based action can be defaulted to some command (as long they aren't risky).Maybe the best compromise is using:
I. Bump into an object with direction keys, perform default action, or if there are several actions get an action menu such as:
1. Disarm
2. Unlock
3. Bash
II. Use separate targeting system for long-range actions
Firing at something or launching a spell is a deliberate command you give. It's not automatic or based on movement (and an "use" generalized command doesn't make much sense to me, use what? a wand, a firearm, cast a spell, these require their own command). It's not simply a targeting system, it's an action that requires targeting as a component after you give the command. Maybe some spells are only cast on "self", so you wouldn't need any targeting.
When targeting usually you visually draw a LoS line to the nearest character, then let the use move the aim around manually, or use some scroll keys to toggle between visible targets. Maybe you save the position on the monster you last fired on (as long it's not dead), so that for consequent shooting you don't have to adjust targeting again.
For implementing LoS I think there are tutorials, the formula itself should be relatively easy to cut&paste. LoS is usually calculated by making the program draw a line to a specific cell. In case of targeting you don't just call the formula in abstract, but you also draw the line on screen so that the player can see what he's shooting at.
Those are some good points. I need to do some more experimenting with the interface.
Yesterday I got sidetracked by working on my message log. Basically, I have a FeedBackSection class, that's instantiated by my Screen class, which takes care of clearing a number of lines at the bottom of the console, and showing text there. My idea is to have various objects send messages to this class, which are then shown in order, with older messages disappearing off the screen. For example a Container object can send the message "picked up <item>" and a Critter object can send the message "attacks <target". The Look function should send the description of the object on the tile where the cursor is as a message.
Edit:
Ok, a primitive version of the message log is working. It currently only shows one message at a time. It will be updated later. I also worked on the Use + direction functionality. It can now be used to loot containers and disarm traps (if your dexterity is high enough), adding them to your inventory. Since traps inherit from TileObject which is different from InventoryObject, I made all traps have an InventoryObject instance as a variable. That object is put in the User's inventory and the TileObject is destroyed.
Last edited by jeansberg; 08-16-2012 at 08:34 AM.
I have question about C# code in general. Right now my classes use a mix of public variables on one hand and properties that access private variables on the other hand. Is it a good idea to just make everything a property instead? Is that the 'correct' way? Are there any drawbacks except more lines of code?
The 'correct' way is to use getters and setters. By funnelling all access of a member to its getter/setter, they give you the flexibility to insert new code to enforce new rules around that variable by just changing the getter/setter, without needing to update all 20 other places that are using/updating its value.
The classic example is to add validation code around the setter. Another good example is to add extra thread synchronization code around the setter/getter.
Yep, they can definitely be used to add some useful functionality. Auto-implemented properties can also be written on a single line nowadays so there isn't much hassle. I think I'll go with using properties throughout my project. The consistency will also be aesthetically pleasing to me. :)
Silly question:
say you have to load at different times a number of objects in your program, and then when you exit the program these need to be unloaded in their order. And say you also have some error handling that may exit the program at any time, and still needs to unload those objects properly anyway.
How do you keep track of this since you can't say at what point the program exits, and what is already loaded or not?
The only idea I have is to have some sort of global vector where you store the name of every object loaded.
Congratulations, you've reinvented garbage collection!
Let objects just fall out of scope and clean themselves up whenever possible. For longer-lived, dynamically-allocated objects, establish the ownership relationships between objects, so that you explicitly know which class manages which other classes. You'll often wind up with a hierarchy of objects, and each layer just takes care of its own objects.
E.g., in a simplified example, your engine might have a World object that gets deleted as the engine cleans up. World then contains Levels and cleans them up as it's being deleted; Level contains Map, Player, Monster objects and cleans them up; Player contains a list of InventoryItem objects and takes care of them; each InventoryItem cleans up whatever container it's using, and so on.
Proper error handling is a whole other topic, but as long as you've got the right ownership behaviour worked out, it should mostly take care of itself as you unwind from wherever the error occurred.
Unless by exiting on an error you mean it's doing an "exit(-1);", in which case all bets are off, only global objects will be fully destroyed. If you really do need objects properly cleaned up in a case like that, then some kind of global registration would be appropriate.
For Jean:
yeah, just use properties, it's easier to switch them back to public members if you need to, but also easy to turn them into more full blown set/get logic later if need.
public int Foo {get;set} is pretty easy. it's not perfect though, since it's no longer getting properly initialized inline, but hey, that's what constructors are for.
For HRose:
Fugitive has the right of it, though you should also be wary of having too much criss-crossing of classes and pointers. Life is a lot easier the more self contained things are, and your issues may be related to having too much intertwining amongst your objects.
Ah, also had another:
since I plan in the beginning to throw everything and the kitchen sink in, is there some tool that checks for dependencies?
I mean, the program will always run fine for me since I have everything set up. But how can I check for all the libraries and dlls that need to be packaged with the file?
Dependency Walker can do that, and it's one of the tools I always keep close at hand. The runtime dependencies may be more than just a DLL though, it might expect data files to be present somewhere or something, but that'll vary wildly from library to library.
virtualbox or other virtual machine?
maybe you can have a snapshot of windows xp, and restart to the snapshot after finishing. you can test it there after every mayor change. Or you can have a groups of friends, and share builds with these people from a dropbox or similar thing. But vmware is easier than having friends :foreveralone: :(
you could also publish the builds in a game devs forum (indies?), that way you will get feedback from other devs, that can be just fun. Just make sure that is not enough for you, or you will be building games for 3 persons.
OOOHHHHHHH!
http://blog.pixelpracht.net/?p=340
Short version: http://web.pixelpracht.net/fovdemo.php
Do you know why I will never be a game developer? because I only need to look at a page like this, and I would be writting a "Thief" like game in 2D, with guards having torchs that generate light that way. Basically singleplayer MONACO. But then I would be reading some shit about minecraft or dwarf fortress, and I would be wanting to adding squad controls, mining, crafting. This why I am not gamedev... on top of a lot of other things (not being the bigger that I have no idea how to make something that is fun).
It's being done by usual suspects:
http://www.mkv25.net/dfma/movie-2456...g--visionsound
Posting Permissions
Reply With Quote