www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Dumping C/C++ library mappings??

reply "Matthew" <admin.hat stlsoft.dot.org> writes:
I'd just like to say - my own bias notwithstanding - that I don't agree with
what seems to be a growing clamour for the 
removal of C/C++ libraries from the standard library.

Three reasons:
    1. I think *all* of the problems encountered thus far are attributable to a
poor/absent management of Phobos and/or 
the interaction between modules' authors and the librarian (Walter)
    2. The 'travails' of porting/compiling/building such libraries is far more
readily handled by an expert group of 
Phobos maintainers, than individual users, many of whom may not (and quite
properly should not) be adept in 
C/C++/assembler/whatever.
    3. This strategy is not reflected in other languages. Hands up how many
think that all the Java and .NET runtime are 


If this becomes a de facto rule, then Phobos will become arbitrarily limited
from expanding into well established 
technologies; and the idea that everything _for_ D is better written _in_ D is
naive, and not bourne out by experience. 
The baby will indeed be washed down the plughole. Furthermore, the users of
such libraries will be more inconvenienced 
than they need be.

What's needed is not a kneejerk reaction to teething problems. Let's just fix
the teething problems.

Of course, I'm still waiting for group (+ Walter) guidance on the Phobos vs
Ares issue. Perhaps the approach is to drop 
everything from Phobos that is not direct language-support?
Mar 30 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Matthew wrote:


 I'd just like to say - my own bias notwithstanding - that I don't agree with
what seems to be a growing clamour for the 
 removal of C/C++ libraries from the standard library.


If it was little old me, then I just wanted it possible for Phobos to 
use the standard system library version of zlib (-lz), nothing else...

Having Phobos include mappings for C/C++ libraries is good, and should
probably be expanded to a few others as well ? (licenses permitting...)


But it seems like bundling, for instance, recls and zlib with the
DMD/Phobos library just causes them to grow old and unmaintained ?

But if zlib is upgraded to 1.2.2 and recls is upgraded to 1.6.1,
then the problem "goes away", or at least goes back under the rug...


Still think that etc/c/zlib.d should be moved to std/c/zlib.d,
but I'll just email that to Walter with the 1.2.2 version upgrade

I think he reasoned something like: "since it's a private import,
it can live just about anywhere". I think it too must be under std.



 What's needed is not a kneejerk reaction to teething problems. Let's just fix
the teething problems.


Once Phobos is more clearly defined (preferrably split, like in Ares)
then it won't be much of an issue. It isn't much of one now either...

Here's my own list of C bindings for D: (they're already completed)
- SDL 1.2.8 ("etc.c.sdl" ?)
- SGI OpenGL 1.2.1 ("etc.c.opengl" ?)
- GNU iconv 1.9.1 ("etc.c.iconv" ?)
- Boutell GD 2.33 ("etc.c.gd" ?)
All of which are very useful libs, but do *not* need to be bundled ?


The only reason against bundling these D "import modules" with Phobos,
is that they use a wide variety of licenses - which complicates things.

I think that "etc" should be empty, in the default DMD installation.
(and it is, in the packages I've made: recls/zlib go in libphobos.a)


But (for me, at least) it has *nothing* to do with the language used.
Except that C++ linkage is not supported, but that's another story...

--anders
Mar 30 2005
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 30 Mar 2005 18:05:42 +1000, Matthew wrote:


 I'd just like to say - my own bias notwithstanding - that I don't agree with
what seems to be a growing clamour for the 
 removal of C/C++ libraries from the standard library.


Define "growing clamour".

I've seen a few of posts that mentioned this idea (in passing). And they
more along the lines that of those C functions that actually are legacy
functions, probably ought to go into a package that identified them as
legacy items. Possibly to be replaced one day by D implementations.


 Three reasons:
     1. I think *all* of the problems encountered thus far are attributable to
a poor/absent management of Phobos and/or 
 the interaction between modules' authors and the librarian (Walter)


Really? *All*? Maybe some, like recls, but some other problems are that
expected functionality is missing, or inconsistently implemented, or blah,
blah, blah ... But I can't see that every problem every discovered with
Phobos can be blamed on management issues.


     2. The 'travails' of porting/compiling/building such libraries is far more
readily handled by an expert group of 
 Phobos maintainers, than individual users, many of whom may not (and quite
properly should not) be adept in 
 C/C++/assembler/whatever.


True, but I hope you are not also saying that if one is not with the
(elite?) "expert group of Phobos maintainers" that one can not or should
not submit items for consideration.


     3. This strategy is not reflected in other languages. Hands up how many
think that all the Java and .NET runtime are 



Also true. I understand a lot of the C runtime library is written in
Assembler too. However, there can't be much against translating any C-based
runtime stuff into D if by doing so the code becomes more maintainable
and/or achieves better performance. There will be trade-offs all the time
and this is what will distinguish the various D implementers' offerings.


 If this becomes a de facto rule, then Phobos will become arbitrarily limited
from expanding into well established 
 technologies; and the idea that everything _for_ D is better written _in_ D is
naive, and not bourne out by experience. 


True. And it is also true that everything _for_ D is better written _in_ C
is naive. We leverage off existing technologies while continuously seeking
improvements, even if that means changing technologies.


 The baby will indeed be washed down the plughole. Furthermore, the users of
such libraries will be more inconvenienced 
 than they need be.


Huh? How will that happen? Have these libraries vanished? Become unusable? 

Aren't we mainly talking about function headers?
 

 What's needed is not a kneejerk reaction to teething problems. Let's just fix
the teething problems.


From where I sit, it seems to be your knee that is doing the jerking. Sorry
mate, no offense intended - just making an observation ;-)

