At 10/28/09 02:02 PM, nathanallenpinard wrote: Stan SB is using a melodic minor, OR basically a major scale in the dorian mode (starting from the 2nd note in a major scale, using the 2nd note as the root key)

Is this Dorian mode used as (un)commonly as the melodic minor? Is there something particular in the song which makes you suspect it may have been used?

At 10/28/09 10:28 PM, Glaiel-Gamer wrote: still doesnt make sense to me that you're casting a pointer type (char*) to an integer type (long)

I would guess that he had an error, and casting allowed compilation.

To the OP, look into the L and _T(...) style macros. For instance:

SendMessage(hWnd,CB_ADDSTRING,0, L"b lah blah blah"); // L not a typo

CronoMan's response is correct, I believe.

At 10/28/09 10:45 PM, Alphabit wrote: I have an iostream object and I need to read from it as fast as possible...
I have to parse a file that contains over 800,000 characters and I have to try to get my algorithm to work under 5 seconds but I currently get about 9 seconds...

File I/O kills performance. You should read the data in large "chunks" to avoid accessing the file as much as possible.

It sounds like you may understand that already, however, from your original question ('one character at a time...'). If that is the case, then Google should suffice. This C++ ifstream Reference is sure to offer something useful. A quick glance at the read function looks promising.

The usual advice, as I'm sure you've gathered, is to guess or "develop a feel" for it.

This question is common, so research on the topic is as well. A good starting point might be the NEAT, or Neuroevolution for Augmenting Topologies, paper. Google Scholar should find a copy without much trouble.

At 7/15/09 09:00 PM, Xenolithic wrote: With Relish's fixed mistake above, the code does work. I did a little tinkering with it, and have this:

Watch your visibility levels--prefer least privilege where possible (private to protected, protected to public). Member variables, in particular, should be private nearly always if well principled design is a goal.

Otherwise, this is fine for a start. The subtleties of dependency management and abstraction, not necessarily wrt OOP/D only, should be examined eventually. More recent versions of PHP (5.3+) I THINK allow for function level types of abstraction and encapsulation, and I believe even older versions of PHP have been able to duck type to an extent.

As always, I'll recommend the SOLID principles as a good "next step" after basic OO terminology has been understood--things like inheritance, dynamic dispatch, interface, override, etc. From that point forward, though, I would encourage critical review of the available literature, as is is sometimes suspect and very often has strong opposition, no matter the topic (and vice versa for the opposition). The paradigm itself, for instance, falls into this category.

cstring is the standard C library with some slight modifications (std namespace, probably not much else) for the C++ language.

In C, strings are represented by char[] or char*. Strings must be null-terminated.

Check out the cstring reference for function signatures and uses. This sounds like a homework assignment, so I'll leave it at that. Google will be generous on this topic.

As it relates to practice, the particular method of calling the function in the example given violates the Law of Demeter. From what I have read, many developers have mixed feelings on this particular rule, however. YMMV.

Long is the way, and hard, that out of Hell leads up to light.

Programming is difficult. The more code you write, the easier writing code becomes. Learn, practice, repeat.

