www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Questions about D

reply FireLancer <FireLancer yahoo.com> writes:
Ive been learning c++ and was wondering if I should move over to D or not but
theres a few details I'm not sure on and I couldn't find a good ansew on.

1)Is there a way to "hide" things complelty when building a static libary. eg
in c++ if I have:

//libary.h
double GetRandomNumber();

//libary.cpp
int DoSomething()
{
 //do something
}
double GetRandomNumber()
{
     return (double)rand() / RAND_MAX;
}


This is fine as the user doesn't know DoSomething() exists. But now if they
create there own DoSomething() they get linker errors because it exists twice :(

Also if I built a frame work based off of DirectX and Win32 API it's be nice to
complelty hide functions from those unless the user imported them themselves.
(So for them CreateWindow() doesn't exist UNLESS they imported the windows
files themselves even though it's used in my libary)
2)
I couldn't tell if D has an eqivlent to the STL. I can see that maps are built
in but what of std::set and std::list?

3)
How do I go about using DirectX with D as all the headers are c/c++

4)
Do the varible sizes work as in c or are they fixed?
eg in c I could define them as

char - at least one byte
short - at least as large as a char
int - at least as large as a short
long - at least as large as an int 

But it would be nice if they were fixed eg
char - 1 byte
short - 2 bytes
int - 4 bytes
long - 8 bytes

5)
May 22 2008
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
FireLancer wrote:

 Ive been learning c++ and was wondering if I should move over to D or not
 but theres a few details I'm not sure on and I couldn't find a good ansew
 on.
 
 2) I 
 couldn't tell if D has an eqivlent to the STL. I can see that maps are
 built in but what of std::set and std::list?
Tango has a collection package.
 3)
 How do I go about using DirectX with D as all the headers are c/c++
I would think there exists headers ported to D.
 
 4)
 Do the varible sizes work as in c or are they fixed?
 eg in c I could define them as
 
 char - at least one byte
 short - at least as large as a char
 int - at least as large as a short
 long - at least as large as an int
 
 But it would be nice if they were fixed eg
 char - 1 byte
 short - 2 bytes
 int - 4 bytes
 long - 8 bytes
They are fixed with those sizes. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
May 22 2008
prev sibling next sibling parent reply jcc7 <technocrat7 gmail.com> writes:
== Quote from FireLancer (FireLancer yahoo.com)'s article
...

 3)
 How do I go about using DirectX with D as all the headers are c/c++
I think there are a couple of D ports of the DirectX headers floating around. I suspect this is the best one (but I haven't used it myself): http://www.dsource.org/projects/bindings/browser/trunk/win32/directx (It's part of the "Windows API" project at dsource: http://www.dsource.org/projects/bindings/wiki/WindowsApi)
May 22 2008
parent reply FireLancer <Dragon_Fly1102 Hotmail.com> writes:
jcc7 Wrote:

 == Quote from FireLancer (FireLancer yahoo.com)'s article
 ...
 
 3)
 How do I go about using DirectX with D as all the headers are c/c++
