Complete.Org: Mailing Lists: Archives: freeciv-dev: November 2001:
[Freeciv-Dev] Re: curiosity
Home

[Freeciv-Dev] Re: curiosity

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: <ansutton@xxxxxxx>, Paul Zastoupil <paulz@xxxxxxxxxxxx>
Cc: Reinier Post <rp@xxxxxxxxxx>, Freeciv developers <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: curiosity
From: Marc Butler <marcbutler@xxxxxxx>
Date: Fri, 30 Nov 2001 21:35:47 -0700

On Fri, 30 Nov 2001 20:32:13 -0500, Andrew Sutton wrote:
>On Friday 30 November 2001 07:32 pm, Paul Zastoupil wrote:
>> On Fri, Nov 30, 2001 at 05:16:06PM -0500, Andrew Sutton wrote:
>> > On Friday 30 November 2001 03:58 pm, Reinier Post wrote:
>> > > As usual, I won't bring in much code, but I'll comment anyway
>>...
>> > > wouldn't it be better to switch to C++ or even Java for 2.0?
>> >
>> > ahhh... you speak my language :) C++ is probably a better
>>solution for
>> > the server. a default client could be written using Qt. so,
>>let's switch
>> > to c++ for version 2.0 - unless anybody can provide a solid
>>reason why
>> > not (don't forget performance degradation is a myth).
>>
>> Isn't there a problem of portablility with C++?
>
>to what? embedded systems? maybe... as long as we avoid namespaces,
>complex
>templates and basically really intricate c++ (like using the
>typename
>operator) there shouldn't be too many portability issues.

I think this is an understatement.  There are several subtle
portability issues.  These are often complicated by link loader
incompatibilities.  A comprehensive list with descriptions is
available at the mozilla project:
http://www.mozilla.org/hacking/portable-cpp.html

>
>e.g. take SGI's STL. it works on tons of systems with tons of
>compilers.
>another example: ACE (Adaptive Communications Environment). lots of
>compilers, lots of systems - and it's overcomming libc and libstdc++
>incompatibilities and differences. also, Qt.

Certainly these are good examples.  There are limitations: the SGI
STL is an example in point.  The STLport improves on it, but they are
both ham-strung by compilers in different circumstances.  The STL
Discussions on comp.lang.c++.moderated are a good source of
information.

>
>c++ should present no incompatibilities as long as we stay away from
>some of
>the newer features that haven't been implemented for all compilers.

A portable C++ implementation is obtainable, and while I agree with
you that portability is not a strong argument against C++.  I don't
think it is as quite as simple as you make out.

>
>andy
>


--
Marc Butler, marcbutler@xxxxxxx on 11/30/2001




[Prev in Thread] Current Thread [Next in Thread]