Questions about D

[Robert Fraser]

FireLancer wrote:
> Jarrett Billingsley Wrote:
> 
>> "Bill Baxter" <dnewsgroup at billbaxter.com> wrote in message 
>> news:g14r0u$nf0$1 at digitalmars.com...
>>
>>> Maybe it's supposed to have that effect, but currently at least it does 
>>> not insulate you from namespace clashes.  Wasn't that how this 
>>> conversation began?
>> But if you make a symbol private, build it as a lib, and export the .di, the 
>> private symbol should not appear in the .di file. 
>>
>>
> 
> So in D it only looks at what is defined in the .di file unlike c++ which goes to the lib it's self (I'd assume the linker looks there?) to see whats there and thus finds functions you did not want to be avaible externaly and clashes.
> 
> So I can have a function that avaible within the static lib but not ouside the lib using .di files?
> 
> eg say sound.d and music.d use functions from in audio.d to build a static libary audio.lib
> 
> If I only put the functions from sound.d and music.d into a .di file then the user only sees those not the underlying functions that make it work and also if the user creats a function with the same name as one of these "hidden" functions say "CreateSecondaryBuffer()" they won't get linker errors.

Well, there needs to be a 1:1 ratio of .d files and .di files since each 
.d _OR_ .di file (one or the other) represents a module. So if you're 
making a closed-source lib, you compile using the .d files. Then you put 
the definitions of what you want into the .di file (or let the compiler 
auto-generate it).

There WILL be linker errors if the user creates a another function with 
exact same fully-qualified name, whether the function appears in the .di 
or not. But if they're using your library, that probably won't happen. 
So if you have:

---
module firelancer.audio.music;

public void PlayAwesomeTune()
{
     CreateSecondaryBuffer();
}

private ubyte[] CreateSecondaryBuffer()
{
     return new ubyte[2048];
}
---

The only way it would conflict is if they also had a module called 
"firelancer.audio.music" with a function called "CreateSecondaryBuffer" 
with the exact same signature. This obviously would be extremely 
unlikely unless they were purposefully trying to mess with something, or 
there were versioning issues like linking two copies of library.

.di files, though, are useful either as an optimization tool or for 
delivering a closed-source static library. For most development, you'll 
just use the same .d files as both interface and implementation, which 
is a lot simpler than the C/C++ method of having header files + source 
files and needing to worry about such things as linker conflicts, etc.