[help] java roguelike development insight needed

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Hi,

I finaly decided to put my first roguelike together, i've put together
my world, What rules will be like ( like classes, skills, magic ...).
So it's kind of ready to be played in pen-and-paper fashion.

What i lack is experience in doing roguelikes (but not programing
overall ...).

So, can anyone point me to design pattens usefull for adom-like complex
game?

What dangerous structures are there waiting for me to discover, use and
loathe?

Now, i'm putting together some basics, like item data model, character
data model...

For example:

Items should all be descendands of object Item ... like Weapon class
and Armor inherits from Item class that has generics, but i don't want
Item class instrictally know how to work with Blessed or Cursed status,
and i don't want to implement it in all apliclable subclases ( that
code will be always the same ... ) and this goes to other stuff to (
Durability of item ... )

Another problem is how to handle ego items. Since i want to employ
Diablo II-like item model with socketable items, runeword-like
abilities, sets ... lots of customizations. All of this having lots of
triggers for special actions ( onBeingHit, onTargetDestroyed ... ).
Currently, having have each item list which contains Object of
MagicItemMod interface and another List which can contain other items
imlementing InsertableItem

(I know how to google for i.e. map generation or so ... i just want
real live answer)

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Filip Dreger wrote:
> Probably you are going to loathe your Object Oriented approach
> This is one of the hot topics here, it got discussed a couple of
> times; one of the last OO Java champions, Slash, used to have some
> really cool posts on doing the OO stuff "the right way", but he seems

> a lot quieter now; and just some time ago he posted a little advice
in
> the lines of "beware of overengineering".
> The ideal OO structure for a roguelike seems way to complicated to
> implement in a straightforward way, just by translating "sword" into
a
> "sword class" and having the "magic sword" inherit from it. It seems
> better to have a generic "item" class.

Well I found this out a long time ago. Now tell me how to make a
generic class for items,beings and world cells ) coz that seems even
more sophisticated.

regard,
Kate

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Twisted One wrote:

> You may want to seriously rethink your choice of language.

Not every RL developer is capable of speaking in every (computer)
language in existance like you IMHO. I'm working mine on Java, and I
like it that way so I'm sticking to it.

Back to topic:

My Java skill is too limited to lend you any insight, though. But as
soon as you have some runnable classes, I'm glad to be a tester *grin*

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

You may want to seriously rethink your choice of language. For really
complex roguelikes you want a functionalesque language with closures,
comprehensions, or some such and dynamic typing. Smalltalk and Python
are candidates; C's static typing makes it more problematic, and Java's
rigid static typing makes it an even worse choice. If you're accepting
the overhead in memory use and slowness that result from implementing
your game on a virtual platform (i.e., it runs as bytecodes on some kind
of VM or is otherwise interpreted) you may as well use Smalltalk or Python.

Both let individual objects actually acquire new methods at run-time in
fact, which can be very useful if, say, something can become Wearable
all of a sudden. Smalltalks sometimes allow object mutation, and at the
very least you can override doesNotUnderstand: to catch attempted calls
to a method with no static implementation. (You'll end up with code for
wielding like theItem isWearable ifTrue: [theItem isCursed ifTrue: [stuff]])

Python makes it even easier since you just create a functional object
(one that can be called like a function) with suitable parameters and
assign it to some attribute of some object and presto: that object now
accepts a new instance method!

--
http://www.gnu.org/philosophy/right-to-read.html
Palladium? Trusted Computing? DRM? Microsoft? Sauron.
"One ring to rule them all, one ring to find them
One ring to bring them all, and in the darkness bind them."

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Twisted One wrote:
> Python makes it even easier

If it was that much easier then we would be probably all programming
with Python. I think just any programming language is good if it's
suitable for large projects and has good memory management.
Like, say, C#.NET

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Filip Dreger wrote:
> Uzytkownik "Petr Prokop" <zwei2stein@gmail.com> napisal w wiadomosci
> news:1116415282.335718.264910@g44g2000cwa.googlegroups.com...
> > What dangerous structures are there waiting for me to discover, use

> > and
> > loathe?
> Probably you are going to loathe your Object Oriented approach
> This is one of the hot topics here, it got discussed a couple of
> times; one of the last OO Java champions, Slash,

Lol, *blushes*

> used to have some
> really cool posts on doing the OO stuff "the right way", but he seems

> a lot quieter now;

I plant to get back to roguelike development mode in the next month...
for now I just can't add another think thread to my head

