D - Library naming convention

There have been a lot of good ideas and points made about this in the
discussions here. The upshot is there isn't a single right answer,
but there are a few clearly wrong ones <g>. So it's up to me to just pick
one of the right answers.

So here goes:

std
 Contains the 'standard' modules that will be available on all
 implementations of D. Emphasis in this package will be on reliability,
 stability, and portability. std as a name has the advantage of being used
 in C++ to specify the standard library, and so is familiar and highly
 unlikely to conflict with common variable names.

std.c
 Contains D interfaces to standard C library functions, like
 std.c.stdio, std.c.stdlib, std.c.math.

std.os
 Access to platform specific functionality.

std.os.windows
 Specific to win32 and win64 operating systems. (win64
 is coming, so calling it 'win32' would be a mistake.)
 The excellent point was raised about operating system
 specific code not being in the std tree as it evolves
 constantly. I understand that point, but operating systems
 evolve by adding API's, not subtracting them. So any
 windows package should continue to work as long as there's
 a windows operating system.

std.os.linux
 Specific to linux operating systems.

std.typeinfo
 Where the various TypeInfo implementations go.

internal
 Internal magic implementation-specific runtime support code.

etc
 There are lots of 'other' modules for D, and right now there is no
 organized way to deal with them. There needs to be a place for them.
 The etc heirarchy will mirror the standard one, i.e. there will
 be etc.c, etc.os.windows, ... These will not be official parts of D
 nor will they be standardized. However, candidates for standardization
 will be drawn from etc. etc is the place for
 not-quite-there-yet-but-still-useful modules.

These names have the advantage of being reasonably greppable.

Major packages, such as a D gui, will merit their own toplevel name. Vendor
specific modules will use a toplevel name being the trademarked vendor name.
For example, vendor BrandX would put their vendor specific packages under
the toplevel name brandx.

Much as I'd prefer to use D or d as the toplevel name, it just isn't going
to work because of conflicts, non-greppability, etc.

Oct 28 2003

J C Calvarese <jcc7 cox.net> writes:

Walter wrote:
 There have been a lot of good ideas and points made about this in the
 discussions here. The upshot is there isn't a single right answer,
 but there are a few clearly wrong ones <g>. 



 So it's up to me to just pick
 one of the right answers.
 
 So here goes:
 
 std
  Contains the 'standard' modules that will be available on all
  implementations of D. Emphasis in this package will be on reliability,
  stability, and portability. std as a name has the advantage of being used
  in C++ to specify the standard library, and so is familiar and highly
  unlikely to conflict with common variable names.


So in the future, we'll be talking about std.string, std.regexp, 
std.thread, std.uri, std.utf and others?  (I'm trying to make sure that 
I understand.)

 
 std.c
  Contains D interfaces to standard C library functions, like
  std.c.stdio, std.c.stdlib, std.c.math.
 
 std.os
  Access to platform specific functionality.
 
 std.os.windows
  Specific to win32 and win64 operating systems. (win64
  is coming, so calling it 'win32' would be a mistake.)
  The excellent point was raised about operating system
  specific code not being in the std tree as it evolves
  constantly. I understand that point, but operating systems
  evolve by adding API's, not subtracting them. So any
  windows package should continue to work as long as there's
  a windows operating system.
 
 std.os.linux
  Specific to linux operating systems.
 
 std.typeinfo
  Where the various TypeInfo implementations go.
 
 internal
  Internal magic implementation-specific runtime support code.



 
 etc
  There are lots of 'other' modules for D, and right now there is no
  organized way to deal with them. There needs to be a place for them.
  The etc heirarchy will mirror the standard one, i.e. there will
  be etc.c, etc.os.windows, ... These will not be official parts of D
  nor will they be standardized. However, candidates for standardization
  will be drawn from etc. etc is the place for
  not-quite-there-yet-but-still-useful modules.
 
 These names have the advantage of being reasonably greppable.
 
 Major packages, such as a D gui, will merit their own toplevel name. Vendor
 specific modules will use a toplevel name being the trademarked vendor name.
 For example, vendor BrandX would put their vendor specific packages under
 the toplevel name brandx.
 


Sounds like a good plan.  (I'm glad that I don't have to put my packages 
in "other.com.tripod.jcc_7".)

 Much as I'd prefer to use D or d as the toplevel name, it just isn't going
 to work because of conflicts, non-greppability, etc.



Justin
http://jcc_7.tripod.com/d/

Oct 28 2003

"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:

 std
  Contains the 'standard' modules that will be available on all
  implementations of D. Emphasis in this package will be on reliability,
  stability, and portability. std as a name has the advantage of being




  in C++ to specify the standard library, and so is familiar and highly
  unlikely to conflict with common variable names.


 So in the future, we'll be talking about std.string, std.regexp,
 std.thread, std.uri, std.utf and others?  (I'm trying to make sure that
 I understand.)


I hope not. Shouldn't string, regexp and the like go "under" something else,
and shouldn't "thread" go under std.lang?

Oct 28 2003

"Walter" <walter digitalmars.com> writes:

"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:bnng71$20up$2 digitaldaemon.com...
 I hope not. Shouldn't string, regexp and the like go "under" something


 and shouldn't "thread" go under std.lang?


Why?

Oct 28 2003

"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:

Isn't it a language feature, rather than a library feature?

Maybe thread wasn't the best example. The class info stuff?

"Walter" <walter digitalmars.com> wrote in message
news:bnnjkd$2683$1 digitaldaemon.com...
 "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
 news:bnng71$20up$2 digitaldaemon.com...
 I hope not. Shouldn't string, regexp and the like go "under" something


 and shouldn't "thread" go under std.lang?


 Why?

Oct 28 2003

"Walter" <walter digitalmars.com> writes:

"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:bnnlgq$28ib$1 digitaldaemon.com...
 Isn't it a language feature, rather than a library feature?

 Maybe thread wasn't the best example. The class info stuff?


The line between can get pretty fuzzy at times. The os packages clearly mark
using them as non-portable, but I don't see the equivalent value added for
dividing between language and library.

Oct 29 2003

"Walter" <walter digitalmars.com> writes:

"J C Calvarese" <jcc7 cox.net> wrote in message
news:bnnb81$1qem$1 digitaldaemon.com...
 So in the future, we'll be talking about std.string, std.regexp,
 std.thread, std.uri, std.utf and others?  (I'm trying to make sure that
 I understand.)


Yes. I also tend to prefer flatter, more populated heirarchies, rather than
deep, thinly populated heirarchies like:

    std.this.that.foo.bar.common.implementation.abc.thread.

Oct 28 2003

"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:

Is this the official final word?

Is this the official final structure?

I'm pretty happy with it as is, although I'd like to see a std.lang where
language bits reside.

Oh, and a std.c.recls. :)

"Walter" <walter digitalmars.com> wrote in message
news:bnn9a0$1o09$1 digitaldaemon.com...
 There have been a lot of good ideas and points made about this in the
 discussions here. The upshot is there isn't a single right answer,
 but there are a few clearly wrong ones <g>. So it's up to me to just pick
 one of the right answers.

 So here goes:

 std
  Contains the 'standard' modules that will be available on all
  implementations of D. Emphasis in this package will be on reliability,
  stability, and portability. std as a name has the advantage of being used
  in C++ to specify the standard library, and so is familiar and highly
  unlikely to conflict with common variable names.

 std.c
  Contains D interfaces to standard C library functions, like
  std.c.stdio, std.c.stdlib, std.c.math.

 std.os
  Access to platform specific functionality.

 std.os.windows
  Specific to win32 and win64 operating systems. (win64
  is coming, so calling it 'win32' would be a mistake.)
  The excellent point was raised about operating system
  specific code not being in the std tree as it evolves
  constantly. I understand that point, but operating systems
  evolve by adding API's, not subtracting them. So any
  windows package should continue to work as long as there's
  a windows operating system.

 std.os.linux
  Specific to linux operating systems.

 std.typeinfo
  Where the various TypeInfo implementations go.

 internal
  Internal magic implementation-specific runtime support code.

 etc
  There are lots of 'other' modules for D, and right now there is no
  organized way to deal with them. There needs to be a place for them.
  The etc heirarchy will mirror the standard one, i.e. there will
  be etc.c, etc.os.windows, ... These will not be official parts of D
  nor will they be standardized. However, candidates for standardization
  will be drawn from etc. etc is the place for
  not-quite-there-yet-but-still-useful modules.

 These names have the advantage of being reasonably greppable.

 Major packages, such as a D gui, will merit their own toplevel name.


 specific modules will use a toplevel name being the trademarked vendor


 For example, vendor BrandX would put their vendor specific packages under
 the toplevel name brandx.

 Much as I'd prefer to use D or d as the toplevel name, it just isn't going
 to work because of conflicts, non-greppability, etc.

Oct 28 2003

Ant <Ant_member pathlink.com> writes:

In article <bnng70$20up$1 digitaldaemon.com>, Matthew Wilson says...


Allow me to suggest 

stdd

"std" on google gets 6.470.00
"stdd" gets 4.700

Ant

Oct 28 2003

"Walter" <walter digitalmars.com> writes:

"Ant" <Ant_member pathlink.com> wrote in message
news:bnnglq$21fi$1 digitaldaemon.com...
 In article <bnng70$20up$1 digitaldaemon.com>, Matthew Wilson says...


 Allow me to suggest

 stdd

 "std" on google gets 6.470.00
 "stdd" gets 4.700


D gets 315,000,000 <g>.

Interestingly, std.thread gets 369, std.string gets 102,000, std.regexp gets
8.

Oct 28 2003

"Walter" <walter digitalmars.com> writes:

"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:bnng70$20up$1 digitaldaemon.com...
 Is this the official final word?
 Is this the official final structure?


Unless someone points out a disastrous problem with it <g>.

 I'm pretty happy with it as is, although I'd like to see a std.lang where
 language bits reside.


I'm just going for a workable system, having long since given up on
perfection. Let's just cut & print and move on to more interesting things!

 Oh, and a std.c.recls. :)

Oct 28 2003

"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:

 I'm just going for a workable system, having long since given up on
 perfection. Let's just cut & print and move on to more interesting things!


You mean like std.c.recls? :)

Oct 28 2003

Helmut Leitner <helmut.leitner chello.at> writes:

Walter wrote:
 
 There have been a lot of good ideas and points made about this in the
 discussions here. The upshot is there isn't a single right answer,
 but there are a few clearly wrong ones <g>. So it's up to me to just pick
 one of the right answers.
 
 So here goes:
 
 std
  Contains the 'standard' modules that will be available on all
  implementations of D. Emphasis in this package will be on reliability,
  stability, and portability. std as a name has the advantage of being used
  in C++ to specify the standard library, and so is familiar and highly
  unlikely to conflict with common variable names.


That's a good decision.

By what formal or informal procedure can one contribute modules?

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com

Oct 28 2003

"Walter" <walter digitalmars.com> writes:

"Helmut Leitner" <helmut.leitner chello.at> wrote in message
news:3F9F6104.A4076357 chello.at...
 That's a good decision.


Thank-you.

 By what formal or informal procedure can one contribute modules?


Certainly, it's informal. Which means any way you want to <g>.

Oct 29 2003

Helmut Leitner <helmut.leitner chello.at> writes:

Walter wrote:
 std
 ...


Just to keep track:
   <http://www.prowiki.org/wiki4d/wiki.cgi?StandardLibrary/Layout>

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com

Oct 28 2003

"Walter" <walter digitalmars.com> writes:

"Helmut Leitner" <helmut.leitner chello.at> wrote in message
news:3F9F6290.6FB11680 chello.at...
 Walter wrote:
 std
 ...


 Just to keep track:
    <http://www.prowiki.org/wiki4d/wiki.cgi?StandardLibrary/Layout>


Nice. Thanks for keeping that up to date!

Oct 29 2003

"Luna Kid" <lunakid neuropolis.org> writes:

 Just to keep track:
    <http://www.prowiki.org/wiki4d/wiki.cgi?StandardLibrary/Layout>





May suggest:

Original:
--------------------
std.os
    Access to platform specific functionality.