-- 
Derek
Melbourne, Australia
30/03/2005 6:18:41 PM
Mar 30 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Derek Parnell wrote:


 Aren't we mainly talking about function headers?


Shhhh, they're "import modules" now. Headers are old-school :-)

I've been exercising my own "h2d" perl script to make mine,
and it's almost becoming useful. And doesn't require "Boost",
which was why I couldn't use the regular H2D tool on Dsource...

(for some reason, C++ libraries always hits a compiler bug
or two and fails to compile. One of the reasons I dislike it,
others being that it's monkey-slow to compile and huge run-time?

I had hoped that Matthew's book would help me too "love" C++,
but so far it is not working... I'd rather use ++C, or D. ;-)

all being the ugly sister of the languages that I myself like)

I'll repost h2d.pl somewhere, later. It's under the zlib license.

--anders
Mar 30 2005
prev sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:euehyiaxs0rl.1l6mjq67jbxze$.dlg 40tude.net...

 On Wed, 30 Mar 2005 18:05:42 +1000, Matthew wrote:


 I'd just like to say - my own bias notwithstanding - that I don't agree with
what seems to be a growing clamour for 
 the
 removal of C/C++ libraries from the standard library.


 Define "growing clamour".


'twas some of my patent hyperbolic decoration. Just slipped out ...


 I've seen a few of posts that mentioned this idea (in passing). And they
 more along the lines that of those C functions that actually are legacy
 functions, probably ought to go into a package that identified them as
 legacy items. Possibly to be replaced one day by D implementations.


 Three reasons:
     1. I think *all* of the problems encountered thus far are attributable to
a poor/absent management of Phobos 
 and/or
 the interaction between modules' authors and the librarian (Walter)


 Really? *All*? Maybe some, like recls, but some other problems are that
 expected functionality is missing, or inconsistently implemented, or blah,
 blah, blah ... But I can't see that every problem every discovered with
 Phobos can be blamed on management issues.


I think all, yes. But I've not been involved / on the receiving end of all
things, so maybe there're some that I've 
missed.

But I absolutely feel that if the building/porting of Phobos involved more
people all these issues would be resolved 
with, in the words of Schnizel von Krumm, "the great of ease".

Maybe it's because porting / per-platform building is my bread and butter and
I'm thus biased, but I don't think any of 
the issues raised are a problem for someone who can actually directly
manipulate the codebase. The problems, at least 
that I've personally encountered and have noticed (/paid attention to) in the
ng, seem to be because people can't effect 
the appropriate changes themselves, or are similarly inhibited.


     2. The 'travails' of porting/compiling/building such libraries is far more
readily handled by an expert group of
 Phobos maintainers, than individual users, many of whom may not (and quite
properly should not) be adept in
 C/C++/assembler/whatever.


 True, but I hope you are not also saying that if one is not with the
 (elite?) "expert group of Phobos maintainers" that one can not or should
 not submit items for consideration.


Emphatically not. The salient word is "maintainers".


     3. This strategy is not reflected in other languages. Hands up how many
think that all the Java and .NET runtime 
 are



 Also true. I understand a lot of the C runtime library is written in
 Assembler too. However, there can't be much against translating any C-based
 runtime stuff into D if by doing so the code becomes more maintainable
 and/or achieves better performance. There will be trade-offs all the time
 and this is what will distinguish the various D implementers' offerings.


Of course.

The point (I failed to make the first time) is that there exist well-tested,
fully-functional, non-trivial (indeed, some 
huge) libraries _now_, and Phobos is short on functionality _now_. Sure, we can
expunge all C/C++/assembler/whatever 
libraries and demand that it's all 100% D. But that's just going to set Phobos
back on functionality, and, let's be 
honest, it's a kick up the arse, not three steps back, that's what's needed at
the moment.