> and just some time ago he posted a little advice in
> the lines of "beware of overengineering".
> The ideal OO structure for a roguelike seems way to complicated to
> implement in a straightforward way, just by translating "sword" into
a
> "sword class" and having the "magic sword" inherit from it. It seems
> better to have a generic "item" class.
>
SNIP
>
> regards,
> Filip

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Petr Prokop wrote:
> Hi,
>
> I finaly decided to put my first roguelike together, i've put
together
> my world, What rules will be like ( like classes, skills, magic ...).
> So it's kind of ready to be played in pen-and-paper fashion.

Nice! any docs or are they *private*?

(makes me think on that project... Greekie??? )

>
> What i lack is experience in doing roguelikes (but not programing
> overall ...).
>
> So, can anyone point me to design pattens usefull for adom-like
complex
> game?

"adom-like complex game"

I can only think on a pattern based on patience and a lot of time

>
> What dangerous structures are there waiting for me to discover, use
and
> loathe?
>
> Now, i'm putting together some basics, like item data model,
character
> data model...
>
> For example:
>
> Items should all be descendands of object Item ... like Weapon class
> and Armor inherits from Item class that has generics, but i don't
want
> Item class instrictally know how to work with Blessed or Cursed
status,
> and i don't want to implement it in all apliclable subclases ( that
> code will be always the same ... ) and this goes to other stuff to (
> Durability of item ... )

This can be handled in a lot of ways...

For example, you may consider weapons, armor, potions, scrolls etc...
to be just Items, they all have common properties, and the thing that
differentiates them is the use you put them into... this allows for
example to make things such as attacking a monster with a scroll... the
results of the attack will be dependant on the attributes of the scroll
as a item, such as its mechanical strength, weight, material, etc...

Subclassing has no real advantage here, as you will end up with ugly
things such as :

if (item instanceof Weapon)
int damge = ((Weapon)item).getDamage();
else
throw GorillaException("You can't attack with that!");

However, you may include attributes to each item that indicates their
common uses, so that its easier for the UI (or the AI) to select them
for each action (for example, if the AI controlled monster wants to
drink something, he will first choose from these things that are
normally drunk, then he may consider if he wants to drink that ugly
looking sword )

>
> Another problem is how to handle ego items. Since i want to employ
> Diablo II-like item model with socketable items, runeword-like
> abilities, sets ... lots of customizations. All of this having lots
of
> triggers for special actions ( onBeingHit, onTargetDestroyed ... ).
> Currently, having have each item list which contains Object of
> MagicItemMod interface and another List which can contain other items
> imlementing InsertableItem

Or just a attribute set inside each item that defines the properties
for an item to be allowed insertion into it, and a reference to the
insertable which is just another Item with these special
modifications... that way you could insert that bubblegum into your
shield and make your enemy weapons stick over it

I think generalization must be avoided here, because it really doesn't
affect the functionality of the objects, only the attributes...

>
> (I know how to google for i.e. map generation or so ... i just want
> real live answer)

--
Slash

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Uzytkownik "Petr Prokop" <zwei2stein@gmail.com> napisal w wiadomosci
news:1116415282.335718.264910@g44g2000cwa.googlegroups.com...
> What dangerous structures are there waiting for me to discover, use
> and
> loathe?
Probably you are going to loathe your Object Oriented approach
This is one of the hot topics here, it got discussed a couple of
times; one of the last OO Java champions, Slash, used to have some
really cool posts on doing the OO stuff "the right way", but he seems
a lot quieter now; and just some time ago he posted a little advice in
the lines of "beware of overengineering".
The ideal OO structure for a roguelike seems way to complicated to
implement in a straightforward way, just by translating "sword" into a
"sword class" and having the "magic sword" inherit from it. It seems
better to have a generic "item" class.

> Items should all be descendands of object Item ... like Weapon class
> and Armor inherits from Item class that has generics, but i don't
> want
> Item class instrictally know how to work with Blessed or Cursed
> status,
> and i don't want to implement it in all apliclable subclases ( that
> code will be always the same ... ) and this goes to other stuff to (
> Durability of item ... )

This is exactly why you do not want to inherit weapon from item

regards,
Filip

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

SmartK8@gmail.com wrote:
>Well I found this out a long time ago. Now tell me how to make a
>generic class for items,beings and world cells ) coz that seems even
>more sophisticated.

