Hello All ! I'm newbie in D. Reading sections "Modules" in specs I've realized, that any time I want to use any D library I need a full source of that library, not just

compiled .o file and header file as in C/C++. Am I right ? Is it right behavior ?

One more question: it seems that I can use printf even if I do not import any modules. Does it means that printf is language feature or does compiler implicitly import some libraries ?

Vladimir wrote:

> I'm newbie in D.

You might want to check out the new digitalmars.D.learn newsgroup too ?

> Reading sections "Modules" in specs I've realized, that any  time I want to use any D library I need a full source of that library, not just
> compiled .o file and header file as in C/C++. Am I right ? Is it right behavior ? 

That is the default behaviour, but you can usually use the D
libraries by providing a static library and the "import modules"

These look the same as the regular modules, but without the code
(i.e. the { ... } blocks have just been replaced with a simple ; }


Linking between systems and versions is about as much as fun as in C++,
so you might want to consider "extern(C)", and also no (external) GC...

Hopefully things shouldn't be in as much flux in the future, as now.

> One more question: it seems that I can use printf even if I do not import any modules. Does it means that printf is language feature or does compiler implicitly import some libraries ? 

printf lives in the std.c.stdio module, it has just been added
to the main object module "while debugging the Phobos library".

If you can, you should be using std.stdio.writef instead of it ?

--anders

>> I'm newbie in D.
>You might want to check out the new digitalmars.D.learn newsgroup too ?
Thanks for suggestion, I've just overlooked link to it.

>Linking between systems and versions is about as much as fun as in C++,
Yes, but following some (restrictive and complicated) rules one can keep C++ library binary compitable. When this rules becomes too restrictive it's good time to redesign the library, which almost surely will break even source-level compatibility.

>so you might want to consider "extern(C)", and also no (external) GC...
BTW, is GC somehow customizable ? Can I replace default GC by my own one ? And, is GC fully run-time system, or does it uses some compile-time predictions ?

>Hopefully things shouldn't be in as much flux in the future, as now.
Page about ABI in specs says almost nothing. Are there some work to make some standard ABI ? Are that ever possible ? Features such as properties, auto-virtual functions, RAII can make standartization very hard.

>If you can, you should be using std.stdio.writef instead of it ?
All those seems to be type-unsafe. Are there something like C++ cin/cout ?

Vladimir wrote:

>>so you might want to consider "extern(C)", and also no (external) GC... 
> 
> BTW, is GC somehow customizable ? Can I replace default GC by my own one ? 

You can replace the garbage collector by hacking the library sources.

>>If you can, you should be using std.stdio.writef instead of it ? 
> 
> All those seems to be type-unsafe.

They do check the type of the parameter, since that is available in D...

> Are there something like C++ cin/cout ? 

Yes, you can use the Reader/Writer classes under the Mango Tree:
http://svn.dsource.org/svn/projects/mango/trunk/doc/html/classReader.html
http://svn.dsource.org/svn/projects/mango/trunk/doc/html/classWriter.html

--anders

>> BTW, is GC somehow customizable ? Can I replace default GC by my own one ?
>You can replace the garbage collector by hacking the library sources.
So GC is fully in library ? Compiler are not involved ?

>>>If you can, you should be using std.stdio.writef instead of it ?
>> All those seems to be type-unsafe.
>They do check the type of the parameter, since that is available in D...
I meant compile-time type-safe.

>> Are there something like C++ cin/cout ?
>Yes, you can use the Reader/Writer classes under the Mango Tree: http://svn.dsource.org/svn/projects/mango/trunk/doc/html/classReader.html http://svn.dsource.org/svn/projects/mango/trunk/doc/html/classWriter.html
Thanks a lot for suggestion.

Again, thanks for your replies.

Vladimir wrote:

>>You can replace the garbage collector by hacking the library sources.  
> 
> So GC is fully in library ? Compiler are not involved ? 

It has been replaced by others, both with other GC and with malloc.
If you search around, you can probably find some more details...

I am using an open source D compiler (GDC), so it's not an issue.

>>They do check the type of the parameter, since that is available in D...  
> 
> I meant compile-time type-safe.  

Let's call it semi-safe :-)

(You probably won't like that "readf" uses pointers either, then?)

--anders

>>If you can, you should be using std.stdio.writef instead of it ?
> All those seems to be type-unsafe. Are there something like C++ cin/cout ?

writef and writefln are type-safe. You are probably thinking of printf, which is not type-safe.

"Vladimir" <Vladimir_member@pathlink.com> wrote in message news:d2e785$1241$1@digitaldaemon.com...
>>> BTW, is GC somehow customizable ? Can I replace default GC by my own one ?
>>You can replace the garbage collector by hacking the library sources.
> So GC is fully in library ? Compiler are not involved ?
>
>>>>If you can, you should be using std.stdio.writef instead of it ?
>>> All those seems to be type-unsafe.
>>They do check the type of the parameter, since that is available in D...
> I meant compile-time type-safe.

What do you mean by compile-time type-safe? Note one can run
writef("hello ",10," there ",3.456)
if you don't need any formatting control. The D version is just as safe as
cout << "hello " << 10 << " there " << 3.456
I do agree that the D version checks types at run-time but that affects
performance, not safety. Is there an example you have in mind?

-Ben

In article <d2e8dj$13lg$1@digitaldaemon.com>, Ben Hinkle says...
>>>> BTW, is GC somehow customizable ? Can I replace default GC by my own one ?
>>>You can replace the garbage collector by hacking the library sources.
>> So GC is fully in library ? Compiler are not involved ?
>> 
>>>>>If you can, you should be using std.stdio.writef instead of it ?
>>>> All those seems to be type-unsafe.
>>>They do check the type of the parameter, since that is available in D...
>> I meant compile-time type-safe.
> 
>What do you mean by compile-time type-safe? Note one can run writef("hello ",10," there ",3.456) if you don't need any formatting control. The D version is just as safe as cout << "hello " << 10 << " there " << 3.456 I do agree that the D version checks types at run-time but that affects performance, not safety. Is there an example you have in mind?
OK, it's good for built-in types. But can I extend it in such way, that expressions like writef("my class: ", my_class_instance) work as expected ? In C++ extensibility is a grate benefit of using cout instead of printf.

Vladimir wrote:

> OK, it's good for built-in types. But can I extend it in such way, that expressions like writef("my class: ", my_class_instance) work as expected ? In  C++ extensibility is a grate benefit of using cout instead of printf. 

You can override "char[] toString();", if that is what you mean here ?

--anders