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,
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
> >
> >
>
>

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

Good.

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

... 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
2
> is
> > just as valid as 3.
>
> I think we're misunderstanding each other, then, because I am in full agreement with you there!

Maybe

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

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

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.

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
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,
> 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
> > >
> > >
> >
> >
>
>

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

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

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
> 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,
> > 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
> > > >
> > > >
> > >
> > >
> >
> >
>
>

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

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