This seems an excessive abstraction to me. But then, I'm a
procedural-with-some-OO-techniques programmer at heart; my reasons for
contemplating learning Java are *entirely* mercenary.
--
Martin Read - my opinions are my own. share them if you wish.
My roguelike games page (including my BSD-licenced roguelike) can be found at:
http://www.chiark.greenend.org.uk/~mpread/roguelikes.html
bounce. bounce. bounce. bounce bounce bounce bounce.

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

tongHoAnh wrote:
> Twisted One wrote:
>
>>You may want to seriously rethink your choice of language.
>
> Not every RL developer is capable of speaking in every (computer)
> language in existance like you IMHO. I'm working mine on Java, and I
> like it that way so I'm sticking to it.

I said "may want to", not "absolutely must" ...

--
http://www.gnu.org/philosophy/right-to-read.html
Palladium? Trusted Computing? DRM? Microsoft? Sauron.
"One ring to rule them all, one ring to find them
One ring to bring them all, and in the darkness bind them."

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Twisted One ha escrito:
> SZDev - Slash wrote:
> > throw GorillaException("You can't attack with that!");
>
> GorillaException?

Yeah... haven't you every thrown one???

>
> > Or just a attribute set inside each item that defines the
properties
> > for an item to be allowed insertion into it, and a reference to the
> > insertable which is just another Item with these special
> > modifications... that way you could insert that bubblegum into your
> > shield and make your enemy weapons stick over it
>
> Hold on. I have to call my stockbroker urgently.
>
> Hello Harry? Yes ... I'd like to buy some stock options. Teflon sword

> futures, to be exact ...

LOL

>
> --
> http://www.gnu.org/philosophy/right-to-read.html
> Palladium? Trusted Computing? DRM? Microsoft? Sauron.
> "One ring to rule them all, one ring to find them
> One ring to bring them all, and in the darkness bind them."

--
Slash

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

SmartK8@gmail.com wrote::

> Filip Dreger wrote:

>>"sword class" and having the "magic sword" inherit from it. It seems
>>better to have a generic "item" class.
>
> Well I found this out a long time ago. Now tell me how to make a
> generic class for items,beings and world cells ) coz that seems even
> more sophisticated.

Items and beings can be unified if you extract the AI into separate
structures. I would not advice to try to merge this with world cells,
though.

I you need example code, you could look at my project:
https://sourceforge.net/projects/h-world/

It uses unified classes for items and monsters.

The CVS stats still say 0 files, but they are all there:
http://cvs.sourceforge.net/viewcvs.py/h-world/

> regard,
> Kate

--
c.u. Hajo

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

tongHoAnh wrote:
> Twisted One wrote:
>
>
>>You may want to seriously rethink your choice of language.
>
>
> Not every RL developer is capable of speaking in every (computer)
> language in existance like you IMHO. I'm working mine on Java, and I
> like it that way so I'm sticking to it.

A lot of people use their RL development as a way of learning new
languages, skills, and techniques. He never said not to use Java, he
just suggested a couple of languages he felt better suited to the
task. An especially valid suggestion, since both of those languages
are worth learning, and making a small RL is a nice way to really give
it a go.


--
SoulEaterRL... Coming soon!

http://www.freewebs.com/timsrl/index.htm

--

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Krice wrote:
> That is true, but you can try to be extra careful with C++ and
> possibly avoid many problems with memory management.
> I wouldn't recommend C for anyone, because (afaik) it lacks
> those few good memory management techniques that C++ has.

C doesn't lack anything that C++ has, aside from syntactic sugar and
exceptions. Exceptions are the only thing a C runtime lacks that a C++
runtime has, and they have nothing to do with memory management. Every
use of a reference in C++ code can be a pointer in C. Any data structure
you implement in either can then be implemented in the other. And so on...

Well, C++ also has templates, but even if you can find a compiler and
linker with proper template support (i.e. doesn't complain about
multiple definitions or some other problem when any nontrivial project
that instantiates templates is compiled, even if the code's all valid
according to the ANSI standard) templates are just as orthogonal to
memory management as exceptions.

There might be coding tricks to deal with stuff more elegantly and in a
way that's easier and less error-prone to code and later to maintain in
C++, but the basic memory management primitives of new and delete are no
more sophisticated than malloc and free, really, aside from the trivial
difference that you get to write new foo[10] without needing sizeof,
instead of writing malloc(10*sizeof(foo)).

