digitalmars.D.learn - Questions about D
- FireLancer (32/32) May 22 2008 Ive been learning c++ and was wondering if I should move over to D or no...
- Lars Ivar Igesund (10/34) May 22 2008 Tango has a collection package.
- jcc7 (7/9) May 22 2008 I think there are a couple of D ports of the DirectX headers floating ar...
- FireLancer (3/15) May 22 2008 Is there no eqivlent of d3dx9.h or is it embedded in one of the other fi...
- Sascha Katzner (9/15) May 22 2008 I must admit that I've never really locked into the D3D9 headers,
- Koroskin Denis (6/21) May 25 2008 I've fixed small d3d9 compilation issues and commited d3dx9, dsound8 and...
- Extrawurst (3/29) May 25 2008 you are talking about the dx bindings in the bindings-project at dsource...
- Koroskin Denis (2/33) May 25 2008 Yep
- Sascha Katzner (14/17) May 25 2008 So far I didn't had the time to take a detailed look at the files, but
- Robert Fraser (9/28) May 22 2008 Yes and no. In D, everything is qualified by its module name, and
- FireLancer (2/32) May 22 2008 So like in c++ I can't choose not to export something in a static lib an...
- Bill Baxter (10/44) May 22 2008 In C++ you can put things in an anonymous namespace:
- Jarrett Billingsley (3/11) May 22 2008 Uh, 'private'?
- Bill Baxter (5/21) May 22 2008 Maybe it's supposed to have that effect, but currently at least it does
- Jarrett Billingsley (4/7) May 22 2008 But if you make a symbol private, build it as a lib, and export the .di,...
- FireLancer (5/16) May 23 2008 So in D it only looks at what is defined in the .di file unlike c++ whic...
- Robert Fraser (31/51) May 23 2008 Well, there needs to be a 1:1 ratio of .d files and .di files since each...
- Spacen Jasset (4/4) May 22 2008 OpenGL support is available via derelict, which is very ipressive
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
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 bytesThey are fixed with those sizes. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
May 22 2008
== 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
jcc7 Wrote:== Quote from FireLancer (FireLancer yahoo.com)'s article ...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?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
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
On Fri, 23 May 2008 02:12:35 +0400, Sascha Katzner <sorry.no spam.invalid> wrote:FireLancer 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.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 25 2008
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: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.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 25 2008
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:YepOn Fri, 23 May 2008 02:12:35 +0400, Sascha Katzner <sorry.no spam.invalid> wrote:FireLancer 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.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 25 2008
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
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
Robert Fraser Wrote:FireLancer wrote:So like in c++ I can't choose not to export something in a static lib and make it completly unavaible?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
FireLancer wrote:Robert Fraser Wrote: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. --bbFireLancer wrote:So like in c++ I can't choose not to export something in a static lib and make it completly unavaible?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
"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
Jarrett Billingsley wrote:"Bill Baxter" <dnewsgroup billbaxter.com> wrote in message news:g14nq9$dgq$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? --bbIn 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
"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
Jarrett Billingsley Wrote:"Bill Baxter" <dnewsgroup billbaxter.com> wrote in message news:g14r0u$nf0$1 digitalmars.com...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.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 23 2008
FireLancer wrote:Jarrett Billingsley Wrote: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."Bill Baxter" <dnewsgroup billbaxter.com> wrote in message news:g14r0u$nf0$1 digitalmars.com...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.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 23 2008
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