std.os.windows
    Specific to win32 and win64 operating systems. (win64 is coming, so calling
it
    ...

std.os.linux
    Specific to linux operating systems. (StdOsLinuxComments)
--------------------

Modified:
--------------------
std.os
    Access to OS-level, platform-independent functionality.

std.os.windows
    ...
...
--------------------

Or do I misunderstand something?

(Sorry I just dind't dare Editing directly in the Wiki.
I'm a shy one... :) )

Cheers,
Sz.

Oct 29 2003

"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:

 May suggest:

 Original:
 --------------------
 std.os
     Access to platform specific functionality.

 std.os.windows
     Specific to win32 and win64 operating systems. (win64 is coming, so


     ...

 std.os.linux
     Specific to linux operating systems. (StdOsLinuxComments)
 --------------------

 Modified:
 --------------------
 std.os
     Access to OS-level, platform-independent functionality.

 std.os.windows
     ...
 ...
 --------------------


Good point.

 Or do I misunderstand something?

 (Sorry I just dind't dare Editing directly in the Wiki.
 I'm a shy one... :) )


LOL

Oct 29 2003

J C Calvarese <jcc7 cox.net> writes:

Luna Kid wrote:

Just to keep track:
   <http://www.prowiki.org/wiki4d/wiki.cgi?StandardLibrary/Layout>




 May suggest:
 
 Original:
 --------------------
 std.os
     Access to platform specific functionality.
     ...
 
 
 Modified:
 --------------------
 std.os
     Access to OS-level, platform-independent functionality.
     ...
 
 Or do I misunderstand something?



The way I read it, "std.os" would only contain code that relates to 
platform-dependent (a/k/a platform-specific) functionality.  It would 
probably contain only a series of directories: "windows", "linux", and 
any other platforms with D implementations.

The platform-independent code would reside elsewhere in "std", 
"internal", or "etc".

 
 (Sorry I just dind't dare Editing directly in the Wiki.
 I'm a shy one... :) )


Don't be afaid to edit the Wiki stuff.  That's what Wiki's are designed 
for.  They're easy to edit and they're easy to change back.

Justin

 
 Cheers,
 Sz.

Oct 29 2003

"Luna Kid" <lunakid neuropolis.org> writes:

 --------------------
 std.os
     Access to platform specific functionality.
     ...


 Modified:
 --------------------
 std.os
     Access to OS-level, platform-independent functionality.
     ...

 Or do I misunderstand something?



 The way I read it, "std.os" would only contain code that relates to
 platform-dependent (a/k/a platform-specific) functionality.  It would
 probably contain only a series of directories: "windows", "linux", and
 any other platforms with D implementations.



Well, dunno, but even without knowing how this really
is in D, I'm still almost sure a namespace node is not
restricted to contain either leaf nodes or another
subnamespaces.

Cheers,
Sz.

Oct 30 2003

Roberto Mariottini <Roberto_member pathlink.com> writes:

In article <bnn9a0$1o09$1 digitaldaemon.com>, Walter says...
[...]
etc
 There are lots of 'other' modules for D, and right now there is no
 organized way to deal with them. There needs to be a place for them.
 The etc heirarchy will mirror the standard one, i.e. there will
 be etc.c, etc.os.windows, ... These will not be official parts of D
 nor will they be standardized. However, candidates for standardization
 will be drawn from etc. etc is the place for
 not-quite-there-yet-but-still-useful modules.


What does 'etc' stand for?
I'd prefer 'ext', that means extension.

Ciao

Oct 30 2003

"Lars Ivar Igesund" <larsivi stud.ntnu.no> writes:

I agree. At least I don't like etc.

Lars Ivar Igesund

"Roberto Mariottini" <Roberto_member pathlink.com> wrote in message
news:bnqp2a$i4q$1 digitaldaemon.com...
 In article <bnn9a0$1o09$1 digitaldaemon.com>, Walter says...
 [...]
etc
 There are lots of 'other' modules for D, and right now there is no
 organized way to deal with them. There needs to be a place for them.
 The etc heirarchy will mirror the standard one, i.e. there will
 be etc.c, etc.os.windows, ... These will not be official parts of D
 nor will they be standardized. However, candidates for standardization
 will be drawn from etc. etc is the place for
 not-quite-there-yet-but-still-useful modules.


 What does 'etc' stand for?
 I'd prefer 'ext', that means extension.

 Ciao

Oct 30 2003

Helmut Leitner <helmut.leitner chello.at> writes:

Roberto Mariottini wrote:
 
 In article <bnn9a0$1o09$1 digitaldaemon.com>, Walter says...
 [...]
etc
 There are lots of 'other' modules for D, and right now there is no
 organized way to deal with them. There needs to be a place for them.
 The etc heirarchy will mirror the standard one, i.e. there will
 be etc.c, etc.os.windows, ... These will not be official parts of D
 nor will they be standardized. However, candidates for standardization
 will be drawn from etc. etc is the place for
 not-quite-there-yet-but-still-useful modules.


 What does 'etc' stand for?
 I'd prefer 'ext', that means extension.


I don't think we need to take this so literally.

Walter surely will find better places in std for most modules. 
I think its just an "default" case: "...and if we really don't
know where to put a module, then we have still this place..."

If no-one likes it, just the better. Nothing should ever go there.

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com

Oct 30 2003

user domain.invalid writes:

Helmut Leitner wrote:

 I don't think we need to take this so literally.
 
 Walter surely will find better places in std for most modules. 
 I think its just an "default" case: "...and if we really don't
 know where to put a module, then we have still this place..."
 
 If no-one likes it, just the better. Nothing should ever go there.


The less the better. Remember what happened to Java in this respect? 
javax.sql.* was intruduced containing JDBC 3.0 stuff. Now that it's part 
of JDK 1.4 it's still in javax since moving it would cause no end of 
compatibility problems.

Once in etc, it will stay in etc, so it's better to never put it there 
in the first place.

Just my personal opinion.

Regards

Elias

Oct 30 2003

Andy Friesen <andy ikagames.com> writes:

user domain.invalid wrote:

 Once in etc, it will stay in etc, so it's better to never put it there 
 in the first place.
 
 Just my personal opinion.
 
 Regards
 
 Elias


hm.  That brings up an idea.  The etc.blah module could later be 
rewritten as:

deprecated import proper.place.to.put.blah;

Supposing that imports can be marked as deprecated.  So the etc package 
would probably get pretty bloaty over time, but the compiler would bitch 
at everybody who tries to use it, and it would all just be redirecting, 
so size and so forth would not suffer.

(better to put it in the right place right off the bat, sure, but that's 
not as easy as it sounds sometimes)

  -- andy

Oct 30 2003

Elias Martenson <elias-m algonet.se> writes:

Andy Friesen wrote:

 user domain.invalid wrote:
 
 Once in etc, it will stay in etc, so it's better to never put it there 
 in the first place.

 Just my personal opinion.

 Regards

 Elias


 
 hm.  That brings up an idea.  The etc.blah module could later be 
 rewritten as:
 
 deprecated import proper.place.to.put.blah;
 
 Supposing that imports can be marked as deprecated.  So the etc package 
 would probably get pretty bloaty over time, but the compiler would bitch 
 at everybody who tries to use it, and it would all just be redirecting, 
 so size and so forth would not suffer.
 
 (better to put it in the right place right off the bat, sure, but that's 
 not as easy as it sounds sometimes)


First of all: sorry for not having configured my email address properly, 
it shuld be fixed now.

The redirect idea sounds nice, and IMHO it's the only thing that works. 
Java has provided us with a very good warning. The redirect idea is a 
good workaround but you have to agree, it's a hack. :-)

Elias

Oct 30 2003

J Anderson <anderson badmama.com.au.REMOVE> writes:

Helmut Leitner wrote:

Roberto Mariottini wrote:
  

In article <bnn9a0$1o09$1 digitaldaemon.com>, Walter says...
[...]
    

etc
There are lots of 'other' modules for D, and right now there is no
organized way to deal with them. There needs to be a place for them.
The etc heirarchy will mirror the standard one, i.e. there will
be etc.c, etc.os.windows, ... These will not be official parts of D
nor will they be standardized. However, candidates for standardization
will be drawn from etc. etc is the place for
not-quite-there-yet-but-still-useful modules.
      


I'd prefer 'ext', that means extension.
    


I don't think we need to take this so literally.

Walter surely will find better places in std for most modules. 
I think its just an "default" case: "...and if we really don't
know where to put a module, then we have still this place..."

If no-one likes it, just the better. Nothing should ever go there.

  


I think etc would be a good place to get early access to new ideas and 
modules, like in openGL's extension mechanism.  There may be allot of 
(constructive) argument about one aspect of something, and it could be 
threshed out in more then one prototype implementation, parhaps by 
several different companies for example.  When one implementation 
becomes widely accepted, it would be moved over the the main lot as a 
new library.  It's a good for people who just want to get on with the 
coding.

But I think ext is a better name for that.

Oct 30 2003

"Walter" <walter digitalmars.com> writes:

"J Anderson" <anderson badmama.com.au.REMOVE> wrote in message
news:bnr4eh$10q3$1 digitaldaemon.com...
 I think etc would be a good place to get early access to new ideas and
 modules, like in openGL's extension mechanism.  There may be allot of
 (constructive) argument about one aspect of something, and it could be
 threshed out in more then one prototype implementation, parhaps by
 several different companies for example.  When one implementation
 becomes widely accepted, it would be moved over the the main lot as a
 new library.  It's a good for people who just want to get on with the
 coding.


Yes, exactly.

Oct 30 2003

"Walter" <walter digitalmars.com> writes:

"Roberto Mariottini" <Roberto_member pathlink.com> wrote in message
news:bnqp2a$i4q$1 digitaldaemon.com...
 What does 'etc' stand for?


'etcetera, etcetera, etcetera' (doing my best Yul Brynner impersonation)

Oct 30 2003

Charles Hixson <charleshixsn earthlink.net> writes:

Roberto Mariottini wrote:
 ...
 What does 'etc' stand for?
 I'd prefer 'ext', that means extension.
 
 Ciao
 
 


etc stands for "et cetera", approx the same as "and other stuff" 
(with the normal implication "and other similar stuff").  Orig. from 
the latin, but now common in English, and rather like the German 
z.b. (which I can't quite remember the expansion of).

In the context of computers, /etc is the root level directory where 
Linux/Unix programs get their configuration files, and where System 
V descendand versions of Unix (also Linux) systems get their boot 
time information about what services should be started, etc.

I'm not sure whether Walter was saying that there would literally be 
a library directory named etc, or whether he was saying the other 
similar directory names would exist.  (Both are plausible.)

Oct 31 2003

Hauke Duden <H.NS.Duden gmx.net> writes:

Charles Hixson wrote:
 etc stands for "et cetera", approx the same as "and other stuff" (with 
 the normal implication "and other similar stuff").  Orig. from the 
 latin, but now common in English, and rather like the German z.b. (which 
 I can't quite remember the expansion of).


If you're going to be a smart ass, please make sure that what you say is 
correct ;)

The german equivalent of "etc." would be "usw." = "und so weiter", which 
roughly means "and so on".

z.B. is the short form of "zum Beispiel" which means "for example".

And yes, I'm a smart ass too ;).

Hauke

Oct 31 2003

"Walter" <walter digitalmars.com> writes:

"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:bnunf3$e0l$1 digitaldaemon.com...
 And yes, I'm a smart ass too ;).


Aren't we all? <g>

Oct 31 2003

"Sean L. Palmer" <palmer.sean verizon.net> writes:

"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:bnunf3$e0l$1 digitaldaemon.com...
 z.B. is the short form of "zum Beispiel" which means "for example".


In English we use the Latin "e.g."   I always get e.g. and i.e. mixed up.
"i.e." means "that is".  I'm not sure why we use those abbreviations if we
don't know what they mean.  I think we know what they mean but we don't know
why they mean what they mean, if you know what I mean.

 And yes, I'm a smart ass too ;).


Your point is...?  ;)

Nov 01 2003

Charles Hixson <charleshixsn earthlink.net> writes:

Hauke Duden wrote:
 Charles Hixson wrote:
 ...
 latin, but now common in English, and rather like the German z.b. 
 (which I can't quite remember the expansion of).


 z.B. is the short form of "zum Beispiel" which means "for example".
 
 And yes, I'm a smart ass too ;).
 
 Hauke
 


Sorry, it's been a number of decades.  My appologies.

Nov 01 2003

Ant <Ant_member pathlink.com> writes:

In article <bnn9a0$1o09$1 digitaldaemon.com>, Walter says...


std.c
 Contains D interfaces to standard C library functions, like
 std.c.stdio, std.c.stdlib, std.c.math.


kinda like puting together stawberies and chilly peppers
because they are the same color...

(I know Walter will never change his mind (reverse psychology)
but the rest of you has to agree ;)

Ant

Oct 30 2003

"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:

Yes, I do.

I don't like that part. I think modules should be broken down logically,
rather on implementation details.

I don't care if something is implemented in C or in D, rather what it can do
for me.

There's a deeper aspect to this. I'm biased on this issue, so you'll have to
take the following with a pinch of salt.

For those of you who do not know, I'm creating a platform-independent,
source-supplied, recursive searching library called recls
(http://recls.org/), and documented in my bi-monthly in-print CUJ column. It
is implemented in C/C++, presents a C interface to the world, and it is to
be mapped to just about any language you can think of (C++, D, Java, .NET,
Perl, Python, Ruby, etc.). There's a beta D mapping available at the
website.

I can't see any reason why recls, and similar libraries, can't become part
of the standard distribution of D, since there're no royalty implications.
However, since it is written in C/C++, it is not 100% pure D. This is
absolutely no impediment to using D on Win32 or UNIX, and I would bet that
recls will be ported to MAC and other platforms before D is. (Even if it's
not, it would be a simple matter to do so.)

People who've used the library so far have said it's very useful (some have
commented that it's the rec-search they always wanted, which is nice), but I
think it will be rejected by the DLG (if we ever get one) because it's not
D.

Anyway, feel free to dismiss this as a self-promotion rant, but I think it's
a good example of an issue we're going to come up against a great deal. Why
reject, or cause to be rewritten, or squirrel away in the "dirty C corner"
libraries that already exist (and is tested), since D makes a big point of C
compatibility in the first place?


-- 
Matthew Wilson

STLSoft moderator and C++ monomaniac       (http://www.stlsoft.org)
Contributing editor, C/C++ Users Journal
(www.synesis.com.au/articles.html#columns)

"You can tell a Yorkshireman, but you can't tell him much!" -- Uncle Michael

----------------------------------------------------------------------------
---



"Ant" <Ant_member pathlink.com> wrote in message
news:bns6d8$2gv2$1 digitaldaemon.com...
 In article <bnn9a0$1o09$1 digitaldaemon.com>, Walter says...


std.c
 Contains D interfaces to standard C library functions, like
 std.c.stdio, std.c.stdlib, std.c.math.


 kinda like puting together stawberies and chilly peppers
 because they are the same color...

 (I know Walter will never change his mind (reverse psychology)
 but the rest of you has to agree ;)

 Ant

Oct 30 2003

"Walter" <walter digitalmars.com> writes:

"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:bns6u8$2hnq$1 digitaldaemon.com...
 I don't care if something is implemented in C or in D, rather what it can


 for me.


You're right, it doesn't matter if the library is implemented in C or D. But
it *does* matter if it follows C or D conventions. For example, if a module
uses errno or error numbers, 0 terminated strings, expects the caller to use
malloc/free on data passed through its interface, etc., I'd prefer to put it
under a C package so that gives the potential user of it some extra
notification that it does not follow D conventions.

D conventions would be using exceptions for error notification, length'd (!)
strings, garbage collection, COW, etc.

A typical C package can be 'wrapped' to give it D conventions, and then it
would be suitable for inclusion in a non-C heirarchy. I am currently working
on a D version of the popular zlib module for just that reason. The
underlying implementation will remain in C (it's a pointless waste of time
to convert that code to D).

 Anyway, feel free to dismiss this as a self-promotion rant, but I think


 a good example of an issue we're going to come up against a great deal.


 reject, or cause to be rewritten, or squirrel away in the "dirty C corner"
 libraries that already exist (and is tested), since D makes a big point of


 compatibility in the first place?


I'd call it the "C corner", not the "dirty C corner" <G>. All that would
mean to the D user of the package would be he'd need to double check things
like 0 terminated strings, returned error codes, storage allocation, and
other C conventions.

Oct 30 2003

"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:

 I don't care if something is implemented in C or in D, rather what it




 do
 for me.


 You're right, it doesn't matter if the library is implemented in C or D.


 it *does* matter if it follows C or D conventions. For example, if a


 uses errno or error numbers, 0 terminated strings, expects the caller to


 malloc/free on data passed through its interface, etc., I'd prefer to put


 under a C package so that gives the potential user of it some extra
 notification that it does not follow D conventions.

 D conventions would be using exceptions for error notification, length'd


 strings, garbage collection, COW, etc.

 A typical C package can be 'wrapped' to give it D conventions, and then it
 would be suitable for inclusion in a non-C heirarchy. I am currently


 on a D version of the popular zlib module for just that reason. The
 underlying implementation will remain in C (it's a pointless waste of time
 to convert that code to D).

 Anyway, feel free to dismiss this as a self-promotion rant, but I think


 a good example of an issue we're going to come up against a great deal.


 reject, or cause to be rewritten, or squirrel away in the "dirty C




 libraries that already exist (and is tested), since D makes a big point




 C
 compatibility in the first place?


 I'd call it the "C corner", not the "dirty C corner" <G>. All that would
 mean to the D user of the package would be he'd need to double check


 like 0 terminated strings, returned error codes, storage allocation, and
 other C conventions.


Ok, I see that. But in that case, you'll have the hierarchies on their heads

std.c.filesystem.recls - the C stuff
std.filesystem.recls - the D stuff

whereas what we should see is

std.filesystem.recls.c - the C stuff
std.filesystem.recls - the D stuff

(I realise that recls.c.d is not going to work, under the current naming
system)

How've you done the zlib module naming? I assume the C interface and a D
layer are both provided?

Oct 30 2003

"Walter" <walter digitalmars.com> writes:

"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:bnsfit$2tsp$1 digitaldaemon.com...
 Ok, I see that. But in that case, you'll have the hierarchies on their


 std.c.filesystem.recls - the C stuff
 std.filesystem.recls - the D stuff

 whereas what we should see is

 std.filesystem.recls.c - the C stuff
 std.filesystem.recls - the D stuff

 (I realise that recls.c.d is not going to work, under the current naming
 system)

 How've you done the zlib module naming? I assume the C interface and a D
 layer are both provided?


Here's what I did. First, I did a simple module with declarations to make
the C zlib functions accessible from D. It makes no attempt to hide zlib's C
conventions. This will not be an official D package, but is still useful, so
I stuffed it in etc.c.zlib. Then I build a D version that implements a
conventional D interface to the zlib functionality. I called this std.zlib.
Now, it works out that std.zlib is implemented by calling the functions in
etc.c.zlib, but that is quite irrelevant to (and hidden from) the user of
std.zlib.

In the future, I can see porting the zlib C code to D and implementing them
directly in std.zlib. But that won't affect the user of std.zlib, except
that it might be a little smaller and faster.

Oct 30 2003

"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:

I totally agree that users of std.zlib should not have to care about
etc.c.zlib

However, where we seem to disagree (and not just here) is that the D way,
which is (reading between the lines) an OO + exceptions way, is the only
way. This is what I rail against.

I want etc.c.filesystem.recls to be accessible to programmers and just as
valid and supported as std.filesystem.recls, or whatever, and the sames
probably goes for etc.c.zlib (unless you've made it pretty ugly and
unusable).

If we have to program in only one way in D, then people will be (rightly)
turned off. If not, then the thin C=>D translator layers should be
accessible, and not in a curious corner, but in a logical place.

The world is a rich place, and the "one way or the highway" is that popular
and efficient language Java. It's horses for courses, and D should support
all models, and prescribe as little as possible.

Don't you agree?


"Walter" <walter digitalmars.com> wrote in message
news:bnsrb4$h4o$1 digitaldaemon.com...
 "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
 news:bnsfit$2tsp$1 digitaldaemon.com...
 Ok, I see that. But in that case, you'll have the hierarchies on their


 std.c.filesystem.recls - the C stuff
 std.filesystem.recls - the D stuff

 whereas what we should see is

 std.filesystem.recls.c - the C stuff
 std.filesystem.recls - the D stuff

 (I realise that recls.c.d is not going to work, under the current naming
 system)

 How've you done the zlib module naming? I assume the C interface and a D
 layer are both provided?


 Here's what I did. First, I did a simple module with declarations to make
 the C zlib functions accessible from D. It makes no attempt to hide zlib's


 conventions. This will not be an official D package, but is still useful,


 I stuffed it in etc.c.zlib. Then I build a D version that implements a
 conventional D interface to the zlib functionality. I called this


 Now, it works out that std.zlib is implemented by calling the functions in
 etc.c.zlib, but that is quite irrelevant to (and hidden from) the user of
 std.zlib.

 In the future, I can see porting the zlib C code to D and implementing


 directly in std.zlib. But that won't affect the user of std.zlib, except
 that it might be a little smaller and faster.

Oct 30 2003

"Walter" <walter digitalmars.com> writes:

I guess where I disagree with you is that putting something that uses C
conventions under a package named 'std.c' is some undesirable place. I don't
think it's some unfavored place at all, it just acknowledges that it uses
different conventions. I also feel that there should be some style
consistency in standard D library code. Having one module use errno and
another use exceptions just makes it look like a hodgepodge. If one package
does something unconventional, it needs to have a strong reason for the
divergence.

The D way is using exceptions for error notification rather than error
codes, but is not necessarilly OO. Several D modules, such as std.string and
std.math, are not OO at all.

BTW, the etc.c.zlib is just as usable or unusable as the C zlib library is,
as that's all it is. I find it more complex than necessary (there are a
number of parameters you basically have to read the source code to zlib to
figure out what they're good for and how to use them, that's unacceptable),
it has a bunch of stuff related to storage allocation, and it uses error
codes rather than exceptions. Hence, I decided a D wrapper that put an easy
face on it made sense, and the result is std.zlib.

"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:bnsse5$j54$1 digitaldaemon.com...
 I totally agree that users of std.zlib should not have to care about
 etc.c.zlib

 However, where we seem to disagree (and not just here) is that the D way,
 which is (reading between the lines) an OO + exceptions way, is the only
 way. This is what I rail against.

 I want etc.c.filesystem.recls to be accessible to programmers and just as
 valid and supported as std.filesystem.recls, or whatever, and the sames
 probably goes for etc.c.zlib (unless you've made it pretty ugly and
 unusable).

 If we have to program in only one way in D, then people will be (rightly)
 turned off. If not, then the thin C=>D translator layers should be
 accessible, and not in a curious corner, but in a logical place.

 The world is a rich place, and the "one way or the highway" is that


 and efficient language Java. It's horses for courses, and D should support
 all models, and prescribe as little as possible.

 Don't you agree?


 "Walter" <walter digitalmars.com> wrote in message
 news:bnsrb4$h4o$1 digitaldaemon.com...
 "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
 news:bnsfit$2tsp$1 digitaldaemon.com...
 Ok, I see that. But in that case, you'll have the hierarchies on their


 std.c.filesystem.recls - the C stuff
 std.filesystem.recls - the D stuff

 whereas what we should see is

 std.filesystem.recls.c - the C stuff
 std.filesystem.recls - the D stuff

 (I realise that recls.c.d is not going to work, under the current






 system)

 How've you done the zlib module naming? I assume the C interface and a






 layer are both provided?


 Here's what I did. First, I did a simple module with declarations to




 the C zlib functions accessible from D. It makes no attempt to hide




 C
 conventions. This will not be an official D package, but is still




 so
 I stuffed it in etc.c.zlib. Then I build a D version that implements a
 conventional D interface to the zlib functionality. I called this


 Now, it works out that std.zlib is implemented by calling the functions




 etc.c.zlib, but that is quite irrelevant to (and hidden from) the user




 std.zlib.

 In the future, I can see porting the zlib C code to D and implementing


 directly in std.zlib. But that won't affect the user of std.zlib, except
 that it might be a little smaller and faster.

Oct 31 2003

"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:

 I guess where I disagree with you is that putting something that uses C
 conventions under a package named 'std.c' is some undesirable place. I


 think it's some unfavored place at all, it just acknowledges that it uses
 different conventions. I also feel that there should be some style
 consistency in standard D library code. Having one module use errno and
 another use exceptions just makes it look like a hodgepodge. If one


 does something unconventional, it needs to have a strong reason for the
 divergence.


One man's hodgepodge is another man's freedom of expression.

 The D way is using exceptions for error notification rather than error
 codes, but is not necessarilly OO. Several D modules, such as std.string


 std.math, are not OO at all.


I really don't think obliging people to always favour exceptions is going to
fly. Exception-handling is the emporer's new clothes; nobody dares to speak
their qualms. That's not to say I don't use it, or believe it is useful, but
I've got both feet firmly in the Kernighan and Pike camp. Exceptions are for
exceptional circumstances. I don't think all that is error-handling falls
within that description.

But, sure, other people have different opinions, and paradigms of work. But
that backs up my argument that we should support multiple programming
paradigms.

As to the consistency issue, I think that modules that are exclusively free
functions should not use exceptions for error-handling. Those that are
class-based are another matter.

 BTW, the etc.c.zlib is just as usable or unusable as the C zlib library


 as that's all it is. I find it more complex than necessary (there are a
 number of parameters you basically have to read the source code to zlib to
 figure out what they're good for and how to use them, that's


 it has a bunch of stuff related to storage allocation, and it uses error
 codes rather than exceptions. Hence, I decided a D wrapper that put an


 face on it made sense, and the result is std.zlib.


I've got no problem with this. I couldn't agree more. C libs should have
user friendly layers put over them. But they should also be available for
use, since virtually any layer adds stuff that may not be necessary under
all circumstances.

I see three levels of APIs.

1. Raw C APIs
2. D-ified C APIs, and D free functions
3. Classes

I am not arguing for much, if any, of 1, but I am arguing strongly that 2 is
just as valid as 3.

 "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
 news:bnsse5$j54$1 digitaldaemon.com...
 I totally agree that users of std.zlib should not have to care about
 etc.c.zlib

 However, where we seem to disagree (and not just here) is that the D




 which is (reading between the lines) an OO + exceptions way, is the only
 way. This is what I rail against.

 I want etc.c.filesystem.recls to be accessible to programmers and just




 valid and supported as std.filesystem.recls, or whatever, and the sames
 probably goes for etc.c.zlib (unless you've made it pretty ugly and
 unusable).

 If we have to program in only one way in D, then people will be




 turned off. If not, then the thin C=>D translator layers should be
 accessible, and not in a curious corner, but in a logical place.

 The world is a rich place, and the "one way or the highway" is that


 and efficient language Java. It's horses for courses, and D should




 all models, and prescribe as little as possible.

 Don't you agree?


 "Walter" <walter digitalmars.com> wrote in message
 news:bnsrb4$h4o$1 digitaldaemon.com...
 "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
 news:bnsfit$2tsp$1 digitaldaemon.com...
 Ok, I see that. But in that case, you'll have the hierarchies on








 heads
 std.c.filesystem.recls - the C stuff
 std.filesystem.recls - the D stuff

 whereas what we should see is

 std.filesystem.recls.c - the C stuff
 std.filesystem.recls - the D stuff

 (I realise that recls.c.d is not going to work, under the current






 system)

 How've you done the zlib module naming? I assume the C interface and








 D
 layer are both provided?


 Here's what I did. First, I did a simple module with declarations to




 the C zlib functions accessible from D. It makes no attempt to hide




 C
 conventions. This will not be an official D package, but is still




 so
 I stuffed it in etc.c.zlib. Then I build a D version that implements a
 conventional D interface to the zlib functionality. I called this


 Now, it works out that std.zlib is implemented by calling the






 in
 etc.c.zlib, but that is quite irrelevant to (and hidden from) the user




 std.zlib.

 In the future, I can see porting the zlib C code to D and implementing


 directly in std.zlib. But that won't affect the user of std.zlib,






 that it might be a little smaller and faster.

Oct 31 2003

"Walter" <walter digitalmars.com> writes:

"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:bntjhh$1srj$2 digitaldaemon.com...
 One man's hodgepodge is another man's freedom of expression.


Sure. But nobody using D is censored or constrained by the std conventions.
D is a multiparadigm language.

 I really don't think obliging people to always favour exceptions is going


 fly. Exception-handling is the emporer's new clothes; nobody dares to


 their qualms. That's not to say I don't use it, or believe it is useful,


 I've got both feet firmly in the Kernighan and Pike camp.


I'm not familiar with the reference.

 Exceptions are for
 exceptional circumstances.


Yes, I agree.

 I don't think all that is error-handling falls
 within that description.


There's certainly a grey area between clear errors and what is expected
behavior.

 But, sure, other people have different opinions, and paradigms of work.


 that backs up my argument that we should support multiple programming
 paradigms.

 As to the consistency issue, I think that modules that are exclusively


 functions should not use exceptions for error-handling. Those that are
 class-based are another matter.


Why? Consider std.file.read(). It's a free function that reads the contents
of a file into an array. It throws an exception if the file doesn't exist or
if the read failed in some way. I use this function all the time, and find
it very handy to rely on the exception mechanism to report errors rather
than the C way of testing the result every time.

 I see three levels of APIs.

 1. Raw C APIs
 2. D-ified C APIs, and D free functions
 3. Classes

 I am not arguing for much, if any, of 1, but I am arguing strongly that 2


 just as valid as 3.


I think we're misunderstanding each other, then, because I am in full
agreement with you there!

Oct 31 2003

"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:

 One man's hodgepodge is another man's freedom of expression.


 Sure. But nobody using D is censored or constrained by the std


 D is a multiparadigm language.


Good.

 I really don't think obliging people to always favour exceptions is




 to
 fly. Exception-handling is the emporer's new clothes; nobody dares to


 their qualms. That's not to say I don't use it, or believe it is useful,


 I've got both feet firmly in the Kernighan and Pike camp.


 I'm not familiar with the reference.


"The Practise Of Programming", AWL, 1999

 Exceptions are for
 exceptional circumstances.


 Yes, I agree.


Cool

 I don't think all that is error-handling falls
 within that description.


 There's certainly a grey area between clear errors and what is expected
 behavior.


Indeed there is, and ...

 But, sure, other people have different opinions, and paradigms of work.


 that backs up my argument that we should support multiple programming
 paradigms.

 As to the consistency issue, I think that modules that are exclusively


 functions should not use exceptions for error-handling. Those that are
 class-based are another matter.


 Why? Consider std.file.read(). It's a free function that reads the


 of a file into an array. It throws an exception if the file doesn't exist


 if the read failed in some way. I use this function all the time, and find
 it very handy to rely on the exception mechanism to report errors rather
 than the C way of testing the result every time.


... you cleverly pick an exceptional example that ably demonstrates your
point, and slashes mine. :)

 I see three levels of APIs.

 1. Raw C APIs
 2. D-ified C APIs, and D free functions
 3. Classes

 I am not arguing for much, if any, of 1, but I am arguing strongly that




 is
 just as valid as 3.


 I think we're misunderstanding each other, then, because I am in full
 agreement with you there!


Maybe

Oct 31 2003

Roberto Mariottini <Roberto_member pathlink.com> writes:

In article <bntd28$1k51$1 digitaldaemon.com>, Walter says...


BTW, the etc.c.zlib is just as usable or unusable as the C zlib library is,
as that's all it is. I find it more complex than necessary (there are a
number of parameters you basically have to read the source code to zlib to
figure out what they're good for and how to use them, that's unacceptable),
it has a bunch of stuff related to storage allocation, and it uses error
codes rather than exceptions. Hence, I decided a D wrapper that put an easy
face on it made sense, and the result is std.zlib.


BTW, have you thougt about making also a zip-file handling library in the D
standard libraries?
I find this very useful to be included by default in every Java implementation,
for example.

Ciao

P.S.: I deduce that my proposal of renaming etc.* to ext.* was refused, right?

Oct 31 2003

"Walter" <walter digitalmars.com> writes:

"Roberto Mariottini" <Roberto_member pathlink.com> wrote in message
news:bntlcf$1v5t$1 digitaldaemon.com...
 In article <bntd28$1k51$1 digitaldaemon.com>, Walter says...
BTW, the etc.c.zlib is just as usable or unusable as the C zlib library




as that's all it is. I find it more complex than necessary (there are a
number of parameters you basically have to read the source code to zlib




figure out what they're good for and how to use them, that's




it has a bunch of stuff related to storage allocation, and it uses error
codes rather than exceptions. Hence, I decided a D wrapper that put an




face on it made sense, and the result is std.zlib.




 standard libraries?
 I find this very useful to be included by default in every Java


 for example.


Yes, I have thought of it, and I've already implemented std.zip. <g>. It
will be in the next release. Great minds think alike!

 P.S.: I deduce that my proposal of renaming etc.* to ext.* was refused,



When I see 'ext' I think 'external'. I kinda like 'etc', it is only 3
letters long and is a very common abbreviation for 'etcetera' and is not
likely to be confused with anything else.

Oct 31 2003

Patrick Down <pat codemoon.com> writes:

"Walter" <walter digitalmars.com> wrote in
news:bnsrb4$h4o$1 digitaldaemon.com: 
 Here's what I did. First, I did a simple module with declarations to
 make the C zlib functions accessible from D. It makes no attempt to
 hide zlib's C conventions. This will not be an official D package, but
 is still useful, so I stuffed it in etc.c.zlib. Then I build a D
 version that implements a conventional D interface to the zlib
 functionality. I called this std.zlib. Now, it works out that std.zlib
 is implemented by calling the functions in etc.c.zlib, but that is
 quite irrelevant to (and hidden from) the user of std.zlib.
 
 In the future, I can see porting the zlib C code to D and implementing
 them directly in std.zlib. But that won't affect the user of std.zlib,
 except that it might be a little smaller and faster.


Why not std.zlib and std.zlib.c?  This make more sense
to me from a packageing standpoint.  Everything needed for the zlib
module is in one directory hierarchy instead of two.

Oct 31 2003

"Walter" <walter digitalmars.com> writes:

"Patrick Down" <pat codemoon.com> wrote in message
news:Xns94255512CA292patcodemooncom 63.105.9.61...
 Why not std.zlib and std.zlib.c?  This make more sense
 to me from a packageing standpoint.  Everything needed for the zlib
 module is in one directory hierarchy instead of two.


Because I don't see the raw zlib interface as being useful enough to be in
the std heirarchy. I think of it as "it's there if you want it, but it isn't
a core feature of the D library".

Oct 31 2003

Benji Smith <dlanguage xxagg.com> writes:

On Thu, 30 Oct 2003 20:49:12 -0800, "Walter" <walter digitalmars.com>
wrote:

Here's what I did. First, I did a simple module with declarations to make
the C zlib functions accessible from D. It makes no attempt to hide zlib's C
conventions. This will not be an official D package, but is still useful, so
I stuffed it in etc.c.zlib. Then I build a D version that implements a
conventional D interface to the zlib functionality. I called this std.zlib.
Now, it works out that std.zlib is implemented by calling the functions in
etc.c.zlib, but that is quite irrelevant to (and hidden from) the user of
std.zlib.


This is a big red flag to me. The standard library (std.zlib) is
dependant upon something outside of the standard library (etc.c.zlib).
As far as I'm concerned, the standard library should be entirely
self-contained.

It seems to me that if a standard library module needs to depend on a
c module, it should be something in std.c rather than in etc.c (maybe
we need both std.c and etc.c).

Oct 31 2003

"Walter" <walter digitalmars.com> writes:

"Benji Smith" <dlanguage xxagg.com> wrote in message
news:3qf5qv066p5295hqfbo0isgh1c8aeg101f 4ax.com...
 On Thu, 30 Oct 2003 20:49:12 -0800, "Walter" <walter digitalmars.com>
 wrote:
Here's what I did. First, I did a simple module with declarations to make
the C zlib functions accessible from D. It makes no attempt to hide




conventions. This will not be an official D package, but is still useful,




I stuffed it in etc.c.zlib. Then I build a D version that implements a
conventional D interface to the zlib functionality. I called this




Now, it works out that std.zlib is implemented by calling the functions




etc.c.zlib, but that is quite irrelevant to (and hidden from) the user of
std.zlib.


 dependant upon something outside of the standard library (etc.c.zlib).
 As far as I'm concerned, the standard library should be entirely
 self-contained.


In general, you're right. But in some cases the implementation should be
hidden from the user. The user of std.zlib is not dependent on it.

 It seems to me that if a standard library module needs to depend on a
 c module, it should be something in std.c rather than in etc.c (maybe
 we need both std.c and etc.c).


I don't think it's necessary for the implementation of it to be in std.

Oct 31 2003

Helmut Leitner <helmut.leitner chello.at> writes:

Walter wrote:
 
 "Benji Smith" <dlanguage xxagg.com> wrote in message
 news:3qf5qv066p5295hqfbo0isgh1c8aeg101f 4ax.com...
 On Thu, 30 Oct 2003 20:49:12 -0800, "Walter" <walter digitalmars.com>
 wrote:
Here's what I did. First, I did a simple module with declarations to make
the C zlib functions accessible from D. It makes no attempt to hide




conventions. This will not be an official D package, but is still useful,




I stuffed it in etc.c.zlib. Then I build a D version that implements a
conventional D interface to the zlib functionality. I called this




Now, it works out that std.zlib is implemented by calling the functions




etc.c.zlib, but that is quite irrelevant to (and hidden from) the user of
std.zlib.


 dependant upon something outside of the standard library (etc.c.zlib).
 As far as I'm concerned, the standard library should be entirely
 self-contained.


 In general, you're right. But in some cases the implementation should be
 hidden from the user. The user of std.zlib is not dependent on it.
 
 It seems to me that if a standard library module needs to depend on a
 c module, it should be something in std.c rather than in etc.c (maybe
 we need both std.c and etc.c).


 I don't think it's necessary for the implementation of it to be in std.


But then you talk and build a bigger entity than std. 

This I called dlib, that which incloses all modules that
are downloaded with the standard distribution.

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com

Nov 01 2003

Hauke Duden <H.NS.Duden gmx.net> writes:

Walter wrote:
 You're right, it doesn't matter if the library is implemented in C or D. But
 it *does* matter if it follows C or D conventions. For example, if a module
 uses errno or error numbers, 0 terminated strings, expects the caller to use
 malloc/free on data passed through its interface, etc., I'd prefer to put it
 under a C package so that gives the potential user of it some extra
 notification that it does not follow D conventions.



Good point. This made me think about the following:

Is it possible to import a module without adding its symbols directly to 
the current namespace?

Since C functions require different handling than D functions I would 
like to import such modules in a way so that I have to explicitly type 
std.c.func() instead of func(). Just as a reminder to myself and the 
people reading my code that one has to take care how to use them.

This would be especially important for string functions, I expect, since 
  forgetting to add the null-terminator can cause a crash.

Any way to do this?

Hauke

Oct 31 2003

"Walter" <walter digitalmars.com> writes:

"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:bntgtv$1pdn$1 digitaldaemon.com...
 Good point. This made me think about the following:

 Is it possible to import a module without adding its symbols directly to
 the current namespace?

 Since C functions require different handling than D functions I would
 like to import such modules in a way so that I have to explicitly type
 std.c.func() instead of func(). Just as a reminder to myself and the
 people reading my code that one has to take care how to use them.

 This would be especially important for string functions, I expect, since
   forgetting to add the null-terminator can cause a crash.

 Any way to do this?


No, there currently isn't a way to do that. BTW, import doesn't exactly add
a symbol to the current namespace, it just adds a search of the import
module if the name isn't already in the current namespace. In other words,
any names in the current namespace override imported names.

Hmm, that does suggest a way to do it ... define a bunch of dummy symbols
with the same name, then anyone using the import will be forced to qualify
it!

Oct 31 2003

Hauke Duden <H.NS.Duden gmx.net> writes:

Walter wrote:
Since C functions require different handling than D functions I would
like to import such modules in a way so that I have to explicitly type
std.c.func() instead of func(). Just as a reminder to myself and the
people reading my code that one has to take care how to use them.

This would be especially important for string functions, I expect, since
  forgetting to add the null-terminator can cause a crash.

Any way to do this?


 
 No, there currently isn't a way to do that. BTW, import doesn't exactly add
 a symbol to the current namespace, it just adds a search of the import
 module if the name isn't already in the current namespace. In other words,
 any names in the current namespace override imported names.
 
 Hmm, that does suggest a way to do it ... define a bunch of dummy symbols
 with the same name, then anyone using the import will be forced to qualify
 it!


You mean like this?

import std.c.stdio;
int printf;
int scanf;
int fopen;
int fread;
[snipped about a hundred further definitions]

Every time I import std.c.stdio? That isn't really practical ;).

I know you're probably sick of all these feature requests, but don't you 
think there should be an EASY way to do such an import?

Maybe something like

"use std.c.stdio;" / "using std.c.stdio"

or

"reference std.c.stdio;"

or

"access std.c.stdio;"

which would mean that the current module accesses the specified module, 
but the symbols are not "imported" and must be references using fully 
qualified names.

Maybe this could also be done by adding a new feature to import. Like 
the ability to specify an alias for the imported module's namespace.

For example:

import std.c.stdio as c;

If the "as" part is left out the symbols are added to the current 
namespace (or, as you put it, an automatic search for that namespace is 
added to the current namespace). Otherwise they are added to a namespace 
with the specified name. So one would have to write "c.printf" instead 
of just "printf", which is just what I want: it is obvious that a C 
function is called, so I am reminded to zero-terminate strings, for example.

This could also be useful to "flatten" deep module hierarchies. If one 
uses two modules that define the same symbols, one has to use fully 
qualified names, right? With such an "import as" you could do the following:

import foo.bar.flobbox.windows.henry as henry;
import foo_version2.bar.flobbox.windows.henry as henry2;

Then you could write

henry.someFunc();
and
henry2.someFunc();

instead of

foo.bar.flobbox.windows.henry.someFunc();
foo_version2.bar.flobbox.windows.henry.someFunc();

Could come in handy...

Hauke

Oct 31 2003

"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:

"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:bnup38$g4e$1 digitaldaemon.com...
 Walter wrote:
Since C functions require different handling than D functions I would
like to import such modules in a way so that I have to explicitly type
std.c.func() instead of func(). Just as a reminder to myself and the
people reading my code that one has to take care how to use them.

This would be especially important for string functions, I expect, since
  forgetting to add the null-terminator can cause a crash.

Any way to do this?



 No, there currently isn't a way to do that. BTW, import doesn't exactly




 a symbol to the current namespace, it just adds a search of the import
 module if the name isn't already in the current namespace. In other




 any names in the current namespace override imported names.

 Hmm, that does suggest a way to do it ... define a bunch of dummy




 with the same name, then anyone using the import will be forced to




 it!


 You mean like this?

 import std.c.stdio;
 int printf;
 int scanf;
 int fopen;
 int fread;
 [snipped about a hundred further definitions]

 Every time I import std.c.stdio? That isn't really practical ;).


I assumed Walter was talking about internal to the compiler. It would indeed
be worrying if he meant your interpretation.

Big W, say it ain't so!

Oct 31 2003

"Walter" <walter digitalmars.com> writes:

"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:bnup38$g4e$1 digitaldaemon.com...
 Hmm, that does suggest a way to do it ... define a bunch of dummy




 with the same name, then anyone using the import will be forced to




 it!


 You mean like this?

 import std.c.stdio;
 int printf;
 int scanf;
 int fopen;
 int fread;
 [snipped about a hundred further definitions]

 Every time I import std.c.stdio? That isn't really practical ;).


I know. It's just a thought.

 I know you're probably sick of all these feature requests, but don't you
 think there should be an EASY way to do such an import?

 Maybe something like

 "use std.c.stdio;" / "using std.c.stdio"

 or

 "reference std.c.stdio;"

 or

 "access std.c.stdio;"

 which would mean that the current module accesses the specified module,
 but the symbols are not "imported" and must be references using fully
 qualified names.


I understand what you're looking for. I'm not ready to implement that yet,
though. Too many other things first!

 Maybe this could also be done by adding a new feature to import. Like
 the ability to specify an alias for the imported module's namespace.

 For example:

 import std.c.stdio as c;

 If the "as" part is left out the symbols are added to the current
 namespace (or, as you put it, an automatic search for that namespace is
 added to the current namespace). Otherwise they are added to a namespace
 with the specified name. So one would have to write "c.printf" instead
 of just "printf", which is just what I want: it is obvious that a C
 function is called, so I am reminded to zero-terminate strings, for


 This could also be useful to "flatten" deep module hierarchies. If one
 uses two modules that define the same symbols, one has to use fully
 qualified names, right? With such an "import as" you could do the


 import foo.bar.flobbox.windows.henry as henry;
 import foo_version2.bar.flobbox.windows.henry as henry2;

 Then you could write

 henry.someFunc();
 and
 henry2.someFunc();

 instead of

 foo.bar.flobbox.windows.henry.someFunc();
 foo_version2.bar.flobbox.windows.henry.someFunc();

 Could come in handy...


The alias already works for module names:

    import foo.bar.abc;
    alias foo.bar.abc xyz;
    ...
    xyz.func();

Oct 31 2003

Ant <Ant_member pathlink.com> writes:

In article <bnn9a0$1o09$1 digitaldaemon.com>, Walter says...
There have been a lot of good ideas and points made about this in the
discussions here. The upshot is there isn't a single right answer,
but there are a few clearly wrong ones <g>. So it's up to me to just pick
one of the right answers.


Do you mean:

##########################

std
|-- c
|   |-- process.d
|   |-- stdio.d
|   `-- stdlib.d
|-- etc
|-- internal
|   |-- aaA.d
|   |-- achar.d
|   |-- adi.d
|   |-- alloca.d
|   |-- array.d
|   |-- arraycast.d
|   |-- arraycat.d
|   |-- assert.d
|   |-- cast.d
|   |-- critical.c
|   |-- dmain2.d
|   |-- errno.c
|   |-- gc.d
|   |-- gc2
|   |-- gcstats.d
|   |-- intrinsic.d
|   |-- invariant.d
|   |-- llmath.d
|   |-- mars.h
|   |-- memset.d
|   |-- minit.asm
|   |-- moduleinit.d
|   |-- monitor.c
|   |-- obj.d
|   |-- object.d
|   |-- outofmemory.d
|   |-- switch.d
|   `-- switcherr.d
|-- os
|   |-- linux
|   |   |-- linux.d
|   |   `-- linuxextern.d
|   |-- windows
|   |   |-- com.d
|   |   |-- iunknown.d
|   |   |-- registry.d
|   |   |-- syserror.d
|   |   `-- windows.d
|   |-- date.d
|   |-- file.d
|   |-- path.d
|   |-- system.d
|   |-- thread.d
|   `-- time.d
|-- typeinfo
|   |-- ti_AC.d
|   |-- ti_Aa.d
|   |-- ti_Adchar.d
|   |-- ti_Ag.d
|   |-- ti_Aint.d
|   |-- ti_Along.d
|   |-- ti_Ashort.d
|   |-- ti_Aubyte.d
|   |-- ti_Auint.d
|   |-- ti_Aulong.d
|   |-- ti_Aushort.d
|   |-- ti_Awchar.d
|   |-- ti_C.d
|   |-- ti_byte.d
|   |-- ti_cdouble.d
|   |-- ti_cfloat.d
|   |-- ti_char.d
|   |-- ti_creal.d
|   |-- ti_dchar.d
|   |-- ti_delegate.d
|   |-- ti_double.d
|   |-- ti_extended.d
|   |-- ti_float.d
|   |-- ti_idouble.d
|   |-- ti_ifloat.d
|   |-- ti_int.d
|   |-- ti_ireal.d
|   |-- ti_long.d
|   |-- ti_ptr.d
|   |-- ti_real.d
|   |-- ti_short.d
|   |-- ti_ubyte.d
|   |-- ti_uint.d
|   |-- ti_ulong.d
|   |-- ti_ushort.d
|   `-- ti_wchar.d
|-- cmath2.d
|-- compiler.d
|-- complex.c
|-- conv.d
|-- crc32.d
|-- ctype.d
|-- dateparse.d
|-- deh.c
|-- deh2.d
|-- linux.mak
|-- math.d
|-- math2.d
|-- outbuffer.d
|-- qsort.d
|-- random.d
|-- regexp.d
|-- stdint.d
|-- stream.d
|-- string.d
|-- unittest.d
|-- uri.d
|-- utf.d
`-- win32.mak

7 directories, 103 files

##########################

would makefiles for this be a good thing?
would a conversion for existing source files be a good thing
(same type as the makePrivate I made) ?

Ant

Oct 30 2003

"Walter" <walter digitalmars.com> writes:

That looks mostly right. Conversion of source would be a bit of a pain, but
not too bad. I have a program that can do global search/replace across
files.

"Ant" <Ant_member pathlink.com> wrote in message
news:bnsadc$2mk7$1 digitaldaemon.com...
 In article <bnn9a0$1o09$1 digitaldaemon.com>, Walter says...
There have been a lot of good ideas and points made about this in the
discussions here. The upshot is there isn't a single right answer,
but there are a few clearly wrong ones <g>. So it's up to me to just pick
one of the right answers.


 Do you mean:

 ##########################

 std
 |-- c
 |   |-- process.d
 |   |-- stdio.d
 |   `-- stdlib.d
 |-- etc
 |-- internal
 |   |-- aaA.d
 |   |-- achar.d
 |   |-- adi.d
 |   |-- alloca.d
 |   |-- array.d
 |   |-- arraycast.d
 |   |-- arraycat.d
 |   |-- assert.d
 |   |-- cast.d
 |   |-- critical.c
 |   |-- dmain2.d
 |   |-- errno.c
 |   |-- gc.d
 |   |-- gc2
 |   |-- gcstats.d
 |   |-- intrinsic.d
 |   |-- invariant.d
 |   |-- llmath.d
 |   |-- mars.h
 |   |-- memset.d
 |   |-- minit.asm
 |   |-- moduleinit.d
 |   |-- monitor.c
 |   |-- obj.d
 |   |-- object.d
 |   |-- outofmemory.d
 |   |-- switch.d
 |   `-- switcherr.d
 |-- os
 |   |-- linux
 |   |   |-- linux.d
 |   |   `-- linuxextern.d
 |   |-- windows
 |   |   |-- com.d
 |   |   |-- iunknown.d
 |   |   |-- registry.d
 |   |   |-- syserror.d
 |   |   `-- windows.d
 |   |-- date.d
 |   |-- file.d
 |   |-- path.d
 |   |-- system.d
 |   |-- thread.d
 |   `-- time.d
 |-- typeinfo
 |   |-- ti_AC.d
 |   |-- ti_Aa.d
 |   |-- ti_Adchar.d
 |   |-- ti_Ag.d
 |   |-- ti_Aint.d
 |   |-- ti_Along.d
 |   |-- ti_Ashort.d
 |   |-- ti_Aubyte.d
 |   |-- ti_Auint.d
 |   |-- ti_Aulong.d
 |   |-- ti_Aushort.d
 |   |-- ti_Awchar.d
 |   |-- ti_C.d
 |   |-- ti_byte.d
 |   |-- ti_cdouble.d
 |   |-- ti_cfloat.d
 |   |-- ti_char.d
 |   |-- ti_creal.d
 |   |-- ti_dchar.d
 |   |-- ti_delegate.d
 |   |-- ti_double.d
 |   |-- ti_extended.d
 |   |-- ti_float.d
 |   |-- ti_idouble.d
 |   |-- ti_ifloat.d
 |   |-- ti_int.d
 |   |-- ti_ireal.d
 |   |-- ti_long.d
 |   |-- ti_ptr.d
 |   |-- ti_real.d
 |   |-- ti_short.d
 |   |-- ti_ubyte.d
 |   |-- ti_uint.d
 |   |-- ti_ulong.d
 |   |-- ti_ushort.d
 |   `-- ti_wchar.d
 |-- cmath2.d
 |-- compiler.d
 |-- complex.c
 |-- conv.d
 |-- crc32.d
 |-- ctype.d
 |-- dateparse.d
 |-- deh.c
 |-- deh2.d
 |-- linux.mak
 |-- math.d
 |-- math2.d
 |-- outbuffer.d
 |-- qsort.d
 |-- random.d
 |-- regexp.d
 |-- stdint.d
 |-- stream.d
 |-- string.d
 |-- unittest.d
 |-- uri.d
 |-- utf.d
 `-- win32.mak

 7 directories, 103 files

 ##########################

 would makefiles for this be a good thing?
 would a conversion for existing source files be a good thing
 (same type as the makePrivate I made) ?

 Ant

Oct 30 2003

Ant <Ant_member pathlink.com> writes:

In article <bnseuj$2t1h$2 digitaldaemon.com>, Walter says...
That looks mostly right. Conversion of source would be a bit of a pain, but
not too bad. I have a program that can do global search/replace across
files.


Just forgot to create the gc2 dir.
All gc2 stuff will go under std.internal.gc2 (?).

To convert existing sources I was thinking of
a makefile with something like:

FILES=$(wildcard *.d)
$(FILES):
  sed -e 's/import com;/import os\.windows\.com;/g' \
      $  > $(NEW_LOCATION)/$ 

(unless your program is better)
that worked to convert all "import" in phobos to "private import"

Ant

Oct 30 2003

"Walter" <walter digitalmars.com> writes:

I don't have sed, but yeah, something like that should cover about 90% of
the work. std.internal.gc is probably the right place for the gc
implementation.

"Ant" <Ant_member pathlink.com> wrote in message
news:bnshaa$30cd$1 digitaldaemon.com...
 In article <bnseuj$2t1h$2 digitaldaemon.com>, Walter says...
That looks mostly right. Conversion of source would be a bit of a pain,




not too bad. I have a program that can do global search/replace across
files.


 Just forgot to create the gc2 dir.
 All gc2 stuff will go under std.internal.gc2 (?).

 To convert existing sources I was thinking of
 a makefile with something like:

 FILES=$(wildcard *.d)
 $(FILES):
   sed -e 's/import com;/import os\.windows\.com;/g' \
       $  > $(NEW_LOCATION)/$ 

 (unless your program is better)
 that worked to convert all "import" in phobos to "private import"

 Ant

Oct 30 2003

"Charles Sanders" <sanders-consulting comcast.net> writes:

What program ?

Also , I keep hitting my head on the toStringz for std.c.X stuff, what about
a std.d.X that mirrors std.c and handles char []  and the like ?

C

"Walter" <walter digitalmars.com> wrote in message
news:bnseuj$2t1h$2 digitaldaemon.com...
 That looks mostly right. Conversion of source would be a bit of a pain,


 not too bad. I have a program that can do global search/replace across
 files.

 "Ant" <Ant_member pathlink.com> wrote in message
 news:bnsadc$2mk7$1 digitaldaemon.com...
 In article <bnn9a0$1o09$1 digitaldaemon.com>, Walter says...
There have been a lot of good ideas and points made about this in the
discussions here. The upshot is there isn't a single right answer,
but there are a few clearly wrong ones <g>. So it's up to me to just






one of the right answers.


 Do you mean:

 ##########################

 std
 |-- c
 |   |-- process.d
 |   |-- stdio.d
 |   `-- stdlib.d
 |-- etc
 |-- internal
 |   |-- aaA.d
 |   |-- achar.d
 |   |-- adi.d
 |   |-- alloca.d
 |   |-- array.d
 |   |-- arraycast.d
 |   |-- arraycat.d
 |   |-- assert.d
 |   |-- cast.d
 |   |-- critical.c
 |   |-- dmain2.d
 |   |-- errno.c
 |   |-- gc.d
 |   |-- gc2
 |   |-- gcstats.d
 |   |-- intrinsic.d
 |   |-- invariant.d
 |   |-- llmath.d
 |   |-- mars.h
 |   |-- memset.d
 |   |-- minit.asm
 |   |-- moduleinit.d
 |   |-- monitor.c
 |   |-- obj.d
 |   |-- object.d
 |   |-- outofmemory.d
 |   |-- switch.d
 |   `-- switcherr.d
 |-- os
 |   |-- linux
 |   |   |-- linux.d
 |   |   `-- linuxextern.d
 |   |-- windows
 |   |   |-- com.d
 |   |   |-- iunknown.d
 |   |   |-- registry.d
 |   |   |-- syserror.d
 |   |   `-- windows.d
 |   |-- date.d
 |   |-- file.d
 |   |-- path.d
 |   |-- system.d
 |   |-- thread.d
 |   `-- time.d
 |-- typeinfo
 |   |-- ti_AC.d
 |   |-- ti_Aa.d
 |   |-- ti_Adchar.d
 |   |-- ti_Ag.d
 |   |-- ti_Aint.d
 |   |-- ti_Along.d
 |   |-- ti_Ashort.d
 |   |-- ti_Aubyte.d
 |   |-- ti_Auint.d
 |   |-- ti_Aulong.d
 |   |-- ti_Aushort.d
 |   |-- ti_Awchar.d
 |   |-- ti_C.d
 |   |-- ti_byte.d
 |   |-- ti_cdouble.d
 |   |-- ti_cfloat.d
 |   |-- ti_char.d
 |   |-- ti_creal.d
 |   |-- ti_dchar.d
 |   |-- ti_delegate.d
 |   |-- ti_double.d
 |   |-- ti_extended.d
 |   |-- ti_float.d
 |   |-- ti_idouble.d
 |   |-- ti_ifloat.d
 |   |-- ti_int.d
 |   |-- ti_ireal.d
 |   |-- ti_long.d
 |   |-- ti_ptr.d
 |   |-- ti_real.d
 |   |-- ti_short.d
 |   |-- ti_ubyte.d
 |   |-- ti_uint.d
 |   |-- ti_ulong.d
 |   |-- ti_ushort.d
 |   `-- ti_wchar.d
 |-- cmath2.d
 |-- compiler.d
 |-- complex.c
 |-- conv.d
 |-- crc32.d
 |-- ctype.d
 |-- dateparse.d
 |-- deh.c
 |-- deh2.d
 |-- linux.mak
 |-- math.d
 |-- math2.d
 |-- outbuffer.d
 |-- qsort.d
 |-- random.d
 |-- regexp.d
 |-- stdint.d
 |-- stream.d
 |-- string.d
 |-- unittest.d
 |-- uri.d
 |-- utf.d
 `-- win32.mak

 7 directories, 103 files

 ##########################

 would makefiles for this be a good thing?
 would a conversion for existing source files be a good thing
 (same type as the makePrivate I made) ?

 Ant

Oct 31 2003

"Walter" <walter digitalmars.com> writes:

I'll include it (replace.exe) in the next release.

"Charles Sanders" <sanders-consulting comcast.net> wrote in message
news:bnu9tf$2sa9$1 digitaldaemon.com...
 What program ?

 Also , I keep hitting my head on the toStringz for std.c.X stuff, what


 a std.d.X that mirrors std.c and handles char []  and the like ?

 C

 "Walter" <walter digitalmars.com> wrote in message
 news:bnseuj$2t1h$2 digitaldaemon.com...
 That looks mostly right. Conversion of source would be a bit of a pain,


 not too bad. I have a program that can do global search/replace across
 files.

 "Ant" <Ant_member pathlink.com> wrote in message
 news:bnsadc$2mk7$1 digitaldaemon.com...
 In article <bnn9a0$1o09$1 digitaldaemon.com>, Walter says...
There have been a lot of good ideas and points made about this in the
discussions here. The upshot is there isn't a single right answer,
but there are a few clearly wrong ones <g>. So it's up to me to just






one of the right answers.


 Do you mean:

 ##########################

 std
 |-- c
 |   |-- process.d
 |   |-- stdio.d
 |   `-- stdlib.d
 |-- etc
 |-- internal
 |   |-- aaA.d
 |   |-- achar.d
 |   |-- adi.d
 |   |-- alloca.d
 |   |-- array.d
 |   |-- arraycast.d
 |   |-- arraycat.d
 |   |-- assert.d
 |   |-- cast.d
 |   |-- critical.c
 |   |-- dmain2.d
 |   |-- errno.c
 |   |-- gc.d
 |   |-- gc2
 |   |-- gcstats.d
 |   |-- intrinsic.d
 |   |-- invariant.d
 |   |-- llmath.d
 |   |-- mars.h
 |   |-- memset.d
 |   |-- minit.asm
 |   |-- moduleinit.d
 |   |-- monitor.c
 |   |-- obj.d
 |   |-- object.d
 |   |-- outofmemory.d
 |   |-- switch.d
 |   `-- switcherr.d
 |-- os
 |   |-- linux
 |   |   |-- linux.d
 |   |   `-- linuxextern.d
 |   |-- windows
 |   |   |-- com.d
 |   |   |-- iunknown.d
 |   |   |-- registry.d
 |   |   |-- syserror.d
 |   |   `-- windows.d
 |   |-- date.d
 |   |-- file.d
 |   |-- path.d
 |   |-- system.d
 |   |-- thread.d
 |   `-- time.d
 |-- typeinfo
 |   |-- ti_AC.d
 |   |-- ti_Aa.d
 |   |-- ti_Adchar.d
 |   |-- ti_Ag.d
 |   |-- ti_Aint.d
 |   |-- ti_Along.d
 |   |-- ti_Ashort.d
 |   |-- ti_Aubyte.d
 |   |-- ti_Auint.d
 |   |-- ti_Aulong.d
 |   |-- ti_Aushort.d
 |   |-- ti_Awchar.d
 |   |-- ti_C.d
 |   |-- ti_byte.d
 |   |-- ti_cdouble.d
 |   |-- ti_cfloat.d
 |   |-- ti_char.d
 |   |-- ti_creal.d
 |   |-- ti_dchar.d
 |   |-- ti_delegate.d
 |   |-- ti_double.d
 |   |-- ti_extended.d
 |   |-- ti_float.d
 |   |-- ti_idouble.d
 |   |-- ti_ifloat.d
 |   |-- ti_int.d
 |   |-- ti_ireal.d
 |   |-- ti_long.d
 |   |-- ti_ptr.d
 |   |-- ti_real.d
 |   |-- ti_short.d
 |   |-- ti_ubyte.d
 |   |-- ti_uint.d
 |   |-- ti_ulong.d
 |   |-- ti_ushort.d
 |   `-- ti_wchar.d
 |-- cmath2.d
 |-- compiler.d
 |-- complex.c
 |-- conv.d
 |-- crc32.d
 |-- ctype.d
 |-- dateparse.d
 |-- deh.c
 |-- deh2.d
 |-- linux.mak
 |-- math.d
 |-- math2.d
 |-- outbuffer.d
 |-- qsort.d
 |-- random.d
 |-- regexp.d
 |-- stdint.d
 |-- stream.d
 |-- string.d
 |-- unittest.d
 |-- uri.d
 |-- utf.d
 `-- win32.mak

 7 directories, 103 files

 ##########################

 would makefiles for this be a good thing?
 would a conversion for existing source files be a good thing
 (same type as the makePrivate I made) ?

 Ant

Oct 31 2003

"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:

Is it written in D?

"Walter" <walter digitalmars.com> wrote in message
news:bnun89$dpa$2 digitaldaemon.com...
 I'll include it (replace.exe) in the next release.

 "Charles Sanders" <sanders-consulting comcast.net> wrote in message
 news:bnu9tf$2sa9$1 digitaldaemon.com...
 What program ?

 Also , I keep hitting my head on the toStringz for std.c.X stuff, what


 a std.d.X that mirrors std.c and handles char []  and the like ?

 C

 "Walter" <walter digitalmars.com> wrote in message
 news:bnseuj$2t1h$2 digitaldaemon.com...
 That looks mostly right. Conversion of source would be a bit of a






 but
 not too bad. I have a program that can do global search/replace across
 files.

 "Ant" <Ant_member pathlink.com> wrote in message
 news:bnsadc$2mk7$1 digitaldaemon.com...
 In article <bnn9a0$1o09$1 digitaldaemon.com>, Walter says...
There have been a lot of good ideas and points made about this in










discussions here. The upshot is there isn't a single right answer,
but there are a few clearly wrong ones <g>. So it's up to me to










 pick
one of the right answers.


 Do you mean:

 ##########################

 std
 |-- c
 |   |-- process.d
 |   |-- stdio.d
 |   `-- stdlib.d
 |-- etc
 |-- internal
 |   |-- aaA.d
 |   |-- achar.d
 |   |-- adi.d
 |   |-- alloca.d
 |   |-- array.d
 |   |-- arraycast.d
 |   |-- arraycat.d
 |   |-- assert.d
 |   |-- cast.d
 |   |-- critical.c
 |   |-- dmain2.d
 |   |-- errno.c
 |   |-- gc.d
 |   |-- gc2
 |   |-- gcstats.d
 |   |-- intrinsic.d
 |   |-- invariant.d
 |   |-- llmath.d
 |   |-- mars.h
 |   |-- memset.d
 |   |-- minit.asm
 |   |-- moduleinit.d
 |   |-- monitor.c
 |   |-- obj.d
 |   |-- object.d
 |   |-- outofmemory.d
 |   |-- switch.d
 |   `-- switcherr.d
 |-- os
 |   |-- linux
 |   |   |-- linux.d
 |   |   `-- linuxextern.d
 |   |-- windows
 |   |   |-- com.d
 |   |   |-- iunknown.d
 |   |   |-- registry.d
 |   |   |-- syserror.d
 |   |   `-- windows.d
 |   |-- date.d
 |   |-- file.d
 |   |-- path.d
 |   |-- system.d
 |   |-- thread.d
 |   `-- time.d
 |-- typeinfo
 |   |-- ti_AC.d
 |   |-- ti_Aa.d
 |   |-- ti_Adchar.d
 |   |-- ti_Ag.d
 |   |-- ti_Aint.d
 |   |-- ti_Along.d
 |   |-- ti_Ashort.d
 |   |-- ti_Aubyte.d
 |   |-- ti_Auint.d
 |   |-- ti_Aulong.d
 |   |-- ti_Aushort.d
 |   |-- ti_Awchar.d
 |   |-- ti_C.d
 |   |-- ti_byte.d
 |   |-- ti_cdouble.d
 |   |-- ti_cfloat.d
 |   |-- ti_char.d
 |   |-- ti_creal.d
 |   |-- ti_dchar.d
 |   |-- ti_delegate.d
 |   |-- ti_double.d
 |   |-- ti_extended.d
 |   |-- ti_float.d
 |   |-- ti_idouble.d
 |   |-- ti_ifloat.d
 |   |-- ti_int.d
 |   |-- ti_ireal.d
 |   |-- ti_long.d
 |   |-- ti_ptr.d
 |   |-- ti_real.d
 |   |-- ti_short.d
 |   |-- ti_ubyte.d
 |   |-- ti_uint.d
 |   |-- ti_ulong.d
 |   |-- ti_ushort.d
 |   `-- ti_wchar.d
 |-- cmath2.d
 |-- compiler.d
 |-- complex.c
 |-- conv.d
 |-- crc32.d
 |-- ctype.d
 |-- dateparse.d
 |-- deh.c
 |-- deh2.d
 |-- linux.mak
 |-- math.d
 |-- math2.d
 |-- outbuffer.d
 |-- qsort.d
 |-- random.d
 |-- regexp.d
 |-- stdint.d
 |-- stream.d
 |-- string.d
 |-- unittest.d
 |-- uri.d
 |-- utf.d
 `-- win32.mak

 7 directories, 103 files

 ##########################

 would makefiles for this be a good thing?
 would a conversion for existing source files be a good thing
 (same type as the makePrivate I made) ?

 Ant

Oct 31 2003

"Walter" <walter digitalmars.com> writes:

I wrote it eons ago, so it's in C. It's a completely trivial program, but I
find myself using it all the time. I'll post the source here. I think a D
version would be an improvement; anyone want to give it a go?

"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:bnuo8v$f68$1 digitaldaemon.com...
 Is it written in D?

 "Walter" <walter digitalmars.com> wrote in message
 news:bnun89$dpa$2 digitaldaemon.com...
 I'll include it (replace.exe) in the next release.




-------------------------------------------------------------------
/*_ replace.c   Mon Nov 21 1988   Modified by: Walter Bright */

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <dos.h>

EXPAND_WILDCARDS;

#include "filespec.h"

#define STRMAX 80
char instr[STRMAX + 1], newstr[STRMAX + 1], oldstr[STRMAX + 1];
char *ptrd, *ptri, *strptr;
FILE *fpin, *fpout;
unsigned long int strcount;
int cc;

main(argc, argv)
int argc;
char *argv[];
{
  int i;
  int result = 0;
  unsigned len;
  char *sourcename,*backupname;

  if(argc < 2)
  {
    fputs ("Usage:\n\treplace filename(s)", stdout);
    exit (1);
  }
  fputs("String to be replaced (80 characters max)?\n",stdout);
  fgets(oldstr, STRMAX + 1, stdin);
  fputs("Replacement string?\n", stdout);
  fgets(newstr, STRMAX + 1, stdin);

  /* Kill the CR and LF at the end of the strings. */
  for(ptrd = newstr; *ptrd; ptrd++)
  {
    if(*ptrd == '\r' || *ptrd == '\n' )
      *ptrd = '\0';
  }
  for(ptrd = oldstr; *ptrd; ptrd++)
  {
    if(*ptrd == '\r' || *ptrd == '\n')
      *ptrd = '\0';
  }
  strcount = 0L;
  for (i = 1; i < argc; i++)
  { char *tempname;

    sourcename = argv[i];
    fputs("File ",stdout);
    fputs(sourcename,stdout);
    fputc('\n',stdout);

    tempname = filespecforceext(sourcename,"tmp");
    backupname = filespecforceext(sourcename,"bak");

    fpout = fopen(tempname, "w");
    if (!fpout)
    { fputs("cannot open ",stdout);
 fputs(sourcename, stdout);
 fputc('\n',stdout);
 continue;
    }
    fpin = fopen(sourcename, "r");
    if (!fpin)
    { fputs("cannot open ",stdout);
 fputs(backupname, stdout);
 fputc('\n',stdout);
 fclose (fpout);
 continue;
    }
    if (replace())
    {
 unlink (backupname);   /* Delete any existing backup. */
 if (rename (sourcename, backupname) == -1 ||
     rename (tempname, sourcename) == -1)
 {
   fputs ("File rename error with file '", stdout);
   fputs (sourcename, stdout);
   fputs ("'\n", stdout);
 }
    }
    else
    { fputs("No changes\n",stdout);
 unlink(tempname);
    }
    free(backupname);
    free(tempname);
    outascii (strcount);
    fputs (" strings replaced\n", stdout);
    strcount = 0L;
  }
  return result;
}

outascii (n)
unsigned long int n;
{
  char outstr[16], *ptr;
  outstr[15] = '\0';
  ptr = &outstr[14];
  do
  {
    *ptr-- = (char)('0' + n % 10);
    n /= 10;
  } while (n);
  fputs (ptr + 1, stdout);
}

/*******************************
 * Does the actual replacement.
 * Returns:
 * 0 error or no changes made
 */

int replace ()
{
  int sflag;

  if (*oldstr) /* If there is a char, search for strings. */
  {
    for (*instr = '\0', sflag= strcheck(); sflag >= 0; sflag= strcheck() )
    {
/* Compare the two strings for a match.  If it doesn't fully match then
shift
the input string over and continue (case 0).  If it fully matches then
replace
the string (case 1).  If EOF occurs then exit (case -1). */

      if (sflag)
      {
        *instr = '\0';
        if (fputs (newstr, fpout) == EOF)
 {   fputs("Error writing file\n",stdout);
     goto err;
 }
        strcount++;
      }
      else
      {
        if (putc (*instr, fpout) == EOF)
 {   fputs("Error writing file\n",stdout);
     goto err;
 }
        /* Shift the string. */
        for (strptr = instr, ptri = instr + 1; *ptri; *strptr++ = *ptri++);
        *strptr = '\0';
      }
    }
  }
    if (fclose(fpin) == EOF || fclose(fpout) == EOF)
    { fputs("Error closing files\n",stdout);
 goto err;
    }
    return strcount != 0;

err:
    return 0;
}

/****************************************
 * Inputs characters to the input string, checks the input string for a
match
 * against the dead string.
 */

strcheck()
{
  ptrd = oldstr;
  ptri = instr;
  while( *ptri == *ptrd && *ptrd != '\0' )
  {
    ptrd++;
    ptri++;
  }
  if( *ptri == '\0' && *ptrd != '\0' )
  {
    while( (cc = getc( fpin )) != EOF && cc == *ptrd && *++ptrd != '\0' )
      *ptri++ = cc;
    if( cc == EOF )
    {
      *ptri++ = '\0';
      return -1;
    }
    *ptri++ = cc;
    *ptri++ = '\0';
  }
  if( *ptrd != '\0' )
    return 0; /* Doesn't fully match the input string. */
  else
    return 1;  /* Full match. */
}

#define MEM_H
#define mem_malloc malloc
#define mem_strdup strdup
#define mem_free free
#define mem_calloc(n) calloc(n,1)

#include "filespec.c"

Oct 31 2003

"Charles Sanders" <sanders-consulting comcast.net> writes:

Sure ill go for it, is their an ETA for .75 ?  I ask because of the private
imports, and some other changes requested for phobos that we'd like to
implement, but if .75 is available soon ill just wait.

C

"Walter" <walter digitalmars.com> wrote in message
news:bnupcl$gjs$1 digitaldaemon.com...
 I wrote it eons ago, so it's in C. It's a completely trivial program, but


 find myself using it all the time. I'll post the source here. I think a D
 version would be an improvement; anyone want to give it a go?

 "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
 news:bnuo8v$f68$1 digitaldaemon.com...
 Is it written in D?

 "Walter" <walter digitalmars.com> wrote in message
 news:bnun89$dpa$2 digitaldaemon.com...
 I'll include it (replace.exe) in the next release.




 -------------------------------------------------------------------
 /*_ replace.c   Mon Nov 21 1988   Modified by: Walter Bright */

 #include <stdio.h>
 #include <string.h>
 #include <stdlib.h>
 #include <dos.h>

 EXPAND_WILDCARDS;

 #include "filespec.h"

 #define STRMAX 80
 char instr[STRMAX + 1], newstr[STRMAX + 1], oldstr[STRMAX + 1];
 char *ptrd, *ptri, *strptr;
 FILE *fpin, *fpout;
 unsigned long int strcount;
 int cc;

 main(argc, argv)
 int argc;
 char *argv[];
 {
   int i;
   int result = 0;
   unsigned len;
   char *sourcename,*backupname;

   if(argc < 2)
   {
     fputs ("Usage:\n\treplace filename(s)", stdout);
     exit (1);
   }
   fputs("String to be replaced (80 characters max)?\n",stdout);
   fgets(oldstr, STRMAX + 1, stdin);
   fputs("Replacement string?\n", stdout);
   fgets(newstr, STRMAX + 1, stdin);

   /* Kill the CR and LF at the end of the strings. */
   for(ptrd = newstr; *ptrd; ptrd++)
   {
     if(*ptrd == '\r' || *ptrd == '\n' )
       *ptrd = '\0';
   }
   for(ptrd = oldstr; *ptrd; ptrd++)
   {
     if(*ptrd == '\r' || *ptrd == '\n')
       *ptrd = '\0';
   }
   strcount = 0L;
   for (i = 1; i < argc; i++)
   { char *tempname;

     sourcename = argv[i];
     fputs("File ",stdout);
     fputs(sourcename,stdout);
     fputc('\n',stdout);

     tempname = filespecforceext(sourcename,"tmp");
     backupname = filespecforceext(sourcename,"bak");

     fpout = fopen(tempname, "w");
     if (!fpout)
     { fputs("cannot open ",stdout);
  fputs(sourcename, stdout);
  fputc('\n',stdout);
  continue;
     }
     fpin = fopen(sourcename, "r");
     if (!fpin)
     { fputs("cannot open ",stdout);
  fputs(backupname, stdout);
  fputc('\n',stdout);
  fclose (fpout);
  continue;
     }
     if (replace())
     {
  unlink (backupname);   /* Delete any existing backup. */
  if (rename (sourcename, backupname) == -1 ||
      rename (tempname, sourcename) == -1)
  {
    fputs ("File rename error with file '", stdout);
    fputs (sourcename, stdout);
    fputs ("'\n", stdout);
  }
     }
     else
     { fputs("No changes\n",stdout);
  unlink(tempname);
     }
     free(backupname);
     free(tempname);
     outascii (strcount);
     fputs (" strings replaced\n", stdout);
     strcount = 0L;
   }
   return result;
 }

 outascii (n)
 unsigned long int n;
 {
   char outstr[16], *ptr;
   outstr[15] = '\0';
   ptr = &outstr[14];
   do
   {
     *ptr-- = (char)('0' + n % 10);
     n /= 10;
   } while (n);
   fputs (ptr + 1, stdout);
 }

 /*******************************
  * Does the actual replacement.
  * Returns:
  * 0 error or no changes made
  */

 int replace ()
 {
   int sflag;

   if (*oldstr) /* If there is a char, search for strings. */
   {
     for (*instr = '\0', sflag= strcheck(); sflag >= 0; sflag= strcheck() )
     {
 /* Compare the two strings for a match.  If it doesn't fully match then
 shift
 the input string over and continue (case 0).  If it fully matches then
 replace
 the string (case 1).  If EOF occurs then exit (case -1). */

       if (sflag)
       {
         *instr = '\0';
         if (fputs (newstr, fpout) == EOF)
  {   fputs("Error writing file\n",stdout);
      goto err;
  }
         strcount++;
       }
       else
       {
         if (putc (*instr, fpout) == EOF)
  {   fputs("Error writing file\n",stdout);
      goto err;
  }
         /* Shift the string. */
         for (strptr = instr, ptri = instr + 1; *ptri; *strptr++ =


         *strptr = '\0';
       }
     }
   }
     if (fclose(fpin) == EOF || fclose(fpout) == EOF)
     { fputs("Error closing files\n",stdout);
  goto err;
     }
     return strcount != 0;

 err:
     return 0;
 }

 /****************************************
  * Inputs characters to the input string, checks the input string for a
 match
  * against the dead string.
  */

 strcheck()
 {
   ptrd = oldstr;
   ptri = instr;
   while( *ptri == *ptrd && *ptrd != '\0' )
   {
     ptrd++;
     ptri++;
   }
   if( *ptri == '\0' && *ptrd != '\0' )
   {
     while( (cc = getc( fpin )) != EOF && cc == *ptrd && *++ptrd != '\0' )
       *ptri++ = cc;
     if( cc == EOF )
     {
       *ptri++ = '\0';
       return -1;
     }
     *ptri++ = cc;
     *ptri++ = '\0';
   }
   if( *ptrd != '\0' )
     return 0; /* Doesn't fully match the input string. */
   else
     return 1;  /* Full match. */
 }

 #define MEM_H
 #define mem_malloc malloc
 #define mem_strdup strdup
 #define mem_free free
 #define mem_calloc(n) calloc(n,1)

 #include "filespec.c"

Oct 31 2003

"Walter" <walter digitalmars.com> writes:

"Charles Sanders" <sanders-consulting comcast.net> wrote in message
news:bnv2il$t3j$1 digitaldaemon.com...
 Sure ill go for it, is their an ETA for .75 ?  I ask because of the


 imports, and some other changes requested for phobos that we'd like to
 implement, but if .75 is available soon ill just wait.


I hope to get it done within a week.

Oct 31 2003

"Charles Sanders" <sanders-consulting comcast.net> writes:

1988 lol!  man that is old. ( puttin on I think we're alone now : Tiffany )

C

"Walter" <walter digitalmars.com> wrote in message
news:bnupcl$gjs$1 digitaldaemon.com...
 I wrote it eons ago, so it's in C. It's a completely trivial program, but


 find myself using it all the time. I'll post the source here. I think a D
 version would be an improvement; anyone want to give it a go?

 "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
 news:bnuo8v$f68$1 digitaldaemon.com...
 Is it written in D?

 "Walter" <walter digitalmars.com> wrote in message
 news:bnun89$dpa$2 digitaldaemon.com...
 I'll include it (replace.exe) in the next release.




 -------------------------------------------------------------------
 /*_ replace.c   Mon Nov 21 1988   Modified by: Walter Bright */

 #include <stdio.h>
 #include <string.h>
 #include <stdlib.h>
 #include <dos.h>

 EXPAND_WILDCARDS;

 #include "filespec.h"

 #define STRMAX 80
 char instr[STRMAX + 1], newstr[STRMAX + 1], oldstr[STRMAX + 1];
 char *ptrd, *ptri, *strptr;
 FILE *fpin, *fpout;
 unsigned long int strcount;
 int cc;

 main(argc, argv)
 int argc;
 char *argv[];
 {
   int i;
   int result = 0;
   unsigned len;
   char *sourcename,*backupname;

   if(argc < 2)
   {
     fputs ("Usage:\n\treplace filename(s)", stdout);
     exit (1);
   }
   fputs("String to be replaced (80 characters max)?\n",stdout);
   fgets(oldstr, STRMAX + 1, stdin);
   fputs("Replacement string?\n", stdout);
   fgets(newstr, STRMAX + 1, stdin);

   /* Kill the CR and LF at the end of the strings. */
   for(ptrd = newstr; *ptrd; ptrd++)
   {
     if(*ptrd == '\r' || *ptrd == '\n' )
       *ptrd = '\0';
   }
   for(ptrd = oldstr; *ptrd; ptrd++)
   {
     if(*ptrd == '\r' || *ptrd == '\n')
       *ptrd = '\0';
   }
   strcount = 0L;
   for (i = 1; i < argc; i++)
   { char *tempname;

     sourcename = argv[i];
     fputs("File ",stdout);
     fputs(sourcename,stdout);
     fputc('\n',stdout);

     tempname = filespecforceext(sourcename,"tmp");
     backupname = filespecforceext(sourcename,"bak");

     fpout = fopen(tempname, "w");
     if (!fpout)
     { fputs("cannot open ",stdout);
  fputs(sourcename, stdout);
  fputc('\n',stdout);
  continue;
     }
     fpin = fopen(sourcename, "r");
     if (!fpin)
     { fputs("cannot open ",stdout);
  fputs(backupname, stdout);
  fputc('\n',stdout);
  fclose (fpout);
  continue;
     }
     if (replace())
     {
  unlink (backupname);   /* Delete any existing backup. */
  if (rename (sourcename, backupname) == -1 ||
      rename (tempname, sourcename) == -1)
  {
    fputs ("File rename error with file '", stdout);
    fputs (sourcename, stdout);
    fputs ("'\n", stdout);
  }
     }
     else
     { fputs("No changes\n",stdout);
  unlink(tempname);
     }
     free(backupname);
     free(tempname);
     outascii (strcount);
     fputs (" strings replaced\n", stdout);
     strcount = 0L;
   }
   return result;
 }

 outascii (n)
 unsigned long int n;
 {
   char outstr[16], *ptr;
   outstr[15] = '\0';
   ptr = &outstr[14];
   do
   {
     *ptr-- = (char)('0' + n % 10);
     n /= 10;
   } while (n);
   fputs (ptr + 1, stdout);
 }

 /*******************************
  * Does the actual replacement.
  * Returns:
  * 0 error or no changes made
  */

 int replace ()
 {
   int sflag;

   if (*oldstr) /* If there is a char, search for strings. */
   {
     for (*instr = '\0', sflag= strcheck(); sflag >= 0; sflag= strcheck() )
     {
 /* Compare the two strings for a match.  If it doesn't fully match then
 shift
 the input string over and continue (case 0).  If it fully matches then
 replace
 the string (case 1).  If EOF occurs then exit (case -1). */

       if (sflag)
       {
         *instr = '\0';
         if (fputs (newstr, fpout) == EOF)
  {   fputs("Error writing file\n",stdout);
      goto err;
  }
         strcount++;
       }
       else
       {
         if (putc (*instr, fpout) == EOF)
  {   fputs("Error writing file\n",stdout);
      goto err;
  }
         /* Shift the string. */
         for (strptr = instr, ptri = instr + 1; *ptri; *strptr++ =


         *strptr = '\0';
       }
     }
   }
     if (fclose(fpin) == EOF || fclose(fpout) == EOF)
     { fputs("Error closing files\n",stdout);
  goto err;
     }
     return strcount != 0;

 err:
     return 0;
 }

 /****************************************
  * Inputs characters to the input string, checks the input string for a
 match
  * against the dead string.
  */

 strcheck()
 {
   ptrd = oldstr;
   ptri = instr;
   while( *ptri == *ptrd && *ptrd != '\0' )
   {
     ptrd++;
     ptri++;
   }
   if( *ptri == '\0' && *ptrd != '\0' )
   {
     while( (cc = getc( fpin )) != EOF && cc == *ptrd && *++ptrd != '\0' )
       *ptri++ = cc;
     if( cc == EOF )
     {
       *ptri++ = '\0';
       return -1;
     }
     *ptri++ = cc;
     *ptri++ = '\0';
   }
   if( *ptrd != '\0' )
     return 0; /* Doesn't fully match the input string. */
   else
     return 1;  /* Full match. */
 }

 #define MEM_H
 #define mem_malloc malloc
 #define mem_strdup strdup
 #define mem_free free
 #define mem_calloc(n) calloc(n,1)

 #include "filespec.c"

Oct 31 2003

"Andrew Edwards" <edwardsac spamfreeusa.com> writes:

"Charles Sanders" <sanders-consulting comcast.net> wrote in message
news:bnv2su$ths$1 digitaldaemon.com...
 1988 lol!  man that is old. ( puttin on I think we're alone now :


 C

Oct 31 2003

"Walter" <walter digitalmars.com> writes:

"Charles Sanders" <sanders-consulting comcast.net> wrote in message
news:bnv2su$ths$1 digitaldaemon.com...
 1988 lol!  man that is old. ( puttin on I think we're alone now :



If you want to see some really old stuff I wrote, check out
www.classicempire.com <g>. I think some of my code has wound up in the
PDP-10 museum.

Oct 31 2003

Ant <Ant_member pathlink.com> writes:

In article <bnsadc$2mk7$1 digitaldaemon.com>, Ant says...
std
|-- c
|   |-- process.d
|   |-- stdio.d
|   `-- stdlib.d
|-- etc
|-- internal
|   |-- aaA.d
|   |-- achar.d
|   |-- adi.d
|   |-- alloca.d
|   |-- array.d


So, I made a script to move the lib files to the new structure.
I started to split the linux.mak
and I'm planing to create a couple of makefiles (or scripts) to:
- change the module declarations.
- change the import statments (should work both for the lib and apps)

Please stop me if it's not usefull!

All this on linux. I guess most of the conversions can be run
on linux and then the windows.mak would be easy to change 
either from the old version or the new linux version (?).
windows users without make or sed are doomed as they will have to
convert their applications some other way.

I don't know if it possible to have a phobos set of files with just
the import statments - for instance phobos/string.d would be just:
/*public*/ import std.string;

that would keep things going for existing applications.

BTW are we going to make all imports on the lib "private"?
(I already posted a makefile that does that)

Ant

Oct 31 2003

"Walter" <walter digitalmars.com> writes:

"Ant" <Ant_member pathlink.com> wrote in message
news:bnu9fa$2roo$1 digitaldaemon.com...
 In article <bnsadc$2mk7$1 digitaldaemon.com>, Ant says...
std
|-- c
|   |-- process.d
|   |-- stdio.d
|   `-- stdlib.d
|-- etc
|-- internal
|   |-- aaA.d
|   |-- achar.d
|   |-- adi.d
|   |-- alloca.d
|   |-- array.d


 So, I made a script to move the lib files to the new structure.
 I started to split the linux.mak
 and I'm planing to create a couple of makefiles (or scripts) to:
 - change the module declarations.
 - change the import statments (should work both for the lib and apps)

 Please stop me if it's not usefull!


I've already done most of it!

 All this on linux. I guess most of the conversions can be run
 on linux and then the windows.mak would be easy to change
 either from the old version or the new linux version (?).
 windows users without make or sed are doomed as they will have to
 convert their applications some other way.

 I don't know if it possible to have a phobos set of files with just
 the import statments - for instance phobos/string.d would be just:
 /*public*/ import std.string;

 that would keep things going for existing applications.


That might be a good idea. On the other hand, it just delays the inevitable
<g>.

 BTW are we going to make all imports on the lib "private"?
 (I already posted a makefile that does that)


Yes.

Oct 31 2003

Ant <Ant_member pathlink.com> writes:

In article <bnun8a$dpa$3 digitaldaemon.com>, Walter says...
"Ant" <Ant_member pathlink.com> wrote in message
news:bnu9fa$2roo$1 digitaldaemon.com...
 In article <bnsadc$2mk7$1 digitaldaemon.com>, Ant says...
std
|-- c
|   |-- process.d
|   |-- stdio.d
|   `-- stdlib.d
|-- etc
|-- internal
|   |-- aaA.d
|   |-- achar.d
|   |-- adi.d
|   |-- alloca.d
|   |-- array.d


 So, I made a script to move the lib files to the new structure.
 I started to split the linux.mak
 and I'm planing to create a couple of makefiles (or scripts) to:
 - change the module declarations.
 - change the import statments (should work both for the lib and apps)

 Please stop me if it's not usefull!


I've already done most of it!


good.
(But why didn't you ask here? Anybody could to that.)

Ant

Oct 31 2003

D Programming

C/C++ Programming

Other

D - Library naming convention