--
http://www.gnu.org/philosophy/right-to-read.html
Palladium? Trusted Computing? DRM? Microsoft? Sauron.
"One ring to rule them all, one ring to find them
One ring to bring them all, and in the darkness bind them."

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

SZDev - Slash wrote:
> throw GorillaException("You can't attack with that!");

GorillaException?

> Or just a attribute set inside each item that defines the properties
> for an item to be allowed insertion into it, and a reference to the
> insertable which is just another Item with these special
> modifications... that way you could insert that bubblegum into your
> shield and make your enemy weapons stick over it

Hold on. I have to call my stockbroker urgently.

Hello Harry? Yes ... I'd like to buy some stock options. Teflon sword
futures, to be exact ...

--
http://www.gnu.org/philosophy/right-to-read.html
Palladium? Trusted Computing? DRM? Microsoft? Sauron.
"One ring to rule them all, one ring to find them
One ring to bring them all, and in the darkness bind them."

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Timothy Pruett wrote:
> tongHoAnh wrote:
>> Twisted One wrote:
>>
>>> You may want to seriously rethink your choice of language.
>>
>> Not every RL developer is capable of speaking in every (computer)
>> language in existance like you IMHO. I'm working mine on Java, and I
>> like it that way so I'm sticking to it.
>
> A lot of people use their RL development as a way of learning new
> languages, skills, and techniques. He never said not to use Java, he
> just suggested a couple of languages he felt better suited to the task.
> An especially valid suggestion, since both of those languages are worth
> learning, and making a small RL is a nice way to really give it a go.

Plus, learning Python might actually give you a marketable skill.
(Smalltalk, on the other hand ... ;P)

--
http://www.gnu.org/philosophy/right-to-read.html
Palladium? Trusted Computing? DRM? Microsoft? Sauron.
"One ring to rule them all, one ring to find them
One ring to bring them all, and in the darkness bind them."

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

On 2005-05-18, Twisted One <twisted0n3@gmail.invalid> wrote:
> and C++. Java scaling is iffy -- being forced at gunpoint to use
> separate source files for every class leads to file multiplication. Once
> you have more than 10 source files, you've exceeded most editors' MRU

Nothing stops you from cramming lots of classes in a file. Java just
requires that the only top-level public class defined in a source file
has the same name as the source file itself. You can write many
non-public classes, which might be accessible for example from factory
methods in the public class.

You can also do this:

BigMainClass.java:

public class BigMainClass {
public static class Foo { ... }
public static class Bar { ... }
...
}

and then refer to the subclasses as BigMainClass.Foo etc.

--
Risto Saarelma

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Risto Saarelma wrote:
> Nothing stops you from cramming lots of classes in a file. Java just
> requires that the only top-level public class defined in a source file
> has the same name as the source file itself. You can write many
> non-public classes, which might be accessible for example from factory
> methods in the public class.

For a typical OO project, to keep the number of separate source files
reasonable and to reasonably group related classes this way would
require a lot of hoop-jumping and unnatural uses of inner classes and
factory classes to export otherwise-private stuff. So, for all practical
purposes, my assertion stands. And anyway, the naming requirement is not
justified. If there was some facility for on the fly recompilation of
changed source files I could see it as making it unambiguous where to
find the source file, coupled with requirements on directory structure
based on package name, but when the compiler is always handed the source
file's location and name on a silver platter why should it care?

> BigMainClass.java:
>
> public class BigMainClass {
> public static class Foo { ... }
> public static class Bar { ... }
> ...
> }
>
> and then refer to the subclasses as BigMainClass.Foo etc.

I.e. a class full of inner classes as a pseudopackage, minus the
readability advantage of being able to import the declarations and just
refer to Foo. Which then leads to using BMC instead of BigMainClass as
the name and still having a million senseless and bloating copies of the
string "BMC" all over your sources. It's just plain ugly and gross.

--
http://www.gnu.org/philosophy/right-to-read.html
Palladium? Trusted Computing? DRM? Microsoft? Sauron.
"One ring to rule them all, one ring to find them
One ring to bring them all, and in the darkness bind them."

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Krice wrote:

> Twisted One wrote:
>> Python makes it even easier
>
> If it was that much easier then we would be probably all programming
> with Python.

Not really. There are quite a few reasons why it isn't the case. One of them
beeing that a single language can hardly fit for every situation. A second
beeing a massive inertia for programming languages but also for programming
paradigms.

