On Sat, 2009-01-03 at 22:42 -0500, Eric S. Raymond wrote: > Ignacio Morelle <shadowm2...@gmail.com>: > > We are vulnerable anywhere where we don't coordinate our work or > > settle upon a common coding style, and a good *design style*. That's > > almost everywhere unfortunately, but I still can't find a good reason > > to blame C++. > > You are mistaken if you think I am blaming C++ specifically in this > discussion. The defect attractors I am most worried about would be > just as severe in any attempt to do what Wesnoth does in *any* > language with pointers and fixed-extent types.
The fact is though that almost ALL programs -- closed or open source -- that are anything like Wesnoth: that is, complex client-side game projects with sophisticated interfaces are written using languages with pointers and fixed-extent types. I personally tend to be of the view that for a project like Wesnoth, using dynamic typing extensively will be much more problematic. I am not sure of any programs that are large (i.e. teams of 5+ coders, developed over years) and have GUI's that are written in any dynamically typed languages, but I would enjoy hearing of them if anyone has any examples. Pointers can be a problem, but in Wesnoth we try to minimize their negative effects through use of various C++ idioms. In particular, we have succeeded in having very few resource leaks by using RAII, and we use almost no pointer arithmetic. I'd also like to point out that contrary to what was said in a previous email, we don't use a variety of memory allocators. We have always used the default, until recently when I introduced an experimental allocator with the intent of seeing if we could reduce memory usage. This has caused a few bugs, but it should be noted that this is an option that would not be available at all in a higher level language, and one would simply have to be stuck with whatever memory usage one ends up with, with no real recourse at all. > > I can find plenty of things to curse C++ about, but that's > a different rant. > > > And a language which does not offer data-type enforcement to me is > > just scaring, which is why it took me so long to learn Perl: > > unwillingness to surrender to type unsafety. > > See my previous about "type safety" being a poor substitute > for explicit contracts and invariants. > > > > The complex tangle of standard and local custom memory allocators we > > > presently use, and that are the source of so many of our bugs [...] > > > > Good example of non-coordination amongst developers. Um, why is C++, > > as a language, guilty? > > Again, this is not a C++-specific problem. C, applied to a project > like Wesnoth, would probably produce a similarly nasty tangle. > > Nor, in principle, would the solution need to be Python; in theory, > Ruby or Groovy or Guile would do just as well. Python is the tool > in thios class closest to hand. > > > What are other *technical cons* on Python now? I have read a social > > one and an economical/hardware-resources one, but nothing else. > > I'm hard put to think of any, really. Unless you think significant > whitespace is evil. > > > I am > > also interested on what other free software projects using standard > > C++, rather than C or some non-standard dialect of any of the two, you > > work for. Or, if you practice writing C++ stand-alone applications to > > learn it, or you just stick to the first impression in Wesnoth. > > I've done a little work on groff, which is written in C++. _______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