this.nextP.addEventListener(MouseEvent.C LICK,nextPage);
function nextPage() {

Your event listener should take an Event of some sort as a an argument. In this case:

function nextPage(e:MouseEvent):void

As you have it written, your function expects 0 arguments since it is defined with 0 parameters, but when the callback triggers it tries to send it 1 argument of the type MouseEvent.

What are you calling "good encapsulation"?

As design in general goes, giving your objects knowledge of the event system couples them to that event system. Moving event handling logic out of your objects into another class or set of classes would actually be a better design and, in the former case, possibly be more efficient (and maybe simpler as well).

Think about it like this: right now your objects are expecting mouse clicks from the event system. If later on you decided that you want your game to be multiplayer, mouse clicks from other players in the game would have to be received through a socket as a binary packet or some XML--in order to compensate for this, you'd have to rewrite every single object that expected 'mouse click' messages from the event system to also listen for and parse packets from a socket.

Unless I'm misunderstanding, this isn't really a case of encapsulation vs efficiency, but more of straightforwardness versus poor design/efficiency. This is sometimes an argument worth making. I'd still decouple my objects from the event system, but ymmv.

LOUD NOISES

Delta and I have the same birthday.

True story.

Fellatio, mostly.

I've only glanced at the posts here, so someone correct me if I'm answering a question that wasn't asked.

The "protected" visibility level gives derived classes access to a the specified variable/method in a parent class. The "internal" visibility level gives the entire package access (iirc, I never use this myself). I think "protected" is what the OP thinks he/she wants.

Good design would say, however, that you should keep your variables private and provide methods which mutate/access them. If you're afraid that the variable will be placed into an invalid state by client code, then there's no promise that future derived classes won't also do that. Instead of accessing the variable directly, try to access it through the functions the base class provides publicly.

With interfaces though, are the interfaces you are speaking of meant to be some sorts of 'read-only' interfaces whereby only 'get' methods are exposed to avoid the classes from altering each other?

They can be read-only interfaces if you want them to be. Many games are set up so that entities have the ability to spawn other entities, such as a guy firing a rocket. More fine grained designs might have a guy who owns a rocket launcher, then the rocket launcher fires the rocket. It just depends.

As an aside, read only interfaces are a questionable practice (but one I support on paper). The idea is to prevent mutation from occurring on an object, but by exposing get methods they return references to the data which can then be modified anyway (this is a problem even in non-read only interfaces, and I'm assuming non-C++). They do help convey intention, though. It's really a question of pragmatism... kind of sucks having to do so much work and introduce so much complexity for every class you ever write--the tests, the class, the interface, the read only interface, possibly fake objects, etc. Anyway, that's neither here nor there, I guess.

They're all judgement calls. For example, if your original design worked, then it worked. Just because I have an opinion doesn't make it any less viable. There are trade offs for each decision you make, but there aren't generally any unequivocally "good" or "bad" routes.

The thing I'm worried about with having each entity being aware of one another is that it doesn't promote loose coupling between them.

Right. One thing that observers/events *do* do is eliminate the direct coupling of objects, though at the expense of complexity, various run-time issues, communication protocol establishment, etc. I haven't thought through it, but you could probably write your entire program so that it communicates exclusively through the event system leading to THE ULTIMATE DECOUPLING at the expense of your sanity. There's a time and a place, and this may very well be a good example of a time and a place to employ these kinds of things. In particular, decoupling the rendering of the entities from the entities themselves is always important as your game's physics should nearly always be updated at a fixed rate, while your rendering should happen at your (variable) framerate. Another example might be a networked game, which required rendering on a client's machine, but would need the rendering system easily-removed for a server. Thus it's important that the rendering portions of your code know about your entities, but it's essential that your entities have no knowledge of a rendering process whatsoever Observers are a common solution here (though not the end-all by any means).

As for entities knowing about each other, this is more of a judgement call. In most people's opinions that I've seen, it isn't unreasonable for an entity to know about other entities--that makes perfect sense when you think about it logically in most cases. Thus creating some sort of EntityPool-like object which knows about entities and entities which know about the pool makes sense.

One of the big issues with that approach, though, is that it creates a circular depenency. This almost always can be broken by programming to interfaces at the object level, an approach described by the Dependency Inversion Principle. Attached is an image showing how this breaks cycles. Programming to interfaces like this is, then a good default approach. Many say that you should never depend on concrete classes. Also, the arrows in the diagram represent dependencies. For example, Entity depends on IEntity because it implements it and IEntityPool because it uses it (it has knowledge of both of them).

Dependencies become even more important as you partition things out into namespaces/libraries/programs/packages/w hatever as it's important to determine *where* the interfaces should go. The placement then determines which package becomes more reusable.

For instance, you could create two packages--one which has your concrete EntityPool and one which has your concrete Entities. The question is, then, where to put the IEntity and IEntityPool interfaces. If you value the reuse of your Entities over the pools, then you could put the IEntityPool into your Entities package along with IEntity. In this way, the EntityPool package *depends* on the interface provided by the Entity package. Your Entities can be reused from program to program so long as something in the program implements their IEntityPool. The opposite could be true if you valued more your reuse of the EntityPool and packaged your IEntity interface with the pool package. Alternatively, you could package your interfaces with their classes as well as interfaces that they expect to be implemented and write a package of adapters that could be used as a translation layer from one package to the other, if it really became necessary. In this last case, each package would be easily reusuable, but the 'adapter' package would generally not be (though it would likely be straighforward to write).

Anyway, there are lots of options out there. Right tool for the job and all that. Different people have different opinions, but most people will agree that the simplest thing that'll work is the way to go. If you feel like your current setup is the simplest way to achieve everything you need to, then you're probably in the clear!

I read some definitions on Wikipedia but I don't think my Manager classes fall under the God object category

I know. I tried to preempt this in my last response:

You may not immediately feel like this is the case [...]

...but I'm not sure why. I knew it wouldn't do any good anyway when I was typing it :p

The Wikipedia (and most descriptions) are a really basic "God objects just do too much stuff" sort of definition. Most people just follow the general rule-of-thumb that anything that has a "Manager" (or something similar, highlighted in my last post) is a red flag and end up accidentally creating God classes which don't require the word "Manager"--this is the main reason I pointed out the CoffeeMaker example. Your example is more explicit, though, since it uses these names.

These sorts of naming schemes ("manager", "system", etc) are a bad idea outside of the whole "God object" argument because they don't convey the responsibility of the class. What is a "manager"? What does that mean? Does it manage the lifetimes of the objects? The communication between them? Access to them? Updating them? What? All of the above and more? For instance, if you were looking to wrap what was essentially a collection of entities into a more abstract class form, you might call it an "EntityPool", as object "pools" are common and their intent is well defined.

because they don't really do that much by themselves; they delegate a lot of responsibility to entities; it's like a company and employees; the company may looks like it does a lot, but the employees are the ones doing all the actual work.

The idea is that objects should be wired together when they're created, and then act as a system from there--there generally should not need to be a "manager" or a "coordinator" or anything like that acting as an intermediary for them. "Wiring" can be done in a factory without too much fuss. A loose analogy to networking would be a star topology versus a mesh topology.

Passing this system (or parts of it) around in your program can be difficult. The solution to this problem relates heavily to your perception of your manager objects and can be answered in (since we're talking patterns) the Facade pattern. The Facade is essentially an interface to the interconnected system of objects that you should be creating, which acts as a simple delegation mechanism, as you described.

Facades aren't too bad, but can be limiting in some cases. When you start adding additional behavior to a Facade, in particular using it as a way to pass messages back and forth from the objects it "wraps", it becomes a Mediator (and tends to require its dependencies to send events for communcation). The Mediator pattern, unfortunately, is essentially a borderline God object.

Mediators, even used appropriately, have a tendency to become complex, dependency heavy, and are pretty much never reusable (which sucks since they're generally complex). As well, they generally force their 'colleagues' to employ observers/events for communication with the mediator (though this is also advantageous for other reasons), building on the complexity.

Sometimes you gotta race, though. While my own personal philosophy is to avoid them where possible and reasonable, they do have their advantages. The situation you mention is one of the places it is, in fact, commonly implemented--though not ubiquitously. Just be careful, I guess.

I just found that the MVC is a little ambiguous when it comes to making games because MVC makes it difficult when you're managing lots of visual components that interact with each other...

The original MVC pattern was intended for really old school GUI apps. From what I've ready, it isn't even suitable for regular windowed applications these days. Other patterns have emerged (variations on MVC, MVP, humble objects, etc) to compensate, but the variations are so wide in number that I think the lines between them are all blurred into nothingness. Writing what makes sense in your specific case makes sense (though I would support a 'tiered' myself).

if each unit is treated independently without any means of being directly aware of one another.

It's okay for units to be aware of one another... I may be misunderstanding, though.

[interfaces]

I think the description of the idea of an interface/purely abstract class is misplaced here... that's an enormous topic on its own, and I don't really see how it relates. I know, I know: "bitch, bitch, bitch"... but I think this topic deserves its own study. The dependency breaking that these interfaces cause is hugely important in OOP in general.

The entity manager receives events (including GUI events) from the game manager and alters the models of the given entities accordingly.

This is confusing for me. If the game manager is dependent on the entity manager (it has direct knowledge of the entity manager), why not notify it directly instead of via an event? Or is that what you meant? Or am I misunderstanding?

The renderer does not interact with the user; it merely fetches new data at a set frame rate and renders any changes among any of the models (entities).

How are the entities fetched? Does the renderer raise an event which signals the game manager to populate it (the renderer)? Or does the game manager poll the entities and push the data into the renderer?

Comments are welcome.

First, it sounds like events are being abused here. They are, of course, frequently a good thing to have, but they do add a heap of complexity and should be avoided when they can be, imo. But whatever gets the job done, I suppose.

Second, you were right to spot this pattern as it is very common, indeed. Unfortunately, it's a very common antipattern, more commonly known as a God object. You may not immediately feel like this is the case, but it is (from the wiki: "Be very suspicious of an abstraction whose name contains Driver, Manager, System, or Subsystem"), and it's one of the worst kinds as it's a very explicit, intentional implementation of the antipattern. To be honest, I believe that most programmers write God objects *by default* without realizing it. This article on God objects is what initially opened my eyes to that train of thought.

I need to look into flash at the base level more some time. So primitives are all that the bytecode handles?

Sort of... the AVM2 bytecode can be pretty abstract when compared with typical "assembly-like languages". The bytecode standard (or whatever this document on AVM2 opcodes is) explains what values certain opcodes expect--generally a primitive or an index into one of several tables (which in turn could contain references). That may not be relevant, though.

I've always thought that the phrase "pass by reference" was a big misnomer when used alongside "pass by value". Nothing is ever passed by reference. You can pass *a* reference, but the reference itself will be passed by value (copied). The canonical example is a swap method of the form swap(a:type, b:type):void, where the values are swapped in a side-effecting manner.

In C#, you can pass a reference to a reference by using the "ref" keyword before your parameters. In C/C++, you can pass pointers to pointers and other things like that. AS3, in standard fashion, has no explicitly defined mechanism for doing this sort of thing.

with as few private member variables as you can manage.

Just a small clarification: you should only have private member variables generally, the exception being a class with only public data members and nothing else (to act as a logical grouping--C style struct). I didn't mean to imply that you should minimize private variables by upping their visibility or anything like that.

supery9:
The Gimp as mentioned. Unintuitive interface in traditional "open source" style, but it's more than good enough for any non-professional (and decent enough for professionals, though Photoshop does edge it out in many cases).

Glaiel-Gamer:
Your capital O "Object" makes the question ambiguous for me. If you're talking about the base "Object" that everything derives from, or if you count dynamic objects (which I do not use), then I'm not sure. If you just mean any random object build from a non-dynamic class, then the answer is no, not really. Just write a clone method and be sure to look out for "Rule of Three"isms (from C++ which, iirc, you're familiar with). It MAY be possible with introspection, but I doubt anyone would suggest an approach based on that. I've never messed with introspection, either.

On a likely-not-related note, classes should be kept small with as few private member variables as you can manage. WRT that, clone methods shouldn't be difficult or time consuming to write, if that was your conern.

Is there any sort of error or exception thrown?

This sort of situation can sometimes happen when there's no cross-domain policy file on the server (for security reasons).

At 2/4/09 10:18 PM, Stelimar wrote: The simplest way would be to just use the win32 API

There are lots of other frameworks/toolkits/whatever for writing "windowed" applications... wxWindows, GKT, QT, MFC, etc. I think most people would say that straight Win32 is the least accessible of the bunch... but of course it varies by individual preference.

At 2/1/09 10:48 AM, Wonderful wrote: XSLT is a client-side language, and will not work for everyone (depending on their browser).

XSLT is just a language. PHP5 has 'standard' classes for processing it, clients can process it... I think Javascript may be able to as well (not sure).

To the OP, it isn't uncommon to use a combination of XML, XSLT and PHP. Run queries, translate the queries to XML, process the XML via PHP (sending generated XHTML) or client-side. Any performance concerns are "supposedly" unjustified the code (and scalability is more important), compared with templateless or PHP templating solutions, is actually LESS complex imho, so there's no argument for complexity, either.

I don't understand.. I tried to print out this:

My mom said, "Go to the store and get some milk"

and it didn't work:

<?php
echo "My mom said, "Go to the store and get some milk";
?>

?????

At 1/28/09 12:50 PM, elbekko wrote: No duplication of data or storing computed values unless absolutely necessary. Easy as that.

Listen to elb's advice here. Look into Database normalization. Your database is tiny, so chances are there won't ever be a reason to violate normal form. Hit the third form and run your queries through EXPLAIN and whatever else there is and you should be more than fine.

If your goal is to avoid TDWTF, make things as simple and straightforward as you can. Easy to write, easy to read, easy to use... not convoluted for mythical reasons related to efficiency.

and just making an array of points with new.

It's nearly always a better idea to use std::vector or some other container versus a naked array. The standard library containers are generally as performant as can be made a container for general purpose use and are really necessary for idiomatic C++, utilization of all of the (good) stuff in algorithm.h, etc. It might not be immediately obvious, but by littering your Polygon (and other) classes with code relating to array size management, traversal, etc mixes the responsibilities of the classes you write and leads to a bunch of repetitive code (which is bad for reasons far worse than "it's annoying to write").

Option 1:
Pass in the number of sides to the constructor. This information becomes part of the state of the class.

There are similar, but not exactly identical options congruent to this approach. For instance, you could use constructor-based dependency injection and, instead of passing in the number of sides, pass in actual Side objects (in a vector, list, array, whatever). Side objects could be constructed by taking in a container of Vertex objects, etc. This approach may seem a little convoluted to the OP at this particular moment (would require factories, or some similar mechanism for instantiation), but the point is that similar 'spins' on this approach exist.

Option 2:
Use inheritance to inherit various polygons from an abstract Polygon class. This solution works if you need to have very distinct behavior for different shapes.

I think you might be better off with the first option. By using a constructor, you can set the number of sides for the object whenever.

A third option would be to just not inherit from a Polygon base.

In CS, the is-a relationship that inheritance represents isn't always modeled as you'd expect. For instance, it might make sense for a Polygon class to have a add_side member function, but when you derive a Triangle from the Polygon, you end up overriding the add_side function with a stub. The standard Liskov substitution example, in particular, shows the dangers of trying to derive a Square from a rectangle, for example.

Additionally, inheritance models a very tightly coupled relationship. The general rule of thumb is to avoid it where possible in favor of an association based approach (option 1 or similar). In general, save inheritance for when you are absolutely sure that you need to treat your objects polymorphically, and even then it may be worth considering a hierachy based off of adapters (but that may be pretty extreme :p).

In the latter case, the inherent problems aren't really resolved, but they're isolated to the (lightweight) adapter classes to avoid any Open/Closed violations on the actual (heavy) Triangle/Quad/etc classes. This is a little bit OT, but it's important to put effort into ensuring that your derived objects don't conform to the base class' interface 'against their will', and adapters are a good mechanism for avoiding that. Still, in this case it's more of a preemptive fix for avoidable poor design choices.

To be completely fair, CAREFULLY writing a base Polygon interface MAY be okay for most cases.

They allow the compiler to create the specific type at run time as needed.

Just a clarification here... templates are resolved at compile time. C++ compilers don't operate at run-time ;)

So learning C++ might not be as useful as learning something in the .NET area.

I had wanted to sidebar this out in my original post, but decided not to. If the definition of 'useful' here is taken to be how the knowledge of a language affects your chances in the job market, then C#, I would say, is much more 'useful' than C++ by a widening margin. In that sense, though, it's probably on par with Java and possibly even less 'useful' than PHP/VB (see a pattern?). It's really a matter of what the OP's goals are specifically. If they're to become a better programmer, I'd still suggest C++. C# is by no means a poor choice, though, if the OP wants to focus on something more practical in terms of employment going forward.

And to the OP, I was hoping my 'hello world' analogy would have been an obvious exaggeration. The point is that you don't know the language well enough to say that you 'know it', and the same is likely true of other languages you claim to know. You wouldn't have made this post if it weren't.

If you're hellbent on 'learning' a new language, and crossing the paradigm boundary proves too difficult (as I imagine it will be due to your AS3 reactions, which doesn't even cross said boundary), then C# would actually be an okay route to take, I guess.

At 1/1/09 09:39 PM, Glaiel-Gamer wrote: I'm making a polygon class right now, and seeing as I'm still relatively new to c++, I have no idea when it's appropriate to use a template class.

Templates are used to allow classes and/or functions to take in different types. Think about writing a basic linked list for, say, polygons. Each node in the Linked List would have a Polygon object (you'd be writing a PolygonLinkedList). Later on and somewhere else, you decide you need a linked list of Vertex objects. Now you have to rewrite your entire Linked List classes, all of which will be identical to the PolygonLinkedList, except with your 'Polygon' types changed to 'Vertex' types. Templates allow you to write a LinkedList class once and, whenever you go to create a list, specify the type *then*.

As an aside, std::list is a standard, templated linked list.

Basically I'm making a "polygon" class (which I will expand into a rigid body engine but that's not the question here), and I want to be able to pass it a variable number of edges. Is it better to use a dynamically allocated array for this and pass it a number in the constructor, or use a template class and reference it as Polygon<#sides>?

A std::vector should be fine. Templates don't make too much sense to me here. Entire books have been written on templates, so I'm not saying it isn't possible or anything... but I doubt it'd be a good idea to use them in the way that you're trying to.

Every time you instantiate a class based on template (or call a function based on one), a new class is generated by the compiler. Increased compile time, potential cache thrashing and code bloat occur because of this. This usually isn't something to worry about, but if you plan on the #sides varying a lot, then it could become a problem.

Beyond all of that, you might reconsider your approach. I don't know the specifics of what you're doing, of course, but it may be a better idea to write a Triangle, Quad, etc class. Generally, the math and rendering processes for different sided polygons varies greatly and having an all-encompassing Polygon could ultimately be more trouble than it's worth.