> I think just any programming language is good if it's
> suitable for large projects and has good memory management.
> Like, say, C#.NET

C# and Java have very good memory management but poor global ressource
management. With C++ and RAII we have very good handling of open files,
mutexes etc... and also good memory handling

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Christophe Cavalaria wrote:
> C# and Java have very good memory management but poor global ressource
> management. With C++ and RAII we have very good handling of open files,
> mutexes etc... and also good memory handling

C++? Good memory management? Are you mad? Unless by "good memory
management" you mean "I can, indeed I must, micromanage memory" rather
than "I can make really complicated data structures and freeing stuff,
but not while it's still in use, is taken care of for me automagically,
unlike C++ where it will be a royal pain to accomplish that due to
having to do it myself and still there's bound to be leaks and
segfault-causing bugs after years and several major revisions".

I have yet to see any large production body of C or C++ code that
doesn't leak like a sieve and occasionally crash under obscure and hard
to reproduce conditions, even with many major revisions and years of
development, field testing, and iterative fixing.

--
http://www.gnu.org/philosophy/right-to-read.html
Palladium? Trusted Computing? DRM? Microsoft? Sauron.
"One ring to rule them all, one ring to find them
One ring to bring them all, and in the darkness bind them."

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

In article <d6fbkp$hsg$1@nemesis.news.tpi.pl>,
Filip Dreger <fdreger@amiga.pl> wrote:
>Uzytkownik "Petr Prokop" <zwei2stein@gmail.com> napisal w wiadomosci
>news:1116415282.335718.264910@g44g2000cwa.googlegroups.com...
>> What dangerous structures are there waiting for me to discover, use
>> and loathe?

Not a structure issue per se., but the one piece of advice I have for
you is this:

Don't plan.

Or, at least, don't plan a lot.

The big gotcha with me (and apparently with some other developers as
far as I can tell) is to design a roguelike as the Greatest Roguelike
Ever, one that requires a zillion lines of code, then only write have
a zillion, resulting in something that won't actually run.

So what I recommend is that you just wing it. Write something _now_,
something that can be played and might perhaps be fun to do so, and
put it on the web. I recommend setting yourself a short time limit.
Seven days seems popular around here, although I think it's a bit
short, personally. A month might be better.

Once you've gotten that far, you can refactor your code and maybe
retroactively design a cool, flexible architecture. At that point,
you'll have a better understanding of the problem.

It's a lot easier to fix a working program than an empty source file.

>Probably you are going to loathe your Object Oriented approach
>This is one of the hot topics here, it got discussed a couple of
>times; one of the last OO Java champions, Slash, used to have some
>really cool posts on doing the OO stuff "the right way", but he seems
>a lot quieter now; and just some time ago he posted a little advice in
>the lines of "beware of overengineering".

On the other hand, I've used the OO approach and haven't regretted
it.

It looks to me like the OO approach doesn't really pay off until
you've got a pretty advanced game, one with unique monsters,
artifacts, funky effects and so on. When you only have one kind of
attack, monsters don't need to be different in any way except for some
stats.

Which means that you'll end up hand-coding a whole lot of monsters
with individual stats in each one. The, you'll need to rebalance your
game and have to hunt through a huge number of source files because
half of them need an extra point of AC.

You might want to consider just storing your game object data in a big
text file and generating your class source code from it with a script
each time you compile. Then, as you start adding wierd monsters (or
artifacts, or whatever), you can remove them from the list and replace
them with hand-coded classes that do the extra special things you care
about.


--Chris


--
Chris Reuter http://www.blit.ca
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety." --Benjamin Franklin, 1759

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Twisted One wrote:

> Christophe Cavalaria wrote:
>> C# and Java have very good memory management but poor global ressource
>> management. With C++ and RAII we have very good handling of open files,
>> mutexes etc... and also good memory handling
>
> C++? Good memory management? Are you mad? Unless by "good memory

Keeping RAII in mind can help a lot in C++ memory management Allocate as
much memory as possible by never calling new : Place all objets in STL
containers or on the stack and you'll have a much easier time managing
memory. If you really need to call new, make sure the resulting pointer is
owned by a non-new using object and don't forget the virtual destructor. I
don't speak about C here because you can't do without calling malloc and
free.

