FWIW:

STLport uses `__xxx' and `_y'  as names of identifiers all over their code. This is a no no, technically the `_' and `__' extensions are reserved for compilers. Some compilers let you get away with this and some do not.  Supposedly the STLport guys will be fixing this for 5.0, but for now it's still in Beta...  The STLport codebase actually has this problem with a _lot_ of compilers (I don't know if DMC's -A makes it worse or better, but I would think it has something to do with it)  I have first hand knowledge that HPUX aCC 6.0 is a super strict compiler and there are TONS of warnings and errors when I try to compile the existing "stable" tree (4.6.2) of STLport with it.

There is actually quite a long history as to WHY they do this. If they just used a, b, or i for identifiers, the compiler can sometimes get confused when it inlines variables.  Most sane people do not use `_' and `__' in the names of their variables, that is why STLport prefixed their variables with these delimiters - to prevent naming/symbol collisions.  This is just my opinion, no facts to back it up, but I think most _modern_ compilers have gotten a lot smarter and can tell the difference between "template" variables and "local" variables that have the same names.  However, if STLport's goal is to support older compilers that do not do this, then I think they will continue to use the `_' and `__' delimiters.  Maybe some interesting lad or lassie will fork SLTport and support __only__ modern compilers...

Maybe they will extend the workaround with these these:  `____xxx'  and `_____y' :)


<rant on>
On a personal note: After working porting c++ to 5 platforms, I will avoid
developing a product using C or C++ (famous last words I know!)  It is far too
painful to port. You may think you are developing for one platform, but if you
can et 10% more revenue for this quarter by releasing on solaris, you can bet
your business guys will try to get the developers to port the code - much to
their chagrin. For those of you that do __not__ need performance (ie your
customer can't tell the difference between 10 milliseconds wait time and 20
milliseconds wait time)  do yourself a favor and use java, python, or some other
interpreted language.  I understand that kernels, device drivers, and very low
level compute intensive tasks will always be done in C, C++ or even assembly,
but most interpreted languages allow you to call out to these functions in a
reasonable fashion.  Even following ISO standards will not save you from nasty
linking/runtime issues that every platform is particular about.