The second important point is that as soon as a library is split into two
different implementation languages, the 
maintenance workload goes up by a factor significantly in excess of 2. Since C
is the lingua-franca of the day, and will 
likely remain so for at least another, 10-30 years, we should not allow an
artificial "100% pure D"-ism to mask this 
important fact.

The third, perhaps less important point, is that D is touted as being a
first-class language for integration with C. 
And, apart from C++, it's the absolute easiest language with which to link to
C. (Although I love Ruby, and Ruby 
extensions are a total breeze and more 'satisfying' than for other languages,
D's definitely _easier_.) So I think it's 
a *good* thing that parts of the D standard library - which is open-source,
remember - is written in C(/C++). What's not 
good is if those bindings are written poorly, or don't readily port to other
platforms. In both those respects the 
current examples need work. But that does not invalidate the good aspects of
their presence, or the general principle.

I think that the first point should mean that Phobos should not seek to remove
its current C/C++ modules - and in fact 
should seek more! - in the short/medium term.

I think that the second point should mean that Phobos should seek to have,
where appropriate, C/C++ modules for the 
foreseeable future. (Don't people think that it'd be a great thing to have,
say, on Linux Phobos containing binding to 
many of the great and well tested Linux libs??)

The third reason is more political and less practical than the others, and
would not, in and of itself, be a good enough 
reason to have C/C++ modules in Phobos. But it does add a little weight,
methinks.


 If this becomes a de facto rule, then Phobos will become arbitrarily limited
from expanding into well established
 technologies; and the idea that everything _for_ D is better written _in_ D is
naive, and not bourne out by 
 experience.


 True. And it is also true that everything _for_ D is better written _in_ C
 is naive. We leverage off existing technologies while continuously seeking
 improvements, even if that means changing technologies.


Absolutely agreed. It's horses for courses. Pragmatic programming should always
be the go. Everything else is dogma and 
wasted breath.


 What's needed is not a kneejerk reaction to teething problems. Let's just fix
the teething problems.


 From where I sit, it seems to be your knee that is doing the jerking. Sorry
 mate, no offense intended - just making an observation ;-)


Non taken.
Mar 30 2005
prev sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
Matthew wrote:

 I'd just like to say - my own bias notwithstanding - that I don't agree with
what seems to be a growing clamour for the 
 removal of C/C++ libraries from the standard library.
 
 Three reasons:
     1. I think *all* of the problems encountered thus far are attributable to
a poor/absent management of Phobos and/or 
 the interaction between modules' authors and the librarian (Walter)
     2. The 'travails' of porting/compiling/building such libraries is far more
readily handled by an expert group of 
 Phobos maintainers, than individual users, many of whom may not (and quite
properly should not) be adept in 
 C/C++/assembler/whatever.
     3. This strategy is not reflected in other languages. Hands up how many
think that all the Java and .NET runtime are 

 
 If this becomes a de facto rule, then Phobos will become arbitrarily limited
from expanding into well established 
 technologies; and the idea that everything _for_ D is better written _in_ D is
naive, and not bourne out by experience. 
 The baby will indeed be washed down the plughole. Furthermore, the users of
such libraries will be more inconvenienced 
 than they need be.
 
 What's needed is not a kneejerk reaction to teething problems. Let's just fix
the teething problems.
 
 Of course, I'm still waiting for group (+ Walter) guidance on the Phobos vs
Ares issue. Perhaps the approach is to drop 
 everything from Phobos that is not direct language-support?
 
 
 


Maybe I'm missing something, but who is advocating everything be written 
  in D?

I'm sure there are plenty of good C libs that are actively maintained, 
and if you can get C++ libs to work with D (which you seem to know how), 
  then all the better.

D needs all the help from other C/C++ lib authors as possible, because 
it is just a pain in the arse to port every new version of a C/C++ lib 
to D.

The more hands we have in the D library, directly or indirectly, the better.
Mar 30 2005
parent "Walter" <newshound digitalmars.com> writes:
"clayasaurus" <clayasaurus gmail.com> wrote in message
news:424AD3C3.5000901 gmail.com...

 Maybe I'm missing something, but who is advocating everything be written
   in D?


If it's making an existing library work with D, and the existing library is
non-trivial, then a mapping layer would be fine. An example of this is the
zlib library.

If it's writing new library code, then it should be written in D.

Some C++ libraries, however, are just unsuitable to use a D mapping layer
with. An example would be one that heavilly relies on templated string types
with some internal memory allocation scheme. D users would want to use the D
string type, which is gc'd. Trying to make a working mapping layer that
isn't a horrible kludge would be more work than just taking the concept of
the library and translating it into D.

One impression I wish to avoid is having too much of the runtime library
written in C, for the reason that it gives the appearance that D is
incomplete and one must still resort to C. This is why it was critical that
the garbage collector be written in D, for example.

All in all, it's a judgement call on a case-by-case basis.
Mar 30 2005