First thing to say, I devoted most of my writing time to populate my French speaking blog. Of course, I'm going to continue (and I will expand it's brand new English speaking section with translations of my French blog tickets), but I'm also going to spend more time here - ya know, I have some WIP to present.
BTW, here is my latest English translation (for my blog (your remember? I just talked about that)): Traps of the delete operator.
At a first glance, everything looks easy. The delete operator is used to deallocate memory that has been allocated previously using operator new. It also executes the destructor of the deallocated object in order to free its owned resources.
Of course, it becomes more complicated when one sees that another operator delete exists, whose name is delete array in the C++ standard (its notation is delete , while the notation of the "normal" on is delete object). The purpose of delete is to free memory blocs that has been allocated with new array'' (new ).
The very first conclusion is the following: if a memory bloc has been allocated using new object it must be freed using delete object. If it has been allocated with new array then it must be deallocated with delete array. An operator error will have no effect on compilation but is likely to have a disastrous effect at runtime, the standard explicitly saying that the program behavior is unspecified in this case (5.3.5 ?2). This is the first trap of the delete operator.
I'm currently writing "SOMETHING". "SOMETHING" is a codename for a project I find cool. Here is an excerpt of "SOMETHING":
The first advice you'll hear (and one I often give, despite the fact that I know this is not a very good advice in the long run) is to think to object as representation of physical entities. This point of view idealizes the following idea: objects have properties (in many languages, we call them variables or member variables) and the goal of an object is to manage these properties. If we take the example of a RPG weapon, and following this definition, we'll create a Sword object with the following properties:
One can easily build simple class diagrams by using this technique and answering a bunch of questions. For example, let's consider again the Asteroid problem. First, we can enumerate the entities that are to be used: the ship, missiles and asteroids.
At this stage, it makes sense to create a Ship class, a Missile class and an Asteroid class. Since a ship can fire a missile, it also makes sense to have a relationship between Ship and Missile. No obvious relation between Asteroid and Ship comes to mind, but there's a loose link between the Missile and the Asteroid - although we're not sure at this point which kind of link it is.
I won't tell you more right now. Let's say that I'm going to post more excerpts in a near future...
Other thing of interest, I'm going to cover (for GameDev.Net) the FMX'07 show in Stuttgart. The FMX show is more about computer generation of images (there's even a projection of the lastest SIGGRAPH shorts) but a part of the show is dedicated to real time applications of these technologies, another part is dedicated to the Flash technologies and so on. So I think it's a valuable show - at least, since I can attend it, I think that its coverage should make a good GDNet feature.
The Flash conference is appealing. Peter Elst will speak about Flash development for alternative devices - guess what: the Wii -, Klaus Wahler will explain the 3 new AS3 UI components, and so on.
I will also try to meet recruiters - I know that a lot of people here want to get information on how they can get in the game/realtime content industry (you know that the cinema industry also needs talented programmers, don't you? For example, Pixar's Renderman is constantly evolving).
Finally, I just saw something weird:
You see? A rating of 1789. Being French, I must conclude that it's a GDNet hint that should telle me "hey guy, it may be the time to get a Revolution". So I guess I'm going to buy a Wii...