In particular there was one area of STLport code that really gave me nightmares
- their reference counting implementation - pure ifdef hell (see _threads.h).
AtomicIncrement and AtomicDecrement are two important library calls (that should
be inlined if the compiler is doing his job right)  that is different for each
architecture/compiler/os combination - super yuck.  With interpreted language
you pay a slight performance hit (mostly in terms of the interpretation and
garbage collection)  but you gain + points for ease of development, faster build
times (you aren't compiling, merely creating bytecode), and easier maintenance
(that you can ship off to India or elsewhere =- yeah right no offshore program I
have seen has worked so far).  In addition there are some clever interpreted
languages that are actually faster than C in some cases - hard to believe no?
Well try out APL, K, or J.  The APL language was created by Dr. Iverson and it
ran on an IBM/360 back in the early 1960's.  This was before C was created!  IBM
used it for lots of early development and APL2 is still a supported product
(many banks with mainframes are still using and developing for it) with a
conference every so often.  I'll be honest, I'm a K\APL fanboy but i haven't
even begun to scratch the surface and I can honestly say I get more work done in
30 characters of k, than I would in 500 to 1000 characters of C.  Try it out
http://www.kx.com/download/software.php
<rant off>

Anuj Goyal wrote:
> I understand that kernels, device drivers, and very low
> level compute intensive tasks will always be done in C, C++ or even assembly,

AT&T tried to write a C++-based Unix kernel back in the early 90s, and failed miserably. So, no, I don't expect I'd ever see a kernel written in C++. I'd be surprised if someone managed to do it.

> In particular there was one area of STLport code that really gave me nightmares
> - their reference counting implementation - pure ifdef hell (see _threads.h).

That's what happens in "portable" code -- #ifdef hell. But it is an approach that works. See the GNU binutils code for real #ifdef nightmares.

> Well try out APL, K, or J.  The APL language was created by Dr. Iverson and it
> ran on an IBM/360 back in the early 1960's.

So did LISP, language of choice for a GNU generation. :-)
(If you're a real purist, you use Scheme.)


-scooter

>> In particular there was one area of STLport code that really gave me nightmares - their reference counting implementation - pure ifdef hell (see _threads.h).
>
>That's what happens in "portable" code -- #ifdef hell. But it is an approach that works. See the GNU binutils code for real #ifdef nightmares.

I agree, ifdef hell is OK .. but only if the developer takes the time to structure it properly.  You can easily abstract away parts of the non-portable interface to a header file and keep it clean.  _threads.h  is not clean by any means.  The STLport people need another level of header files to clean up this mess.  However, that is no detraction against the maintainer.  If he can understand it that is all that really matters, but the "secondary" eyes in the open source community will soon glaze over and shake their head.

Would anyone accept SSL code that looked like that? I think not. Unnecessary complexity often times breeds more problems than it solves.

Here is one possible solution:

#if defined(_AIX)
#include "aix_threads.h"

#elif defined(hpux)
#include "hpux_threads.h"

#elif defined(sun)
#include "sun_threads.h"

#elif defined(linux)
#include "linux_threads.h"

#elif defined(__DECC) || defined(__DECCXX)
#include "dec_threads.h"
....

#endif


The above solution still has it's problems (simplifies the header, possibly complicates the build system), but it structures the header in such a way that it is quite easy to add another platform.

When you have less than 5 configurations that you are supporting, I think ifdef code (such as STLport's) can be used.  But when you are trying to support 20 different configurations (like STLport), do something a bit more structured.  I relooked at STLport recently and it seems to be semi-reasonable, but I think as time goes on I hope the list will slowly whittle down to linux (and linux derivatives) and MS - just my opinion - I don't want to start a flamewar here :) At the company I work for, our customers are wondering why we didn't start porting our software to linux sooner!

"Anuj Goyal" <Anuj_member@pathlink.com> wrote in message news:cla77t$260a$1@digitaldaemon.com...
> <rant on>
> On a personal note: After working porting c++ to 5 platforms, I will avoid
> developing a product using C or C++ (famous last words I know!)  It is far
too
> painful to port. You may think you are developing for one platform, but if
you
> can et 10% more revenue for this quarter by releasing on solaris, you can
bet
> your business guys will try to get the developers to port the code - much
to
> their chagrin. For those of you that do __not__ need performance (ie your customer can't tell the difference between 10 milliseconds wait time and
20
> milliseconds wait time)  do yourself a favor and use java, python, or some
other
> interpreted language.  I understand that kernels, device drivers, and very
low
> level compute intensive tasks will always be done in C, C++ or even
assembly,
> but most interpreted languages allow you to call out to these functions in
a
> reasonable fashion.  Even following ISO standards will not save you from
nasty
> linking/runtime issues that every platform is particular about.

One thing I am trying to clean up with the D programming language (www.digitalmars.com/d/) is to fix issues that make C/C++ code not portable. One of those sources of problems is the prevalence of "implementation defined" and "undefined" behavior in the language specs. But if you could post a list of the issues you ran into in real code, I'd appreciate it.

Anuj Goyal wrote:
> Here is one possible solution:
> 
> #if defined(_AIX)
> #include "aix_threads.h"
> ....
> 
> #endif

That's what stl_config.h does, but it's not followed elsewhere. I do agree with your solution: it's a lot more readable. I think "readability" is the crux of your argument.

> When you have less than 5 configurations that you are supporting, I think ifdef
> code (such as STLport's) can be used.  But when you are trying to support 20
> different configurations (like STLport), do something a bit more structured.  I
> relooked at STLport recently and it seems to be semi-reasonable, but I think as
> time goes on I hope the list will slowly whittle down to linux (and linux
> derivatives) and MS - just my opinion - I don't want to start a flamewar here :)
> At the company I work for, our customers are wondering why we didn't start
> porting our software to linux sooner!   

Someday you'll discover why FreeBSD is beloved by the technorati (and it executes Linux binaries, sometimes faster than Linux.) :-)

More seriously, I did contributed to Linux in the early days, as well as other GNU porting efforts (look for scottm@intime.intime.com or scottm@intime.com). But after installing FreeBSD in 1996, I never looked back. It's a platform where you know what you're getting, instead of many thousand RPMs, all of which have interdependencies. Or several species of small furry distributions, grooving in a cave with a Pict.

Someday??? ;-)
I have several FreeBSD systems running... The server that hosts www.digitalmars.com is one of 'em!
www.digitaldaemon.com
This page is kinda cute: http://www.digitaldaemon.com/System_Status.html
Look at the 'uptime'...
Than check http://uptime.netcraft.com/up/today/top.avg.html
And you might have some real fun...

Jan



Scott Michel wrote:
> Someday you'll discover why FreeBSD is beloved by the technorati (and it executes Linux binaries, sometimes faster than Linux.) :-)
> 
> More seriously, I did contributed to Linux in the early days, as well as other GNU porting efforts (look for scottm@intime.intime.com or scottm@intime.com). But after installing FreeBSD in 1996, I never looked back. It's a platform where you know what you're getting, instead of many thousand RPMs, all of which have interdependencies. Or several species of small furry distributions, grooving in a cave with a Pict.


-- 
ManiaC++
Jan Knepper

But as for me and my household, we shall use Mozilla...
www.mozilla.org

Jan Knepper wrote:
> Someday??? ;-)
> I have several FreeBSD systems running... The server that hosts 

