www.digitalmars.com         C & C++   DMDScript  

c++.stl.port - stlport should not use `__'

reply Anuj Goyal <Anuj_member pathlink.com> writes:
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>
Oct 21 2004
next sibling parent reply Scott Michel <scottm aero.org> writes:
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
Oct 22 2004
next sibling parent reply Anuj Goyal <Anuj_member pathlink.com> writes:
 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!
Oct 22 2004
parent reply Scott Michel <scottm aero.org> writes:
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.
Oct 25 2004
next sibling parent reply Jan Knepper <jan smartsoft.us> writes:
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
Oct 25 2004
parent reply Scott Michel <scottm aero.org> writes:
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
Oct 25 2004
next sibling parent reply Anuj Goyal <Anuj_member pathlink.com> writes:
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:



I think that might be a good way to start getting used to it w/o spending extra
money on hardware :)
Oct 26 2004
parent reply Jan Knepper <jan smartsoft.us> writes:
I have heard that SuSe is one of the better onces...

Jan



Anuj Goyal wrote:

 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:
 

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



-- 
ManiaC++
Jan Knepper

But as for me and my household, we shall use Mozilla...
www.mozilla.org
Nov 09 2004
parent Anuj Goyal <Anuj_member pathlink.com> writes:
Suse is what I run at work.  I am thinking about putting freebsd on another box
to try it out - I tried it a few years ago and liked it.  However, the push
towards linux is inevitable, not necessarily because customers are really going
to run on linux, but saying we support linux is a "checkbox" when deals are
being signed.  If the software is supported on linux, the customer can
_sometimes_ negotiate a better deal with the hardware vendors (HP, AIX, SUN).
However, if our software is only supported on AIX, for instance, the customer
loses this leverage.

Linux is great for webservers, email servers, dns servers.  It lacks some of the
nice 99.999% features of big unixes - hot swapping, guaranteed uptime (backed by
$$$), etc.  That being said, the kernel engineers and 3rd party vendors (suse,
redhat, mandrake) are working very hard to put these features into the kernel. 



I have heard that SuSe is one of the better onces...
Jan
Nov 12 2004
prev sibling parent Jan Knepper <jan smartsoft.us> writes:
Scott Michel wrote:

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


Converted???
I never run Linux for more than a couple of hours... Disliked the 
non-standard extension too much...
Isn't Linux officially a clone???
*BSD is an official Unix AFAIK...

Jan




 
 
 -scooter



-- 
ManiaC++
Jan Knepper

But as for me and my household, we shall use Mozilla...
www.mozilla.org
Nov 09 2004
prev sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Scott Michel" <scottm aero.org> wrote in message 
news:cljai5$2khn$1 digitaldaemon.com...

 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.


Dumb question, but from where does one get FreeBSD, and how is it 
installed. I confess I have neither time nor patience for doing lots of 
manual install stuff?

Cheers

Matthew
Feb 06 2005
parent Arjan Knepper <arjan ask.me> writes:
Matthew wrote:

 "Scott Michel" <scottm aero.org> wrote in message 
 news:cljai5$2khn$1 digitaldaemon.com...
 

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.


 
 
 Dumb question, but from where does one get FreeBSD, and how is it 
 installed. I confess I have neither time nor patience for doing lots of 
 manual install stuff?
 
 Cheers
 
 Matthew
 
 


http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install.html

You could download the ISO images from serveral ftp sites around the 
world see:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mirrors-ftp.html

But if you wanna be really cool... just download the 2 or 3 floppy 
images and install the comlpete system via internet!
This is what I used to do when a internet connection is avaiable.

Arjan

Want a quick look into it?

Download the FreeSBIE live cd image from one of these ftp sites:
http://www.freesbie.org/?section=download-en
burn it and reboot your pc with it.
Feb 06 2005
prev sibling parent reply Ulrich Eckhardt <Ulrich_member pathlink.com> writes:
In article <clbdot$ep0$1 digitaldaemon.com>, Scott Michel says...

AT&T tried to write a C++-based Unix kernel back in the early 90s, and 
failed miserably. 


Ten years ago there simply were no properly working C++ compilers. Hell, even
now there are unresolved issues within the language.


 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.


Surprise: http://l4ka.org/projects/pistachio/
There is at least one more microkernel out there that is written in C++ (plus
the obvious inline assembly) but I'm too lazy to google. There is a patch that
enables the Linux kernel to be compiled in C++, including the use of RTTI and
exceptions.

Uli
Dec 20 2004
next sibling parent Scott Michel <scottm aero.org> writes:
Ulrich Eckhardt wrote:

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.


 
 
 Surprise: http://l4ka.org/projects/pistachio/
 There is at least one more microkernel out there that is written in C++ (plus
 the obvious inline assembly) but I'm too lazy to google. There is a patch that
 enables the Linux kernel to be compiled in C++, including the use of RTTI and
 exceptions.


Ok, I'm surprised. Looks like Liedtke's work moves forward (in his 
memory.) I've seen the recent patches to Linux to support C++ in the 
kernel; it was on /. a few weeks back.


-scooter
Dec 21 2004
prev sibling parent Jan Knepper <jan smartsoft.us> writes:
Ulrich Eckhardt wrote:

AT&T tried to write a C++-based Unix kernel back in the early 90s, and 
failed miserably. 


 
 Ten years ago there simply were no properly working C++ compilers. Hell, even
 now there are unresolved issues within the language.


Ten years ago would have been 1994... I was definitely using several
reliable C++ compilers in those days. I think the standard was at 3.1 in
those days and all to sudden all compiler version changed to 3.1
independent of what their earlier version was... ;-)
Zortech C++ was around in those days and beating every one else...
Borland and M$ where fighting each other in commercials.

-- 
ManiaC++
Jan Knepper

But as for me and my household, we shall use Mozilla...
www.mozilla.org
Jan 15 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"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.
Oct 24 2004
parent reply Anuj Goyal <Anuj_member pathlink.com> writes:
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.
Oct 26 2004
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"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.
Oct 26 2004
parent reply Anuj Goyal <Anuj_member pathlink.com> writes:
 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.


are you talking about this article?

http://www.informit.com/articles/printerfriendly.asp?p=25298
Oct 26 2004
parent "Walter" <newshound digitalmars.com> writes:
"Anuj Goyal" <Anuj_member pathlink.com> wrote in message
news:clmd84$9ah$1 digitaldaemon.com...

 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.


 are you talking about this article?

 http://www.informit.com/articles/printerfriendly.asp?p=25298


Actually by his much more recent presentations, etc. He has an article in
last summer's CUJ.
Nov 04 2004
prev sibling parent reply Scott Michel <scottm aero.org> writes:
Anuj Goyal wrote:

 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).


I've used a reference-counted prefix string trie that does roughly the 
same thing as rope for years. Not a new idea and doesn't suffer from mad 
cow disease. I definitely have to add a few more things to the class to 
make it more thread-safe (or implement r/w locks or ll/sc primitives -- 
see "Efficient and Practical Constructions of LL/SC variables" by 
Jayanti, P and Petrovic, S [Dartmouth])


 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?


More generally, you might want to look at John Backus' functional 
programming work from the late 70s and early 80s. Functional programming 
seems to be making its way back into the limelight with the DARPA PCA 
program and multicore processors. The biggest hurdle is I/O: I/O 
requires state, whereas functional languages don't carry state well.

Let's face it: APL's operators are a bitch to work . It's definitely a 
neat language for "shape shifting" arrays and vectors, but I have not 
found a good reason to go back to working in it. You might want to check 
out PLASM, a functional programming language for graphics, for more ideas.
Oct 27 2004
parent reply Anuj Goyal <Anuj_member pathlink.com> writes:
In article <clomde$2l6m$1 digitaldaemon.com>, Scott Michel says...

Anuj Goyal wrote:

 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).


I've used a reference-counted prefix string trie that does roughly the 
same thing as rope for years. Not a new idea and doesn't suffer from mad 
cow disease. I definitely have to add a few more things to the class to 
make it more thread-safe (or implement r/w locks or ll/sc primitives -- 
see "Efficient and Practical Constructions of LL/SC variables" by 
Jayanti, P and Petrovic, S [Dartmouth])


and you have to convince the STLport maintainers to add it to STLport :) that
will truly be the hard part.  One of the developers I work implemented a ref
counted version of "std::string" but he hasn't pushed it on the STLport
maintainers because it's a very very hard process to move the STLport people
forward.  And it would break some sticky c++ semantics (when you copy
std::string, it is _expected_ that a true copy is made, not just a ref count)


 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?


More generally, you might want to look at John Backus' functional 
programming work from the late 70s and early 80s. Functional programming 
seems to be making its way back into the limelight with the DARPA PCA 
program and multicore processors. The biggest hurdle is I/O: I/O 
requires state, whereas functional languages don't carry state well.



Let's face it: APL's operators are a bitch to work . It's definitely a 
neat language for "shape shifting" arrays and vectors, but I have not 
found a good reason to go back to working in it. You might want to check 
out PLASM, a functional programming language for graphics, for more ideas.


APL operators might painful work with, but try J and K.  They use only ascii
characters that are on your keyboard. APL did use a weird char set, but now all
the derivatives use ascii.  All 3 of these languages are quite "dense" meaning
that every character has a lot of significance.

I have a small web page showing some very very basic examples:

http://goanuj.freeshell.org/k/

my fav is freq of values in a list (sorted):



to the uninitiated it looks like line noise, but to APL, J, K programmers, they
can easily figure out what is going on.  Take the same program, write it in c,
and you will end up with at least 100 more characters.
Nov 01 2004
parent Anuj Goyal <Anuj_member pathlink.com> writes:
I biffed on the last post:



only took me 30  seconds to fix :)
Nov 01 2004