A roguelike programming contest
Tarindel
am hosting a Roguelike programming contest. The objective: write a
random dungeon generator in the language of your choice.
Sound easy? It's as easy or as hard as you make it. The point is to
have fun, create some interesting new dungeon designs, give you a
reason to try out that algorithm that's been in the back of your head,
or even learn a new language. Because all entries are output to HTML,
no mucking with I/O libraries is needed.
Details can be found <a href="http://www.learncpp.com/forums/index.php?
topic=4.msg10#new">here</a>. The contest runs until midnight on
August 5th, 2007. Submitting your dungeon generation source code is
optional, but it would definitely be cool to have more dungeon
generation source code out in the public domain.
This contest was inspired by Jakub Debski's <a href="http://
sourceforge.net/projects/roguelikelib/">RoguelikeLib v0.4</a>, and
Gamer_2k4's <a href="http://www.geocities.com/reptoran/images/
dgen/">cave generation adventures</a> from back in Feb. Thanks guys.
I can't wait to see what you guys are able to come up with.
Antoine
Can we have those links again please - not as HTML, just (functioning)
URLs.
Cheers
A.
Tarindel
Contest URL: http://www.learncpp.com/forums/index.php?topic=4.msg10
RoguelikeLib v0.4: http://sourceforge.net/projects/roguelikelib/
Gamer_2k4's CaveGen: http://www.geocities.com/reptoran/images/dgen/
Gamer_2k4
> Gamer_2k4's CaveGen: http://www.geocities.com/reptoran/images/dgen/
Well, I guess you know my entry...Eh, maybe I'll make a castle
generator or something just for fun.
--
Gamer_2k4
Tarindel
Did you ever release the source code for your cave generator? I can't
remember.
I think it would be interesting to try to do a castle generator
recursively. I think that way you've get something very ordered
looking, as a castle should be.
Krice
> give you a reason to try out that algorithm that's been in
> the back of your head
I've been thinking about how to do a decent town generator..
Gamer_2k4
> remember.
Yep, but here's the link again:
http://www.geocities.com/reptoran/files/Dgen.zip
--
Gamer_2k4
Timofei Shatrov
confuse everyone with this message:
>Details can be found <a href="http://www.learncpp.com/forums/index.php?
>topic=4.msg10#new">here</a>.
LearnCPP? I guess I'm out...
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
Tarindel
> LearnCPP? I guess I'm out...
Don't worry about the name of the site. The contest is open to
programmers of all languages. Hence the, "write a random dungeon
generator in the language of your choice."
The forums will be moved to site without cpp in the name as soon as I
find and register a good one. :)
Pasi Kallinen
> To commemorate the opening of the programming forums on my website, I
> am hosting a Roguelike programming contest. The objective: write a
> random dungeon generator in the language of your choice.
>
> Sound easy? It's as easy or as hard as you make it. The point is to
> have fun, create some interesting new dungeon designs, give you a
> reason to try out that algorithm that's been in the back of your head,
> or even learn a new language. Because all entries are output to HTML,
> no mucking with I/O libraries is needed.
OK, I'll bite. Here's a simple one to generate an oasis, with
some ruins:
http://bilious.homelinux.org/~paxed/code/gens/oasis/
--
Pasi Kallinen
pa...@alt.org
http://bilious.homelinux.org/ -- NetHack Patch Database
Tarindel
> OK, I'll bite. Here's a simple one to generate an oasis, with
> some ruins:
>
> http://bilious.homelinux.org/~paxed/code/gens/oasis/
I like it! If you'd be so kind as to post your files (as an
attachment) in a response to the contest thread at:
http://www.dev-spot.com/forums/index.php?topic=4.0
...that would be fantastic. Thanks for participating. I hope we'll
see many more entries over the next month.
konijn_
Me as well, but your site is sloooooow. In average it takes 20 seconds
per page.
Cheers,
T.
konijn_
Gah !
I tried to upload my entry, than it mentioned that the upload path
could not be accessed.
Then I tried to re-upload it again, and it said the post was already
made.
Then I checked for my post, and I cant find it.
So here goes :
Hi,
here goes the undead desert terrain generator.
One generated map :
http://www.demuyt.net/contest/prototype.html
Link to source is in the generated map.
Only works in Firefox and other advanced browsers because of
transparent images, sometimes you need to hit refresh even in silly
Firefox to remove some annoying little white lines.
Cheers,
T.
Ps : I do fail rule 5, it generates prototype.html ;) , why is that a
rule ?
Tarindel
> Me as well, but your site is sloooooow. In average it takes 20 seconds
> per page.
Where are you located? For me (I'm in California) it takes about 2
seconds to load the page.
On Jul 6, 2:44 pm, konijn_ <kon...@gmail.com> wrote:
> I tried to upload my entry, than it mentioned that the upload path
> could not be accessed.
> Then I tried to re-upload it again, and it said the post was already
> made.
> Then I checked for my post, and I cant find it.
That is my fault. When I moved the forums to the new domain I missed
changing the attachment path. I just tried it and it is now fixed.
Give it another whirl.
> Ps : I do fail rule 5, it generates prototype.html ;) , why is that a
> rule ?
Disqualified! ;)
No, I'm only kidding. I removed that part of the rule. Your right,
it made no sense.
konijn_
> On Jul 6, 2:23 pm, konijn_ <kon...@gmail.com> wrote:
>
> > Me as well, but your site is sloooooow. In average it takes 20 seconds
> > per page.
>
> Where are you located? For me (I'm in California) it takes about 2
> seconds to load the page.
Manhattan.
> On Jul 6, 2:44 pm, konijn_ <kon...@gmail.com> wrote:
>
> > I tried to upload my entry, than it mentioned that the upload path
> > could not be accessed.
> > Then I tried to re-upload it again, and it said the post was already
> > made.
> > Then I checked for my post, and I cant find it.
>
> That is my fault. When I moved the forums to the new domain I missed
> changing the attachment path. I just tried it and it is now fixed.
> Give it another whirl.
Will try ;)
> > Ps : I do fail rule 5, it generates prototype.html ;) , why is that a
> > rule ?
>
> Disqualified! ;)
>
> No, I'm only kidding. I removed that part of the rule. Your right,
> it made no sense.
Cool ;)
Gerry Quinn
kon...@gmail.com says...
> here goes the undead desert terrain generator.
> One generated map :
> http://www.demuyt.net/contest/prototype.html
> Link to source is in the generated map.
>
> Only works in Firefox and other advanced browsers because of
> transparent images, sometimes you need to hit refresh even in silly
> Firefox to remove some annoying little white lines.
It loads fine in IE7. I got white lines in Firefox, but not in IE.
- Gerry Quinn
Slash
> To commemorate the opening of the programming forums on my website, I
> am hosting a Roguelike programming contest. The objective: write a
> random dungeon generator in the language of your choice.
>
> Sound easy? It's as easy or as hard as you make it. The point is to
> have fun, create some interesting new dungeon designs, give you a
>
> I can't wait to see what you guys are able to come up with.
Count me in, I have an idea being preprocessed in my brain right
now... (yeah, that one Gamer)
--
Slash
Icey
> In article <1183758240.009645.220...@w3g2000hsg.googlegroups.com>,
Same for me. Works fine in Opera.
konijn_
I do consider Opera an advanced browser, and I most pleased that even
IE is catching up ;)
Cheers,
T.
Gerry Quinn
java....@gmail.com says...
I've just had a neat-seeming idea myself - maybe for once I'll do a
little open source...
- Gerry Quinn
--
Lair of the Demon Ape
http://indigo.ie/~gerryq/lair/lair.htm
Gamer_2k4
It looked just fine to me in Firefox.
--
Gamer_2k4
Corremn
>
> - Show quoted text -
It took them a while but IE is getting usable.
Those undead must get cold when night falls :)
BWIGLEY
news:1183598344.0...@e9g2000prf.googlegroups.com...
> To commemorate the opening of the programming forums on my website,
I
> am hosting a Roguelike programming contest. The objective: write a
> random dungeon generator in the language of your choice.
>
> Sound easy? It's as easy or as hard as you make it. The point is
to
> have fun, create some interesting new dungeon designs, give you a
> reason to try out that algorithm that's been in the back of your
head,
> or even learn a new language. Because all entries are output to
HTML,
> no mucking with I/O libraries is needed.
>
Well, I've been learning assembly for the past week or two, so I think
I'll have a go at doing one in that. It'll just be a basic generator
but I don't think I could handle much more (Well It'll probably
actually be in HLA so I don't have to learn how to do file output or
figure out random numbers but I won't use it's IF statements or
anything like thet).
Timofei Shatrov
confuse everyone with this message:
>On Jul 5, 12:42 am, g...@mail.ru (Timofei Shatrov) wrote:
OK, so I need another excuse: if I cannot use 3rd party libraries, I can't use
CL-WHO [1] to generate HTML files! And that's just evil!
Tarindel
> On Thu, 05 Jul 2007 14:13:08 -0000, Tarindel <aapomer...@gmail.com> tried to
> confuse everyone with this message:
> CL-WHO [1] to generate HTML files! And that's just evil!
>
> [1]http://weitz.de/cl-who/
The general idea behind the rule is to keep the number of dependencies
down and to encourage code reuse by keeping things as library-
independent as possible. However, in the case where the 3rd party
library is being utilized to help produce HTML, I don't think that's
going to violate the spirit of the rule too egregiously. Just note
that you are using it, so others who would like to use or modify your
code know what is going on.
nornagon
> Well, I've been learning assembly for the past week or two, so I think
> I'll have a go at doing one in that. It'll just be a basic generator
> but I don't think I could handle much more (Well It'll probably
> actually be in HLA so I don't have to learn how to do file output or
> figure out random numbers but I won't use it's IF statements or
> anything like thet).
>
For random numbers, you can implement a Mersenne twister fairly easily
in asm. File I/O should also be naught but some fancy system interrupt
work, non?
Krice
> library is being utilized to help produce HTML, I don't think that's
> going to violate the spirit of the rule too egregiously.
Even I can write a HTML converting routine, so it
should be easy enough... Besides my routine produces
very nice looking formatted HTML and the color of the
tile changes only when the tile changes to different one.
BWIGLEY
Yeah, I figure it wouldn't be too hard to do. It's just that I don't
know how to do it ATM. I'm sure that I'll be able to do it an a
couple of weeks/months and I know I'll have to learn it sometime(and I
might do it if I have time), but for now the HLA libraries will do...
gerryq
> To commemorate the opening of the programming forums on my website, I
> random dungeon generator in the language of your choice.
> Details can be found <a href="http://www.learncpp.com/forums/index.php?
> topic=4.msg10#new">here</a>. The contest runs until midnight on
> August 5th, 2007. Submitting your dungeon generation source code is
> optional, but it would definitely be cool to have more dungeon
> generation source code out in the public domain.
Okay, I started one, left it for a while, and finished it in a rush
today. It
generates dungeons of rooms and corridors a little bit like classic
Rogue,
but in a probably somewhat unusual fashion.
Three random dungeons:
<http::indigo.ie/~gerryq/maze/Dungeon1.html>
<http::indigo.ie/~gerryq/maze/Dungeon2.html>
<http::indigo.ie/~gerryq/maze/Dungeon3.html>
Windows executable will make endless versions of Dungeon.html:
<http::indigo.ie/~gerryq/maze/DungeonGenerator.exe>
And the source code, written in MSVC6 but I think independent of
anything in it. It comes with instructions for sticking it into
Alex's
MSVC6 project, but it ought to work in any environment. Feel free
to use it in your own roguelikes!
<http::indigo.ie/~gerryq/maze/Maze-source.zip>
- Gerry Quinn
Gerry Quinn
ger...@indigo.ie says...
> On Jul 5, 2:19 am, Tarindel <aapomer...@gmail.com> wrote:
> > To commemorate the opening of the programming forums on my website, I
> > am hosting a Roguelike programming contest. The objective: write a
> > random dungeon generator in the language of your choice.
>
> > Details can be found <a href="http://www.learncpp.com/forums/index.php?
> > topic=4.msg10#new">here</a>. The contest runs until midnight on
> > August 5th, 2007. Submitting your dungeon generation source code is
> > optional, but it would definitely be cool to have more dungeon
> > generation source code out in the public domain.
Sorry, fixed version:
Okay, I started one, left it for a while, and finished it in a rush
today. It generates dungeons of rooms and corridors a little bit like
classic Rogue, but in a probably somewhat unusual fashion.
Three random dungeons:
<http:://indigo.ie/~gerryq/maze/Dungeon1.html>
<http:://indigo.ie/~gerryq/maze/Dungeon2.html>
<http:://indigo.ie/~gerryq/maze/Dungeon3.html>
Windows executable will make endless versions of Dungeon.html:
<http:://indigo.ie/~gerryq/maze/DungeonGenerator.exe>
And the source code, written in MSVC6 but I think independent of
anything in it. It comes with instructions for sticking it into Alex's
MSVC6 project, but it ought to work in any environment. Feel fre to
use it in your own roguelikes!
<http:://indigo.ie/~gerryq/maze/Maze-source.zip>
Gerry Quinn
ger...@indigo.ie says...
> In article <1186335872.2...@o61g2000hsh.googlegroups.com>,
> ger...@indigo.ie says...
> > On Jul 5, 2:19 am, Tarindel <aapomer...@gmail.com> wrote:
> > > To commemorate the opening of the programming forums on my website, I
> > > am hosting a Roguelike programming contest. The objective: write a
> > > random dungeon generator in the language of your choice.
> >
> > > Details can be found <a href="http://www.learncpp.com/forums/index.php?
> > > topic=4.msg10#new">here</a>. The contest runs until midnight on
> > > August 5th, 2007. Submitting your dungeon generation source code is
> > > optional, but it would definitely be cool to have more dungeon
> > > generation source code out in the public domain.
>
Posting on Google had confused mem but the thread had timed out on my
news server.
Krice
> Feel fre to use it in your own roguelikes!
The source was like procedural C wrapped inside class
member functions. Horror! So many bad things.. for
example, don't include <vector> inside header file,
it's bad.
And don't write using namespace std; when you are
going to use only vector. Write using std::vector;
Keith H Duggar
> Gerry Quinn wrote:
> > Feel fre to use it in your own roguelikes!
>
> The source was like procedural C wrapped inside class
> member functions. Horror! So many bad things.. for
> example, don't include <vector> inside header file,
> it's bad.
If <vector> were not included, the code would be undefined.The code
declares functions taking std::vector dependent args.
This requires std::vector be declared. std::vector cannot be
forward declared because from the C++ standard we have:
17.4.3.1 Reserved names
1 It is undefined for a C++ program to add declarations or
definitions to namespace std or namespaces within namespace
std unless otherwise specified. A program may add template
specializations for any standard library template to
namespace std.
Do you suggest it is "bad" for user defined types, functions,
etc visible in headers to depend on std types, etc? Or do you
have a legal and defined solution to offer?
> And don't write using namespace std; when you are
> going to use only vector. Write using std::vector;
That is good advice. It also has the added benefit that for
std libraries declaring multiple names (say <algorithm>) it
documents which component(s) you are using.
KHD
Krice
> Do you suggest it is "bad" for user defined types, functions,
> etc visible in headers to depend on std types, etc? Or do you
> have a legal and defined solution to offer?
In some cases including another header inside header is ok,
but it's a sign that the design is poor. What you should
always do is include headers only inside cpp files.
myfile.cpp:
#include <vector>
using std::vector;
#include "my_header_that_uses_vector.h"
awhite
> In some cases including another header inside header is ok,
> but it's a sign that the design is poor. What you should
> always do is include headers only inside cpp files.
Why? What is so illegal, immoral, and/or fattening about putting system
header file includes inside your own header files? By doing that, you're
just guaranteeing that someone else can use your header more easily.
Perl is two doors down the hall, thataway -->.
> myfile.cpp:
>
> #include <vector>
> using std::vector;
> #include "my_header_that_uses_vector.h"
So, you're advocating that before including any user-written header, you
should have to scan it to find out what other headers to include? That way
lies madness. What if one of your headers includes another header - should
you have to scan that, too?
Scott Meyers explored it in more detail, but one of the subjects in
one of his books was that headers should be self-complete (though
IDHTBIFOM)
Adam
Martin Read
>On 6 elo, 07:20, Keith H Duggar <dug...@alum.mit.edu> wrote:
>> Do you suggest it is "bad" for user defined types, functions,
>> etc visible in headers to depend on std types, etc? Or do you
>> have a legal and defined solution to offer?
>
>In some cases including another header inside header is ok,
>but it's a sign that the design is poor. What you should
>always do is include headers only inside cpp files.
I'm very firmly of the opinion that header files whose contents depend
on other header files should include those header files. That way,
if I want to use the things in that header file, I can just #include its
header file and hey presto, I can use those things.
Contrast saying
#include <vector>
using std::vector;
#include "monster.h"
with saying
#include <vector>
using std::vector;
at the top of monster.h.
In the former case, changing what container I use for class monster
forces me to *edit* every file that does things with monsters, as well
as recompiling. In the latter case, a change to the container used for
class monster is (probably) basically transparent; all I have to do is
recompile. This makes monster.h more of a "black box" that I can simply
plug into my program - which is part of the point of object-oriented
design.
--
\_\/_/ you take a mortal man and put him in control
\ / and watch him become a god watch people's heads roll
\/ --- Megadeth, "Symphony of Destruction"
Krice
> Why? What is so illegal, immoral, and/or fattening about putting system
> header file includes inside your own header files?
If you extend that kind of thinking then you could as well
include all header files in one big header and then use that
in your cpp files.
The problem of that approach is that it breaks the modular
design which I think is an important part of modern programming.
Patric Mueller
> On Aug 5, 9:03 pm, Gerry Quinn <ger...@indigo.ie> wrote:
>> Feel fre to use it in your own roguelikes!
>
> The source was like procedural C wrapped inside class
> member functions.
I've always had the impression that this possibility has always been
sold as big plus of C++.
> Horror! [snip]
I've seen much worse. Actually I don't think this is bad. Besides some
functions that don't need to be in that class, it looks okay.
What would you have done different? For example creating classes for a
rooms and walls?
Now that Allman indentation style is much more a reason for
crucification. ;-)
Bye
Patric
Gerry Quinn
pau...@mbnet.fi says...
> On Aug 5, 9:03 pm, Gerry Quinn <ger...@indigo.ie> wrote:
> > Feel fre to use it in your own roguelikes!
>
> The source was like procedural C wrapped inside class
> member functions. Horror!
Well, it's a dungeon generator for roguelikes! What else is it going
to look like?
Seriously, it's a bit untidy as I said, and I will probably go back and
tidy it up. All the array accesses and bit-setting are a bit hideous,
and I see I have even left a chunk of code that was unnecessary
commented out. I just hacked it together, was happy that it worked,
and uploaded it.
It suffers a bit from the portability requirement. I couldn't live
without a Point class, but if I had access to MFC I'd have made use of
CRect and CSize.
It gives nice dungeons, so I am inclined to play with it a bit, which
would include making code that is nicer to look at.
[Incidentally, if anyone is wondering, it will make corridors one
square wide if exp is set to 2 in Create.]
> So many bad things.. for
> example, don't include <vector> inside header file,
> it's bad.
It's necessary, because the function prototypes refer to vector. If
someone doesn't like <vector> being included in headers, they are free
to modify these functions.
MTRand should be pre-declared, certainly. I would probably leave Point
as it is, because it is made purposely for Maze. (In fact I suspect
anyone using this in their own environment will throw Point away and
replace it with MFC's CPoint or the like.)
> And don't write using namespace std; when you are
> going to use only vector. Write using std::vector;
Yes, I should do that.
Gerry Quinn
01.iinet.net.au>, spu...@iinet.net.au says...
> On Sun, 05 Aug 2007 23:47:00 -0700, Krice wrote:
> > In some cases including another header inside header is ok,
> > but it's a sign that the design is poor. What you should
> > always do is include headers only inside cpp files.
>
> Why? What is so illegal, immoral, and/or fattening about putting system
> header file includes inside your own header files? By doing that, you're
> just guaranteeing that someone else can use your header more easily.
>
> Perl is two doors down the hall, thataway -->.
>
> > myfile.cpp:
> >
> > #include <vector>
> > using std::vector;
> > #include "my_header_that_uses_vector.h"
>
> So, you're advocating that before including any user-written header, you
> should have to scan it to find out what other headers to include? That way
> lies madness. What if one of your headers includes another header - should
> you have to scan that, too?
And nothing is gained anyway from Krice's suggestion, because
presumably Maze.h won't be included in any of his headers. So after
headers have been compiled, the result will be exactly the same except
for anything preceding #include< vector > in Maze.h. All it means is
extra purposeless typing.
It IS good practice in most cases to forward declare classes rather
than include headers withing headers, so as to avoid unnecessary
clashes and dependencies. But it's not something to be obsessive
about, IMO.
- Gerry Quinn
Martin Read
>On 6 elo, 10:16, awhite <spud...@iinet.net.au> wrote:
>> Why? What is so illegal, immoral, and/or fattening about putting system
>> header file includes inside your own header files?
>
>If you extend that kind of thinking then you could as well
>include all header files in one big header and then use that
>in your cpp files.
You could. It would be spork-your-eyes-out awful, and nobody's
advocating taking this to that extreme, but yes, you could.
>The problem of that approach is that it breaks the modular
>design which I think is an important part of modern programming.
So does your approach.
In a modular design, a module should be a black box with defined inputs
and outputs, and its header file should be sufficient of itself for
someone writing another module to make use of those inputs and outputs,
without caring one jot for the implementation details of how its inputs
will be processed in order to yield its outputs.
If (for example) a class contains a private or protected member object
of type std::vector, it's nobody else's business (except another class
derived from that class) that that member object exists or that it is
of type std::vector.
Since they don't need to know there's a std::vector in there, why should
they have to manually include <vector>?
Ray Dillinger
> MTRand should be pre-declared, certainly. I would probably leave Point
> as it is, because it is made purposely for Maze. (In fact I suspect
> anyone using this in their own environment will throw Point away and
> replace it with MFC's CPoint or the like.)
You suspect wrong.
Your code is sufficiently modular that they don't have to replace
your point class. Therefore, they won't. Even in applications
that use MFC and have CPoints running around in other use cases.
Nobody actually reads the code they use that comes from other
people, unless they absolutely have to. And when that happens,
they complain a lot.
Bear
Keith H Duggar
> On 6 elo, 07:20, Keith H Duggar <dug...@alum.mit.edu> wrote:
>
> > Do you suggest it is "bad" for user defined types, functions,
> > etc visible in headers to depend on std types, etc? Or do you
> > have a legal and defined solution to offer?
>
> In some cases including another header inside header is ok,
> but it's a sign that the design is poor.
On average each g++ standard header includes 3 other header
files. Some headers include more than 10 other headers. Is
this a sign that the g++ library is poorly designed?
> What you should
> always do is include headers only inside cpp files.
>
> myfile.cpp:
>
> #include <vector>
> using std::vector;
> #include "my_header_that_uses_vector.h"
Seems like a giant headache for effectively no gain and it creates
a maintenance and portability nightmare. I can't think of a single
example of a public code base that follows your proscription. Can
you provide one?
Perhaps a decent prescription would be that designers supply fwd
headers (such as the std <iosfwd>) for those who wish to reduce
compile dependancies at the expense of tedium.
KHD
Krice
> Is this a sign that the g++ library is poorly designed?
No.
> Seems like a giant headache for effectively no gain and it creates
> a maintenance and portability nightmare.
Not true. The idea is that a module includes only the headers
it's really using. When you include everything inside the
cpp module you can see how the dependencies work. Also in
large projects it's making compile times faster if there are
less dependencies and only files that are associated to the
module are compiled when something is changed.
It's a kind of mechanism that makes you think about the
structure of the source code and avoid bad decisions that
lead to messy and poorly structured source code.
Martin Read
>Not true. The idea is that a module includes only the headers
>it's really using. When you include everything inside the
>cpp module you can see how the dependencies work.
<vector> isn't going to change unless I update my build environment.
>Also in
>large projects it's making compile times faster if there are
>less dependencies and only files that are associated to the
>module are compiled when something is changed.
<vector> isn't going to change unless I update my build environment.
>It's a kind of mechanism that makes you think about the
>structure of the source code and avoid bad decisions that
>lead to messy and poorly structured source code.
Why do I need to care that this class (from which I am not deriving
class of my own) has a private or protected member of type std::vector?
It's a simple enough question.
Martin Read
>Nobody actually reads the code they use that comes from other
>people, unless they absolutely have to. And when that happens,
>they complain a lot.
If I include someone else's *source code* in my project, you bet your
ass I read it end to end before including it.
Krice
> <vector> isn't going to change unless I update my build environment.
Yes, but everything you write is probably going to change.
> Why do I need to care that this class (from which I am not deriving
> class of my own) has a private or protected member of type std::vector?
You seem to stick to std::vector while it's not the point here.
In fact the whole standard library is a hack for C++ so you
really can't say it's a perfect way to handle things.
Jakub Debski
>> <vector> isn't going to change unless I update my build environment.
> Yes, but everything you write is probably going to change.
So? If you really want to distinguish interface from implementation
then use the pImpl idiom.
> In fact the whole standard library is a hack for C++ so you
> really can't say it's a perfect way to handle things.
Get real. STL isn't a hack for C++. It's the part of the language.
regards,
Jakub
windywinter
I'm really beginner of C++ (and probably I would stay beginner...) but
STL is rather more "standarized base class library" than language it
self.
But from developrs perspective STL is part of language called "C++ and
STL" that is supported by most C++ compilers. :-)
Krice:
Hmm... Could you provide me YOUR implementation of STL? Hmm...
PIMPL'ed implementation of course :>
Regards,
windywinter
Gerry Quinn
says...
Yeah, I was thinking of people who might want to modify the source or
copy the algorithms, not those who might want to slot it straight into
their code.
Incidentally, I have now added some extra parameters, and a standard
way of setting all parameters. I'm also nearly finished a small
Windows program that allows you to play with them to see what kind of
maps are generated. But in any case, hopefully this will be something
worth slotting into C++ roguelikes that need a little extra dungeon
variety. Anyone who wants to use C will have to find a replacement for
std::vector.
It would be easy to modify the room generation stage to make extra
rooms, and of course suitable door positions are trivial to find.
Granite walls around rooms would be easy also. That covers most of
what would be needed in many roguelikes. The maps it generates will
suit Lair very well anyway ;-)
Jakub Debski
> I'm really beginner of C++ (and probably I would stay beginner...) but
> STL is rather more "standarized base class library" than language it
> self.
Which is the part of the language... You cannot have implementation of
C++ without STL in it, because it won't be a C++ as defined.
Look at the ANSI/ISO standard of the language (ISO/IEC 14882:2003).
> But from developrs perspective STL is part of language called "C++ and
> STL" that is supported by most C++ compilers. :-)
From your very personal perspective....
regards,
Jakub
windywinter
You are right! this ISO-blah-blah includes STL. :-)
I thought that someone has made distinction between language and basic
classes, but it seems that this is one thing.
Thanks for clarification!
windywinter.
PS: But still I have this strange impression that string template
class depends on language syntax and there is no dependency language
syntax on string template class ;-)
Jakub Debski
> PS: But still I have this strange impression that string template
> class depends on language syntax and there is no dependency language
> syntax on string template class ;-)
not only syntax defines the language :)
regards,
Jakub
Keith H Duggar
> On 7 elo, 11:11, Martin Read <mpr...@chiark.greenend.org.uk> wrote:
>
> > Why do I need to care that this class (from which I am not deriving
> > class of my own) has a private or protected member of type std::vector?
>
> You seem to stick to std::vector while it's not the point here.
This subthread began with your comment about <vector>
and my response that std headers are special since their
components cannot be forward declared without undefined
behavior. So, in point of fact, std::vector (and std
headers in general) is the point here.
> In fact the whole standard library is a hack for C++ so you
> really can't say it's a perfect way to handle things.
Perhaps more than I should, I sympathize with that point of
view. I might even extend it to other features. However, the
key point is that with C++ as it is now defined, your advice
applied to std headers is very poor indeed and contrary to
all C++ practice I've seen, heard of, or been a party to.
KHD
PS. Were you ever going to respond to the friendly offer
(copied below) I made in the "Side Project" thread?
Krice wrote:
> It doesn't modify, but I'm not const correct, because it's
> so confusing. If something is const then it seems like
> everything has to be const and that is not a realistic
> option.
It is essentially impossible to avoid some degree of const
correctness in C++. Hence it's desirable to practice const
correctness where feasbile even if you judiciously decide
to avoid it elsewhere.
In the case of pac_file->Save, assuming reasonable semantics
and behavior, I can see no difficulty in defining it to take
unsigned char const *. Better still, being as how your are
practicing with std::string, provide an overload for Save:
Save ( string const & fname, string const & data ) ;
By the way, what type is pac_file? Is it a type defined in
your or a 3rd party library? If you have the source we
could rewrite it to be more C++ friendly.
Krice
> So, in point of fact, std::vector (and std
> headers in general) is the point here.
The way headers are included is the point here. You have
basically two styles for that. The first and probably more
common is just include lots of stuff inside headers and
elsewhere. The second, and better one, is include inside
cpp modules and only files that are used in that module.
> and contrary to
> all C++ practice I've seen, heard of, or been a party to.
The common practice is not always the best one.
> Hence it's desirable to practice const
> correctness where feasbile
Const correctness is something you don't need if you just
don't fucking change the original stuff given to some
function. I know that accidents happen, but usually those
kind of accidents crash the program.
> By the way, what type is pac_file? Is it a type defined in
> your or a 3rd party library? If you have the source we
> could rewrite it to be more C++ friendly.
It's a class I made and in fact I have been thinking to
release the source code for that dungeon generator even
I didn't complete the generator itself. The source code
is so good that you can use that to create new roguelikes
easily. Unlike other source codes this one is extremely well
written and very easy to extend.
Gerry Quinn
pau...@mbnet.fi says...
> On 8 elo, 03:56, Keith H Duggar <dug...@alum.mit.edu> wrote:
> > Hence it's desirable to practice const
> > correctness where feasbile
>
> Const correctness is something you don't need if you just
> don't fucking change the original stuff given to some
> function. I know that accidents happen, but usually those
> kind of accidents crash the program.
The thing is that when you have a bug in function A, and it calls
functions B, C and D that are const, you don't have to go looking for
possible side effects of those functions.
It makes me happy when nearly all functions of a class are const, and
the rest are short. If a big part of a function's job can be made
const, I'll split it into a big const function, and a small non-const
function that calls the const one.
[I didn't really achieve this in the source I posted, there are too
many non-const functions. I was slightly tempted to make the workspace
m_Wave mutable, it is ugly having connection tests break const. In my
'real' roguelike, all pathfinding is done in an instance of a
specialised class.]
Also, in roguelikes you are going to have a lot of complicated code
that is not fully tested in all situations, and therefore you are going
to use defensive coding practices so that bugs will not crash the game.
(It is true that defences where possible should be marked by asserts.
The point is that you can't rely on crashes to find errors.)
If you are sure something is const, but for some technical reason it is
not so declared (maybe something like that applies to your save file),
you can const_cast it. I've done that occasionally in classes derived
from MFC classes, because MS don't do const correctness...
> > By the way, what type is pac_file? Is it a type defined in
> > your or a 3rd party library? If you have the source we
> > could rewrite it to be more C++ friendly.
>
> It's a class I made and in fact I have been thinking to
> release the source code for that dungeon generator even
> I didn't complete the generator itself. The source code
> is so good that you can use that to create new roguelikes
> easily. Unlike other source codes this one is extremely well
> written and very easy to extend.
Well, it would be nice to see. Why not upload it this week, so it will
contrast with my 'horror'?
Jakub Debski
> Const correctness is something you don't need if you just
> don't fucking change the original stuff given to some
> function. I know that accidents happen, but usually those
> kind of accidents crash the program.
And sometimes can crash the program in very different place,
which can happen not during testing but on the client side.
You completly don't understand what the type safety is for...
Books by Meyers and Sutter are your friends if you want to write in
C++.
regards,
Jakub
Tarindel
dungeon generation contest. The contest's ending deadline is August
12th at midnight.
Details here: http://www.dev-spot.com/forums/index.php?topic=4
So far we've had 7 submissions, which isn't too shabby. Thanks to
everyone who has already participated!
Keith H Duggar
> On 7 elo, 05:15, Keith H Duggar <dug...@alum.mit.edu> wrote:
>
> > Is this a sign that the g++ library is poorly designed?
>
> No.
Ok, then your earlier proclamation:
> In some cases including another header inside header is ok,
> but it's a sign that the design is poor.
was empty rhetoric safely ignored.
> > Seems like a giant headache for effectively no gain and it creates
> > a maintenance and portability nightmare.
>
> Not true. The idea is that a module includes only the headers
> it's really using.
Unfortunately a module must directly or indirectly include
declarations and sometimes definitions for all names whether
or not that module uses them directly or indirectly. Forcing
a client to directly include headers needed only indirectly
degrades rather than improves of modularity.
> When you include everything inside the
> cpp module you can see how the dependencies work.
Why should a client care and more importantly why should a
client be /forced to manage/ the implementation dependencies
of a module it's using? For example:
class Foo {
Bar _bar ;
public :
void doSomething ( ) ;
} ;
Your proscription would force a module using Foo to write:
#include "bar.h"
#include "foo.h"
even if that module does not directly use Bar itself. Why
should the module need to care that Foo's implemenation is
using Bar? Why should the client be forced to manage this?
When the implementor of Foo changes Bar to Baz then what?
Hint, the client must be /rewritten/ (not just recompiled)
which is a degredation of modularity not an improvement.
How do you think this improves modularity?
> Also in large projects it's making compile times faster
> if there are less dependencies and only files that are
> associated to the module are compiled when something is
> changed.
Forward declarations /where possible/ help reduce compile
times. Your method offers no such improvement since every
translation unit will still include the necessary headers
or it simply will not compile. You have merely moved the
responsibilty to client module where it does not belong.
> It's a kind of mechanism that makes you think about the
> structure of the source code and avoid bad decisions that
> lead to messy and poorly structured source code.
No. It's a mechanism that struggles against the current
structure of C++ and merely adds work and hassle for no
gain. The language supports a method entirely different
from what you decribe that achieves, when possible, the
effects you seek: forward declarations.
KHD
Keith H Duggar
> Krice wrote:
> > Keith H Duggar wrote:
> > > Hence it's desirable to practice const
> > > correctness where feasbile
>
> > Const correctness is something you don't need if you just
> > don't fucking change the original stuff given to some
> > function. I know that accidents happen, but usually those
> > kind of accidents crash the program.
>
> The thing is that when you have a bug in function A, and it calls
> functions B, C and D that are const, you don't have to go looking for
> possible side effects of those functions.
>
> It makes me happy when nearly all functions of a class are const, and
> the rest are short. If a big part of a function's job can be made
> const, I'll split it into a big const function, and a small non-const
> function that calls the const one.
Yes, as a form of compiler checked documentation const does
seem useful. Now suppose you didn't believe this and instead
believed that const serves no useful purpose as Krice seems
to. Even if you believed this, the simple fact is that const
is effectively impossible to avoid. Consider:
-- rvalues can only bind to const & (which happens often
when passing temporaries to functions)
-- the automatically generated default copy contructor and
assignment operator take const & arguments
-- STL is replete with const (ex map keys are const) so if
you use the libraries you need to understand const and
code const correctly.
-- string literal decay to char * is deprecated;
char const * should be used instead.
-- namespace level const objects have internal linkage by
default allowing one to efficiently provide constants
(for example numerical constants like PI) without
violating the one-definition-rule.
-- etc
Thus, trying to avoid C++ const correctness is to struggle
against the language as it is now defined. (Similar to his
proscription regarding #include.) Yes it is at times extra
work for perhaps little gain, yes it can even be a pain in
the ass, and yes there are some good arguments against the
current state of const in C++. That said, if you choose to
code in C++, why make your life more difficult by fighting
it at every turn?
KHD
Krice
> Thus, trying to avoid C++ const correctness is to struggle
> against the language as it is now defined.
I think some programmers forget what is the purpose of
a programming language: to produce programs.
If we keep that simple fact in mind then we also know
that it's perfectly possible to make programs without
being const correct.
Krice
> Why should the client be forced to manage this?
What is this mysterious "client" you keep talking about?
If you include everything in one header then it's not
modular programming. Why you even use more than one file?
Why not put everything in one big file?
Sherm Pendley
You're beginning to sound like Twisted, arguing against your imagination.
No one has suggested putting *everything* in one header. All that's been
said here is that the standard headers, which rarely (if ever) change, are
exceptions to the common guideline of not putting #includes in headers.
sherm--
--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
Star...@gmail.com
Hm. If you have a types.h sort of file defining all your INT32Us and
GAMEBITS or whatever you want to use for typenames, you'd have to
include that in your other header files so you can use those typedefs
as paramaters, right?
STL is a sort of TYPE library (or at least meta-type), right?
Might be confusing how people do things in C and C++ though.
--
Weaver--
Sherm Pendley
> On Aug 9, 7:09 am, Sherm Pendley <spamt...@dot-app.org> wrote:
>> Krice <pau...@mbnet.fi> writes:
>> > On 9 elo, 04:38, Keith H Duggar <dug...@alum.mit.edu> wrote:
>> >> Why should the client be forced to manage this?
>>
>> > What is this mysterious "client" you keep talking about?
>> > If you include everything in one header then it's not
>> > modular programming. Why you even use more than one file?
>> > Why not put everything in one big file?
>>
>> You're beginning to sound like Twisted, arguing against your imagination.
>>
>> No one has suggested putting *everything* in one header. All that's been
>> said here is that the standard headers, which rarely (if ever) change, are
>> exceptions to the common guideline of not putting #includes in headers.
>
> Hm. If you have a types.h sort of file defining all your INT32Us and
> GAMEBITS or whatever you want to use for typenames, you'd have to
> include that in your other header files so you can use those typedefs
> as paramaters, right?
I would - but then, that's why I referred to it as a "common guideline", not
as an "absolute rule." I'm pragmatic, not dogmatic. :-)
What I would not generally do is use #include in headers to pull in full
class declarations for classes that are only used as argument or return
types.
The reason for this is to reduce dependencies and therefore build times.
If foo.h declares class foo that takes instances of bar as arguments, and
includes bar.h, then anything that #includes foo.h will *also* depend on
bar.h. That includes code that only uses instances of foo, and neither
knows nor cares about the methods of class bar.
On the other hand, if bar is forward-declared in foo.h, and then bar.h is
included in foo.cc, then foo can still call bar's methods, but users of
foo.h no longer depend on bar.h, and won't need to be rebuilt when bar.h
changes. Foo's use of bar becomes a private matter, something that users
of foo.h no longer need to be concerned with.
If you hear someone complaining of absurdly long build times, then the
odds are pretty good that they've set up a twisty maze of dependencies
for themselves, so that practically every source file needs to be rebuilt
whenever a single header is changed.
STL headers, and headers like your "types.h" example, are rarely changed
anyway, so the effect of including them in other headers isn't so bad.
David Damerell
>I think some programmers forget what is the purpose of
>a programming language: to produce programs.
Yes. When are you going to produce one?
--
OPTIONS=name:Kirsty,menustyle:C,female,lit_corridor,standout,time,showexp,hilit
e_pet,catname:Akane,dogname:Ryoga,fruit:okonomiyaki,pickup_types:"!$?=/,scores:
5 top/2 around,color,boulder:0,autoquiver,autodig,disclose:yiyayvygyc,pickup_bu
rden:burdened,!cmdassist,msg_window:reversed,!sparkle,horsename:Rumiko,showrace
Jakub Debski
> I think some programmers forget what is the purpose of
> a programming language: to produce programs.
> If we keep that simple fact in mind then we also know
> that it's perfectly possible to make programs without
> being const correct.
it's also perfectly possible to write programms without high-level
programming languages. Should we write in assembler then? ;)
regards,
Jakub
Sherm Pendley
Object-Oriented assembler, of course - because OOP is the One True Way
to write software. :-)
Ray Dillinger
> On the other hand, if bar is forward-declared in foo.h, and then bar.h is
> included in foo.cc, then foo can still call bar's methods, but users of
> foo.h no longer depend on bar.h, and won't need to be rebuilt when bar.h
> changes. Foo's use of bar becomes a private matter, something that users
> of foo.h no longer need to be concerned with.
Just for my information, how do you forward-declare a type in C?
Bear
Sherm Pendley
You can declare a public header with an "opaque pointer" typedef:
typedef struct _my_data *data_handle;
Then, you'd place the full definition of the struct's members in a private
header, or even in a .c file if nothing outside that file will need to access
the struct's members. You'd then #include the public header in other header
files, and only include the private header (if there is one) in .c files that
actually need to access the struct's members.
Wikipedia has a brief discussion of this, with examples in Ada, C++, and C:
<http://en.wikipedia.org/wiki/Opaque_pointer>
Keith H Duggar
Here is C++ example of a forward declaration:
class Foo ; // forward class declaration
and a quick search gave a decent article about it:
http://www.goingware.com/tips/parameters/notrequired.html
This allows one to define pointers and references to Foo,
declare functions returning and taking Foo, and to typedef
templates parameterized by Foo.
Let's examine in more detail the example I hoped would bring
Krice to his senses. Consider this class definition:
-- foo.h ---------------------------------------------------
-- assume Bar and Baz are classes
// HHH what should we put here if anything?
class Foo {
Bar _bar ;
Baz & _baz ;
public :
Foo ( ) ;
Bar readBar ( Bar ) ;
Baz readBaz ( Baz ) ;
void print ( ) ;
} ;
------------------------------------------------------------
Now suppose there is a client of Foo (Krice, here "client"
means a module of code that uses Foo) calling Foo::print:
-- client.c ------------------------------------------------
// CCC what should/must go here if anything?
Foo TheFoo ;
void printTheFoo ( ) { TheFoo.print() ; }
------------------------------------------------------------
As it stands client.c will not compile. Why? Because Bar and
Baz have neither been declared nor defined. Since there is a
Bar variable Bar must be defined. Baz must only be declared
since Bar is used only for a reference and function return
and parameter types. Here are three possible solutions:
------------------------------------------------------------
-- The "lazy" but easiest to maintain way, include them all,
-- let the compiler sort it out. Replace HHH in foo.h with:
#include "bar.h"
#include "baz.h"
------------------------------------------------------------
------------------------------------------------------------
-- The forward declaration way, include only what you must
-- for the .h to compile if it were a .c. Replace HHH with:
#include "bar.h"
class Baz ; // forward declaration
------------------------------------------------------------
------------------------------------------------------------
-- The Krice way, include nothing. Force the client to sort
-- it out. Replace CCC in client.c with:
#include "bar.h"
#include "baz.h"
------------------------------------------------------------
As for compile times, out of the four files considered here
(client.c, foo.h, bar.h, and baz.h) the number compiled in
the client.c translation unit is:
include : 4 forward : 3 Krice : 4
There are a number of pros and cons one may consider. But
in my opinion Krice's method offers no advantages that
outweigh it's costs when compared to headers having a
combination of includes and forward declarations.
KHD
Krice
> in my opinion Krice's method offers no advantages that
> outweigh it's costs when compared to headers having a
> combination of includes and forward declarations.
I think even forward declarations are somewhat dangerous
and they too are a sign of less than optimal structure
of the source code. About the "client"'s responsibility
to include headers.. of course he is responsible of it.
It's very logical to include headers inside the module,
not in the header.
Martin Read
>I think even forward declarations are somewhat dangerous
>and they too are a sign of less than optimal structure
>of the source code. About the "client"'s responsibility
>to include headers.. of course he is responsible of it.
Please explain to me how your method promotes the developer of another
module being able to treat *your* module as a black box whose internal
implementation details are irrelevant.
--
\_\/_/ you take a mortal man and put him in control
\ / and watch him become a god watch people's heads roll
\/ --- Megadeth, "Symphony of Destruction"
Krice
> Please explain to me how your method promotes the developer of another
> module being able to treat *your* module as a black box whose internal
> implementation details are irrelevant.
Well, usually the re-usable parts of my source code are classes
without external dependencies so basically you cut and paste
(that's what I do) class cpp and h to your project. The ways to
reuse code beyond that is not my concern. The important
thing to notice is that parts of my source code are re-usable
in the first place. There are tons of procedural C source
which is basically not good for anything than the project
it belongs. There are too many internal dependencies, funny
macros and functions used in them.
Krice
> Why not upload it this week, so it will
> contrast with my 'horror'?
I don't intend to release it for the contest, because it
has small SDL "engine" which I think is useful when you use
it to build roguelikes.
konijn_
> On Jul 5, 2:19 am, Tarindel <aapomer...@gmail.com> wrote:
>
> > To commemorate the opening of the programming forums on my website, I
> > am hosting a Roguelike programming contest. The objective: write a
> > random dungeon generator in the language of your choice.
> > Details can be found <a href="http://www.learncpp.com/forums/index.php?
> > topic=4.msg10#new">here</a>. The contest runs until midnight on
> > August 5th, 2007. Submitting your dungeon generation source code is
> > optional, but it would definitely be cool to have more dungeon
> > generation source code out in the public domain.
>
> Okay, I started one, left it for a while, and finished it in a rush
> today. It
> generates dungeons of rooms and corridors a little bit like classic
> Rogue,
> but in a probably somewhat unusual fashion.
>
> Three random dungeons:
> <http::indigo.ie/~gerryq/maze/Dungeon1.html>
> <http::indigo.ie/~gerryq/maze/Dungeon2.html>
> <http::indigo.ie/~gerryq/maze/Dungeon3.html>
>
> Windows executable will make endless versions of Dungeon.html:
> <http::indigo.ie/~gerryq/maze/DungeonGenerator.exe>
>
> And the source code, written in MSVC6 but I think independent of
> anything in it. It comes with instructions for sticking it into
> Alex's
> MSVC6 project, but it ought to work in any environment. Feel free
> to use it in your own roguelikes!
Thanks! I really appreciate your first steps towards open sourcing
your stuff. Dont let underthebridgeliving denizens discourage you.
Cheers,
T.
>
> <http::indigo.ie/~gerryq/maze/Maze-source.zip>
>
> - Gerry Quinn
Gerry Quinn
kon...@gmail.com says...
> On Aug 5, 1:44 pm, gerryq <ger...@indigo.ie> wrote:
> > On Jul 5, 2:19 am, Tarindel <aapomer...@gmail.com> wrote:
> > And the source code, written in MSVC6 but I think independent of
> > anything in it. It comes with instructions for sticking it into
> > Alex's
> > MSVC6 project, but it ought to work in any environment. Feel free
> > to use it in your own roguelikes!
>
> > <http::indigo.ie/~gerryq/maze/Maze-source.zip>
> Thanks! I really appreciate your first steps towards open sourcing
> your stuff. Dont let underthebridgeliving denizens discourage you.
Don't get your hopes too high - my opinion on open source hasn't
changed! I've never been opposed to it, but I'm not convinced it adds
much to the general quality of code, and may sometimes even detract
from it. Still, in cases like this it may be helpful, either to plug
into a roguelike that needs some dungeons fast, or just as an example
of some dungeon generation algorithms and how to code them (or how not
to code them, depending on your viewpoint).
This little project made one downside of open source, which I hadn't
really recognised, obvious to me, by the way. Standardisation. Alex
produced a lovely dungeon generation wrapper package with nice 2D array
templates etc. included in the mix, but I figured that if anyone will
use my code, it better be completely standalone, so it is - there is
even a translation layer to get from my internal terrain values to his
default ones.
It also meant I had to create a primitive 'Point' class or go looking
for one, checking the licence, finding out how it worked, etc. It was
faster to write it.
And quite likely, even my use of STL will turn people off my code, if
they aren't used to it or don't like it. (I'm not mad about a lot of
it myself, and I truly wish they had a predicate version of
random::shuffle that didn't depend on the abomination that is
std::functional.)
I never saw this much with the Code Project MFC projects, because these
tend to be single useful classes that can rely on having MFC available.
(Certainly however in a cooperative open-source project these issues
would be ameliorated, because a standard base of utility classes could
be agreed on.)