I know you're one of the converted. Now for Anuj to discover why it's called 'Linsux'. :-)


-scooter

hey guys :) i'm not against FreeBSD, I just don't have an extra computer (or time) to learn all the system admin tasks of a new OS (though I imagine it can't be that much different than any other *nix) another reason is that our customers are asking for it and not freebsd.

On a semi-related note: we have had a suse box up and running for about 2 months now with heavy heavy usage.  We had to poweroff the machine to add a harddrive, but other than that it has been running reasonably well.  We have also added a bunch of software through yast and haven't run into 'dependency' hell, but I remember going through this on other linux boxes that I have tried to set up. Hopefully SUSE has done a better job.... we'll see in a coule months :)

maybe then our corporate customers will ask for freebsd :)

I have VMware workstation, so I will try to "install" freebsd onto a virtual machine:

http://www.vmware.com/support/ws45/doc/intro_supguest_ws.html#1032196

I think that might be a good way to start getting used to it w/o spending extra money on hardware :)

Hey walter, one that that annoys me about C++ is the wchar_t stuff. I wish POSIX had been more clear as to the size requirements for this type but alas they let each vendor do what they wanted.  On _some_ 32 bit systems it is 2 bytes and on solaris it is 4 bytes.  And then on 64 bit systems it can be different lengths as well (see win32, aix, linux, solaris).  You have already solved this so it's really not worth mentioning - good job.  POSIX/ISO leaves many things up to the implementor and it often times causes too many problems.  Since you are both the designer and implementor you can "see" further.

char 	unsigned 8 bit UTF-8 	0xFF
wchar 	unsigned 16 bit UTF-16 	0xFFFF
dchar 	unsigned 32 bit UTF-32 	0x0000FFFF
http://www.digitalmars.com/d/type.html  etc etc


Most of the "undefined" behavior i see occurs in multithreaded code where different Operating systems have different sematics for threading. Especially in regards to string references being passed around in C++.  Underneath the covers, <rope> in STL uses atomic increment/decrement to achieve reasonable performance in concurrent situations.  I use <rope> very heavily in multithreaded environments because there are no copies of the object being passed around, only "references to it" (cheaper than copies of the rope).  Most of the APIs I work with look like this

foo(const wrope &w0; const wrope &w1) {
.. /* do something */
}


$ cat rope.cpp
#include <rope>
#include <iostream>

bool foo(const wrope &w0, const wrope &w1)
{
cout << "w0=" << w0 << "\tw1=" << w1 << endl;
return false;
}

int main(){

wrope BAM(L"hmm");

foo(BAM, BAM);
cout << "BAM=" << BAM<< endl;

return 0;
}
$ g++ rope.cpp ; ./a.out
w0=104109109    w1=104109109
BAM=104109109

They are all references to the same object which is expected, but underneath the covers, atomic instructions are doing a lot of magic.  I think you have mentioned that your instrinic types are not thread aware.  But even in this example it can be tricky to know what is going on underneath the covers here. It might be a good idea if you could post some examples of how your code instrinic string type performs under threaded operation.  You may have already mentioned this but I haven't check all of the documentation.

I guess this is not "undefined" language behavior, but it is "undefined" runtime behavior and often the language implementation plays a part in understanding what is going on underneath the covers.

I don't know if you planned on addressing threading in D, but many "new" languages are offering threading as a builtin library.  I don't recommend going down that route though :)


--Anuj

PS: just for fun.... I was hoping that your next foray would be into the world of interpreted languages :) have you heard of APL? J? K?  These are vector based languages that offer similar if not better performance than C/C++/D for many operations ... hard to believe eh? check out http://www.kx.com/  (all the wall street firms are using this for their realtime trading systems).  The interesting thing to note is that APL was invtend in 1962 (before C) and was written in microcode.  J and K are both written in C and were developed in the mid 1990's but both of them share quite a bit of the design of APL.