> management" you mean "I can, indeed I must, micromanage memory" rather
> than "I can make really complicated data structures and freeing stuff,
> but not while it's still in use, is taken care of for me automagically,
> unlike C++ where it will be a royal pain to accomplish that due to
> having to do it myself and still there's bound to be leaks and
> segfault-causing bugs after years and several major revisions".
>
> I have yet to see any large production body of C or C++ code that
> doesn't leak like a sieve and occasionally crash under obscure and hard
> to reproduce conditions, even with many major revisions and years of
> development, field testing, and iterative fixing.

I think QT and KDE are big enouth C++ projects in themselves. They don't
leak in any perceptible way and don't crash either.

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Christophe Cavalaria wrote:
> Keeping RAII in mind can help a lot in C++ memory management

I don't know what this RAII thing of yours is, so I basically just
ignored it and assumed ANSI standard C++ is being used.

> I think QT and KDE are big enouth C++ projects in themselves. They don't
> leak in any perceptible way and don't crash either.

Surely you jest. Even if this is true they are the exceptions that prove
the rule. Most software is in C or C++. Most software seems to have
serious showstopper bugs, including crashes that don't occur
consistently in specific circumstances but seem random. Most software
also seems to leak. If I use my computer for a few days without
rebooting, any long-running tasks in Task Manager seem to slowly bloat,
along with the total commit charge. If not all of them, then most. Of
course, open source software of good repute and widespread usage tends
to have better stability due to the salutary effects of peer review and
sheer weight of eyeballs, but large projects tend to be nearly
unmanageable and even with this sort of massive distributed effort cease
to be kept completely free of memory management problems. The only thing
your statement says about KT and QDE are that the problems they do have
are relatively subtle, and that there are probably lots of double and
triple checks to avoid double-deletes or misusing a null pointer
somewhere. Crashes then turn into subtler problems such as something
mysteriously not working now and again, or bogus "out of memory" errors
when there's gobs of physical ram free and a 2GB swap partition, when
all the added validation code catches something and handles it more
gracefully. And, of course, a bit of slowness and bloat from said
validation code.