I think there are a couple of D ports of the DirectX headers floating around. I suspect this is the best one (but I haven't used it myself): http://www.dsource.org/projects/bindings/browser/trunk/win32/directx (It's part of the "Windows API" project at dsource: http://www.dsource.org/projects/bindings/wiki/WindowsApi)
Is there no eqivlent of d3dx9.h or is it embedded in one of the other files? Ive used functions from that all over the place and I don't really want to relearn in order to work out ways of doing stuff without some of it's features and DirectX 10 isn't an option for me. Also is there any support beyond Direct3D like DirectSound or xAudio2 (prefered) or will I need to write my own port of the March SDK to get those things?
May 22 2008
parent reply Sascha Katzner <sorry.no spam.invalid> writes:
FireLancer wrote:
 Is there no eqivlent of d3dx9.h or is it embedded in one of the other
 files?  Ive used functions from that all over the place and I don't
 really want to relearn in order to work out ways of doing stuff
 without some of it's features and DirectX 10 isn't an option for me.
I must admit that I've never really locked into the D3D9 headers, because I'm using D3D10 exclusively. If the D3D9 headers are incomplete, perhaps you find the missing parts in one of the countless games which are on dsource.org (http://www.dsource.org/projects/).
 ...  or will I need to write my own port of the March SDK to
 get those things?
If you do that, commit them into the repository please. Even small additions are always welcome. LLAP, Sascha
May 22 2008
parent reply "Koroskin Denis" <2korden gmail.com> writes:
On Fri, 23 May 2008 02:12:35 +0400, Sascha Katzner <sorry.no spam.invalid>  
wrote:

 FireLancer wrote:
 Is there no eqivlent of d3dx9.h or is it embedded in one of the other
 files?  Ive used functions from that all over the place and I don't
 really want to relearn in order to work out ways of doing stuff
 without some of it's features and DirectX 10 isn't an option for me.
I must admit that I've never really locked into the D3D9 headers, because I'm using D3D10 exclusively. If the D3D9 headers are incomplete, perhaps you find the missing parts in one of the countless games which are on dsource.org (http://www.dsource.org/projects/).
 ...  or will I need to write my own port of the March SDK to
 get those things?
If you do that, commit them into the repository please. Even small additions are always welcome. LLAP, Sascha
I've fixed small d3d9 compilation issues and commited d3dx9, dsound8 and dinput8 bindings. I use Dx9 in my latest project, so let me know if have any problems with it, I'll try to help.
May 25 2008
next sibling parent reply Extrawurst <spam extrawurst.org> writes:
you are talking about the dx bindings in the bindings-project at dsource 
right ?


Koroskin Denis schrieb:
 On Fri, 23 May 2008 02:12:35 +0400, Sascha Katzner 
 <sorry.no spam.invalid> wrote:

 FireLancer wrote:
 Is there no eqivlent of d3dx9.h or is it embedded in one of the other
 files?  Ive used functions from that all over the place and I don't
 really want to relearn in order to work out ways of doing stuff
 without some of it's features and DirectX 10 isn't an option for me.
I must admit that I've never really locked into the D3D9 headers, because I'm using D3D10 exclusively. If the D3D9 headers are incomplete, perhaps you find the missing parts in one of the countless games which are on dsource.org (http://www.dsource.org/projects/).
 ...  or will I need to write my own port of the March SDK to
 get those things?
If you do that, commit them into the repository please. Even small additions are always welcome. LLAP, Sascha
I've fixed small d3d9 compilation issues and commited d3dx9, dsound8 and dinput8 bindings. I use Dx9 in my latest project, so let me know if have any problems with it, I'll try to help.
May 25 2008
parent "Koroskin Denis" <2korden gmail.com> writes:
On Sun, 25 May 2008 20:03:40 +0400, Extrawurst <spam extrawurst.org> wrote:

 you are talking about the dx bindings in the bindings-project at dsource  
 right ?


 Koroskin Denis schrieb:
 On Fri, 23 May 2008 02:12:35 +0400, Sascha Katzner  
 <sorry.no spam.invalid> wrote:

 FireLancer wrote:
 Is there no eqivlent of d3dx9.h or is it embedded in one of the other
 files?  Ive used functions from that all over the place and I don't
 really want to relearn in order to work out ways of doing stuff
 without some of it's features and DirectX 10 isn't an option for me.
I must admit that I've never really locked into the D3D9 headers, because I'm using D3D10 exclusively. If the D3D9 headers are incomplete, perhaps you find the missing parts in one of the countless games which are on dsource.org (http://www.dsource.org/projects/).
 ...  or will I need to write my own port of the March SDK to
 get those things?
If you do that, commit them into the repository please. Even small additions are always welcome. LLAP, Sascha
I've fixed small d3d9 compilation issues and commited d3dx9, dsound8 and dinput8 bindings. I use Dx9 in my latest project, so let me know if have any problems with it, I'll try to help.
Yep
May 25 2008
prev sibling parent Sascha Katzner <sorry.no spam.invalid> writes:
Koroskin Denis wrote:
 I've fixed small d3d9 compilation issues and commited d3dx9, dsound8
 and dinput8 bindings. I use Dx9 in my latest project, so let me know
 if have any problems with it, I'll try to help.
So far I didn't had the time to take a detailed look at the files, but I've noticed two things: 1) You use .def files. Have you tried coffimplib to convert the lib files? [1] When I translated the D3D10 part there was no def files needed. 2) Is the alignment of structs really required? As far as I know, D uses the same alignment as a C compiler as default. In my experience it's very rare that you need to align structs. LLAP, Sascha [1] ftp://ftp.digitalmars.com/coffimplib.zip http://www.digitalmars.com/ctg/coffimplib.html http://www.digitalmars.com/d/archives/c++/announce/864.html
May 25 2008
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
FireLancer wrote:
 Ive been learning c++ and was wondering if I should move over to D or not but
theres a few details I'm not sure on and I couldn't find a good ansew on.
 
 1)Is there a way to "hide" things complelty when building a static libary. eg
in c++ if I have:
 
 //libary.h
 double GetRandomNumber();
 
 //libary.cpp
 int DoSomething()
 {
  //do something
 }
 double GetRandomNumber()
 {
      return (double)rand() / RAND_MAX;
 }
 
 
 This is fine as the user doesn't know DoSomething() exists. But now if they
create there own DoSomething() they get linker errors because it exists twice :(
Yes and no. In D, everything is qualified by its module name, and there's a 1:1 module:file correspondence. So it's unlikely that two modules would have the same fully-qualified name with the exact same symbol. A bigger problem is that D doesn't have the concept of header files (well, it does sort of with .di files, but they're rarely used in open-source since they're generally not necessary if you have the source file). The problem is that if you import one of them, all the symbols (even those marked "private") will be imported.
May 22 2008
parent reply FireLancer <Dragon_Fly1102 Hotmail.com> writes:
Robert Fraser Wrote:

 FireLancer wrote:
 Ive been learning c++ and was wondering if I should move over to D or not but
theres a few details I'm not sure on and I couldn't find a good ansew on.
 
 1)Is there a way to "hide" things complelty when building a static libary. eg
in c++ if I have:
 
 //libary.h
 double GetRandomNumber();
 
 //libary.cpp
 int DoSomething()
 {
  //do something
 }
 double GetRandomNumber()
 {
      return (double)rand() / RAND_MAX;
 }
 
 
 This is fine as the user doesn't know DoSomething() exists. But now if they
create there own DoSomething() they get linker errors because it exists twice :(
Yes and no. In D, everything is qualified by its module name, and there's a 1:1 module:file correspondence. So it's unlikely that two modules would have the same fully-qualified name with the exact same symbol. A bigger problem is that D doesn't have the concept of header files (well, it does sort of with .di files, but they're rarely used in open-source since they're generally not necessary if you have the source file). The problem is that if you import one of them, all the symbols (even those marked "private") will be imported.
So like in c++ I can't choose not to export something in a static lib and make it completly unavaible?
May 22 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
FireLancer wrote:
 Robert Fraser Wrote:
 
 FireLancer wrote:
 Ive been learning c++ and was wondering if I should move over to D or not but
theres a few details I'm not sure on and I couldn't find a good ansew on.

 1)Is there a way to "hide" things complelty when building a static libary. eg
in c++ if I have:

 //libary.h
 double GetRandomNumber();

 //libary.cpp
 int DoSomething()
 {
  //do something
 }
 double GetRandomNumber()
 {
      return (double)rand() / RAND_MAX;
 }


 This is fine as the user doesn't know DoSomething() exists. But now if they
create there own DoSomething() they get linker errors because it exists twice :(
Yes and no. In D, everything is qualified by its module name, and there's a 1:1 module:file correspondence. So it's unlikely that two modules would have the same fully-qualified name with the exact same symbol. A bigger problem is that D doesn't have the concept of header files (well, it does sort of with .di files, but they're rarely used in open-source since they're generally not necessary if you have the source file). The problem is that if you import one of them, all the symbols (even those marked "private") will be imported.
So like in c++ I can't choose not to export something in a static lib and make it completly unavaible?
In C++ you can put things in an anonymous namespace: namespace { int variable_only_i_can_see; double function_only_i_can_call() { return (double)rand()/RAND_MAX; } } In C you could use "static": static int only_i_can_see; In D I'm not sure if there is any such thing. --bb
May 22 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
news:g14nq9$dgq$1 digitalmars.com...
 In C++ you can put things in an anonymous namespace:

 namespace {
    int variable_only_i_can_see;
    double function_only_i_can_call() { return (double)rand()/RAND_MAX; }
 }

 In C you could use "static":

  static int only_i_can_see;

 In D I'm not sure if there is any such thing.
Uh, 'private'?
May 22 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Jarrett Billingsley wrote:
 "Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
 news:g14nq9$dgq$1 digitalmars.com...
 In C++ you can put things in an anonymous namespace:

 namespace {
    int variable_only_i_can_see;
    double function_only_i_can_call() { return (double)rand()/RAND_MAX; }
 }

 In C you could use "static":

  static int only_i_can_see;

 In D I'm not sure if there is any such thing.
Uh, 'private'?
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? --bb
May 22 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
news:g14r0u$nf0$1 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.
May 22 2008
parent reply FireLancer <FireLancer yahoo.com> writes:
Jarrett Billingsley Wrote:

 "Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
 news:g14r0u$nf0$1 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.
May 23 2008
parent Robert Fraser <fraserofthenight gmail.com> writes:
FireLancer wrote:
 Jarrett Billingsley Wrote:
 
 "Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
 news:g14r0u$nf0$1 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.
May 23 2008
prev sibling parent Spacen Jasset <spacen yahoo.co.uk> writes:
OpenGL support is available via derelict, which is very ipressive 
package. I don't know about direct x. But if you are not fixed on the 
idea of direct x. Consider derelict, which also has joystick/sound 
support though the vorbis/ogg/sdl_mixer/sdl libraries.
May 22 2008