http://www.digitalmars.com/drn-bin/wwwnews?c%2B%2B.chat/359

Ken Iverson (APL, J)
Arthur Whitney (K)

These programming languages are dense...but they pack a powerful punch and are much more economical than C.

PSS: would D be good for code like LAPACK?  I ask this because anytime some piece of software becomes important enough, people want it to be fast and code up the routines in raw assembly and then the language does not seem to matter so much anymore...


>One thing I am trying to clean up with the D programming language (www.digitalmars.com/d/) is to fix issues that make C/C++ code not portable. One of those sources of problems is the prevalence of "implementation defined" and "undefined" behavior in the language specs. But if you could post a list of the issues you ran into in real code, I'd appreciate it.

"Anuj Goyal" <Anuj_member@pathlink.com> wrote in message news:cll176$1i48$1@digitaldaemon.com...
> Hey walter, one that that annoys me about C++ is the wchar_t stuff. I wish
POSIX
> had been more clear as to the size requirements for this type but alas
they let
> each vendor do what they wanted.  On _some_ 32 bit systems it is 2 bytes
and on
> solaris it is 4 bytes.  And then on 64 bit systems it can be different
lengths
> as well (see win32, aix, linux, solaris).

There's some agreement amongst the C++ experts I've talked to that wchar_t is a complete botch.

> Most of the "undefined" behavior i see occurs in multithreaded code where different Operating systems have different sematics for threading.
Especially in
> regards to string references being passed around in C++.  Underneath the
covers,
> <rope> in STL uses atomic increment/decrement to achieve reasonable
performance
> in concurrent situations.  I use <rope> very heavily in multithreaded environments because there are no copies of the object being passed
around, only
> "references to it" (cheaper than copies of the rope).  Most of the APIs I
work
> with look like this
>
> foo(const wrope &w0; const wrope &w1) {
> .. /* do something */
> }
>
>
> $ cat rope.cpp
> #include <rope>
> #include <iostream>
>
> bool foo(const wrope &w0, const wrope &w1)
> {
> cout << "w0=" << w0 << "\tw1=" << w1 << endl;
> return false;
> }
>
> int main(){
>
> wrope BAM(L"hmm");
>
> foo(BAM, BAM);
> cout << "BAM=" << BAM<< endl;
>
> return 0;
> }
> $ g++ rope.cpp ; ./a.out
> w0=104109109    w1=104109109
> BAM=104109109
>
> They are all references to the same object which is expected, but
underneath the
> covers, atomic instructions are doing a lot of magic.  I think you have mentioned that your instrinic types are not thread aware.  But even in
this
> example it can be tricky to know what is going on underneath the covers
here.

I don't understand how different threading implementations would affect this.

> It might be a good idea if you could post some examples of how your code instrinic string type performs under threaded operation.  You may have
already
> mentioned this but I haven't check all of the documentation.

Passing strings around in D is like simply passing around pointers. No reference counting is needed since it is garbage collected.

> I don't know if you planned on addressing threading in D, but many "new" languages are offering threading as a builtin library.  I don't recommend
going
> down that route though :)

I'm swayed by Andrei A's arguments and proposals on this.

>
> --Anuj
>
> PS: just for fun.... I was hoping that your next foray would be into the
world
> of interpreted languages :) have you heard of APL? J? K?  These are vector
based
> languages that offer similar if not better performance than C/C++/D for
many
> operations ... hard to believe eh? check out http://www.kx.com/  (all the
wall
> street firms are using this for their realtime trading systems).  The
> interesting thing to note is that APL was invtend in 1962 (before C) and
was
> written in microcode.  J and K are both written in C and were developed in
the
> mid 1990's but both of them share quite a bit of the design of APL.
>
> http://www.digitalmars.com/drn-bin/wwwnews?c%2B%2B.chat/359
>
> Ken Iverson (APL, J)
> Arthur Whitney (K)
>
> These programming languages are dense...but they pack a powerful punch and
are
> much more economical than C.
>
> PSS: would D be good for code like LAPACK?  I ask this because anytime
some
> piece of software becomes important enough, people want it to be fast and
code
> up the routines in raw assembly and then the language does not seem to
matter so
> much anymore...

I don't see why not.