(Mind you, even Java doesn't seem to be immune to weird memory
management bugs. I've seen Java apps leak, presumably by accumulating a
dead weight of referenced but actually unused objects; I've also seen
Java apps generate spurious out of memory errors when there was gobs of
memory free. This, to me, suggests a bug in the VM (maybe with memory
allocation from the OS or detecting low memory conditions in the
underlying system), or (more likely) a lazy app programmer who decided
to throw an OutOfMemoryError for every "can't happen" or unlikely sanity
check assert instead of creating their own unchecked exception class for
such occasions.

--
http://www.gnu.org/philosophy/right-to-read.html
Palladium? Trusted Computing? DRM? Microsoft? Sauron.
"One ring to rule them all, one ring to find them
One ring to bring them all, and in the darkness bind them."

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Twisted One wrote:
> Christophe Cavalaria wrote:
>
>> Keeping RAII in mind can help a lot in C++ memory management
>
>
> I don't know what this RAII thing of yours is, so I basically just
> ignored it and assumed ANSI standard C++ is being used.
>
>> I think QT and KDE are big enouth C++ projects in themselves. They don't
>> leak in any perceptible way and don't crash either.
>
>
> Surely you jest. Even if this is true they are the exceptions that prove
> the rule. Most software is in C or C++. Most software seems to have
> serious showstopper bugs, including crashes that don't occur
> consistently in specific circumstances but seem random. Most software
> also seems to leak. If I use my computer for a few days without
> rebooting, any long-running tasks in Task Manager seem to slowly bloat,
> along with the total commit charge. If not all of them, then most. Of
> course, open source software of good repute and widespread usage tends
> to have better stability due to the salutary effects of peer review and
> sheer weight of eyeballs, but large projects tend to be nearly
> unmanageable and even with this sort of massive distributed effort cease
> to be kept completely free of memory management problems. The only thing
> your statement says about KT and QDE are that the problems they do have
> are relatively subtle, and that there are probably lots of double and
> triple checks to avoid double-deletes or misusing a null pointer
> somewhere. Crashes then turn into subtler problems such as something
> mysteriously not working now and again, or bogus "out of memory" errors
> when there's gobs of physical ram free and a 2GB swap partition, when
> all the added validation code catches something and handles it more
> gracefully. And, of course, a bit of slowness and bloat from said
> validation code.
>
> (Mind you, even Java doesn't seem to be immune to weird memory
> management bugs. I've seen Java apps leak, presumably by accumulating a
> dead weight of referenced but actually unused objects; I've also seen
> Java apps generate spurious out of memory errors when there was gobs of
> memory free. This, to me, suggests a bug in the VM (maybe with memory
> allocation from the OS or detecting low memory conditions in the
> underlying system), or (more likely) a lazy app programmer who decided
> to throw an OutOfMemoryError for every "can't happen" or unlikely sanity
> check assert instead of creating their own unchecked exception class for
> such occasions.

I'm currently running a laptop that has a mere 128MB of RAM, and it's
running Red Hat 9. Pretty much every single piece of software I'm
running is coded in C/C++. As of right now, my machine has been
running for 37 days straight, without a single reboot. And it's still
running as good as it did when it was first booted. I run my web
browser, newsreader, word processor, several games, IDE, miscellaneous
system tools, terminal, PDF viewer, video software, music players, and
a variety of other apps. Given my low system specs, if C/C++ apps
really leaked that much, my machine should be incapacitated by now.
Yet it's not.

I'm guessing you're experience is probably derived from the fact that
you are using Windows. All MS-bashing aside, Windows apps seem much
more likely to leak, from my experience. Probably due to the buggy
nature of the environment those apps run in. I don't recall ever
being able to run a Windows machine for longer than a few days before
a reboot is necessary, whereas I once ran my Linux box for over 3
months without a reboot. And even then it didn't really need a
reboot, but I had to unplug it for moving day.

Any competent C/C++ coder can avoid memory leaks. It just takes the
patience to make sure your code is carefully written, and to ensure
that all memory management is handled properly.


--
SoulEaterRL... Coming soon!

http://www.freewebs.com/timsrl/index.htm

--

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Timothy Pruett wrote:
> I'm currently running a laptop that has a mere 128MB of RAM, and it's
> running Red Hat 9. Pretty much every single piece of software I'm
> running is coded in C/C++. As of right now, my machine has been running
> for 37 days straight, without a single reboot. And it's still running
> as good as it did when it was first booted.

That's because on unix, killing a task that's leaked and restarting it
actually reclaims the leaked memory, and the kernel and all the little
command line tools are simple and streamlined enough someone can
actually feasibly program them with manual memory management and
eventually clean up all the bugs in same, and since it's open source,
someone actually has. Have you restarted anything big and complex in
those 37 days, such as pretty much anything with a GUI? If you've run
something of the sort for that time without restarting the app and
without it leaking or crashing at all then praise the Lord it's a
miracle! Two more and you're eligible for sainthood. Or the programmer
is. Or the entire devteam. Or something like that.

> I run my web browser,
> newsreader, word processor, several games, IDE, miscellaneous system
> tools, terminal, PDF viewer, video software, music players, and a
> variety of other apps. Given my low system specs, if C/C++ apps really
> leaked that much, my machine should be incapacitated by now. Yet it's not.

The OS kernel doesn't leak in your case and lets you restart anything
and everything else without a reboot. That's why.

> Any competent C/C++ coder can avoid memory leaks. It just takes the
> patience to make sure your code is carefully written, and to ensure that
> all memory management is handled properly.

In a complex enough project, my experience tells me this becomes
impossible-to-downright-nontrivial. Eventually you end up with
objects in a long running system that have no "primary" reference or
ownership that is going to be the last one cleared, every time. At this
point, whether something is "live" or not is no longer a simple matter
of whether its container is, or whether some other thing is, or whether
this is done yet or that, but for some "somethings" at bare minimum will
depend on reference counting. This assumes you avoid circular data
structures, circular structures have a clear-cut parent or a handle of
some kind, or you have some system for deterministic symmetry breaking
to consider for reference counting purposes any cycle as having a head
and a tail and not counting the link between them. (The general rule
with circular structures is: count = refs - # cycles participated in. If
count == 0, reclaimable. Finding a general algorithm for keeping track
of the # cycles for every object is left as an exercise for the reader.
I'll be generous and leave you until the heat death of the universe
rather than impose a stricter deadline; you actually might have long
enough this way.) Of course, once you've got circular structures with no
clear way to break symmetry with "weak" links in each you're into
wanting to use a GC. And at that point, you may as well give up on using
C or C++. You can either use Java or reimplement it, and I know which
I'd pick.

--
http://www.gnu.org/philosophy/right-to-read.html
Palladium? Trusted Computing? DRM? Microsoft? Sauron.
"One ring to rule them all, one ring to find them
One ring to bring them all, and in the darkness bind them."