Re: val.init
On 2013-10-02 19:54, Sean Kelly wrote: I think it used to work roughly this way but was changed… um… maybe 2 years ago? It has worked like this for as long as I can remember. I've been using D for 6-7 years. -- /Jacob Carlborg
Re: come back to D
On 2013-10-02 23:07, Spacen Jasset wrote: I recently heard about dub and other useful things happening in the D world after being away from it for a long while. So, as you do I thought I would see what's going on. C:\bzr\mk4k-dmd2dub build Checking dependencies in 'C:\bzr\mk4k-dmd2' Building configuration application, build type debug Running dmd (compile)... Linking... OPTLINK (R) for Win32 Release 8.00.13 Copyright (C) Digital Mars 1989-2010 All rights reserved. http://www.digitalmars.com/ctg/optlink.html OPTLINK : Error 118: Filename Expected Path=PATH=C:\Ruby192\bin;C:\WINDOWS\system32;C:\WINDOWS;c:\usr\local\bin;C:\Program Files\CodeBlocks\share\devpaks\bin;C:\Program Files\Bazaar;C:\Program Files\dub;C:\PROGRA~1\PyGTK\GTK\bin;c:\program files\winmerge;C:\Program Files\Nmap;c:\python27;C:\dmd2.0 3.2\windows\bin ^ --- errorlevel 1 Error: Link command failed with exit code 1 Some things seem to never change (and never seem to get fixed). What is the situation with optlink and why can't it be fixed? http://d.puremagic.com/issues/show_bug.cgi?id=4831 You can now compile for 64bit on Windows using the Visual Studio tool chain. -- /Jacob Carlborg
directx bindings problem
i'm trying directx bindings from dsource (http://dsource.org/projects/bindings/wiki/DirectX) and encountered problem, when calling swap chain getbuffer it suddenly crashes. does anyone using it? any help please :( // Create a render target view ID3D11Texture2D* pBackBuffer; // C++ version //hr = g_pSwapChain-GetBuffer( 0, __uuidof( ID3D11Texture2D ),(LPVOID*)pBackBuffer ); // D version(crashes) hr = g_pSwapChain.GetBuffer( 0, IID_ID3D11Texture2D, cast(LPVOID*)pBackBuffer );
A few questions about safe concurrent programming assumptions
Hi there,
I have a few questions about what is safe to assume when writing
concurrent code in D with data sharing (as opposed to message
passing).
After doing a fair amount of reading, I'm still slightly hazy
about what shared does and doesn't guarantee. Here is the only
assumption I understand to be valid:
* Reads and writes to shared variables with a size equal to or
less than the word size of the machine are atomic and are visible
to all other threads immediately.
Now, in Andrei's D book he also states that sequential
consistency is guaranteed for operations on shared data, however
I understand that this is not currently implemented by (any?)
compiler and perhaps never will be, what with the discussions
about making changes to the semantics of shared and all.
So then this code is not safe, assuming the methods are executed
on different threads:
shared int x = 0;
shared bool complete = false;
void foo()
{
x = 7; // atomic
complete = true; // atomic
}
void bar()
{
while (!complete) {}
writeln(x); // undefined output (0 or 7)
}
But then I understand the core.atomic module incorporates the
necessary memory barriers to make this work, so we can replace
foo() by:
void foo()
{
x.atomicStore(7);
complete.atomicStore(true);
}
and achieve the intended behaviour (maybe only one of those two
modifications were actually needed here?). Or possibly:
void foo()
{
x = 7; // atomic
atomicFence(); // from core.atomic again
complete = true; // atomic
}
Do these modifications achieve the desired result? I know there
are other ways to go about this. I think one (bad) way is putting
a mutex around every read/write (a mutex also acts as a memory
barrier, right?), and I suppose in this case, message passing!
(But let's pretend the data sharing is more complex)
My other question about shared is: what does the shared qualifier
mean when applied to a class definition? e.g.
shared class Cat {...}
Does it just force all references to Cat instances to be shared
by default and make all methods of Cat shared? Andrei uses it in
his book when talking about lock-free programming with cas,
however he seems to make the assumption (well, explicitly states)
that sequential consistency is assured within the methods of such
a class. I'm quite confused about what it actually means,
especially since shared apparently does not currently use memory
barriers.
Re: directx bindings problem
Am 03.10.2013 08:19, schrieb evilrat: i'm trying directx bindings from dsource (http://dsource.org/projects/bindings/wiki/DirectX) and encountered problem, when calling swap chain getbuffer it suddenly crashes. does anyone using it? any help please :( // Create a render target view ID3D11Texture2D* pBackBuffer; // C++ version //hr = g_pSwapChain-GetBuffer( 0, __uuidof( ID3D11Texture2D ),(LPVOID*)pBackBuffer ); // D version(crashes) hr = g_pSwapChain.GetBuffer( 0, IID_ID3D11Texture2D, cast(LPVOID*)pBackBuffer ); What directX .lib file are you linking against? Whats the exact error that is given to you? When you run this from within visual studio you might get additional information about the problem. Kind Regards Bejamin Thaut
Re: directx bindings problem
On Thursday, 3 October 2013 at 09:35:46 UTC, Benjamin Thaut wrote: Am 03.10.2013 08:19, schrieb evilrat: i'm trying directx bindings from dsource (http://dsource.org/projects/bindings/wiki/DirectX) and encountered problem, when calling swap chain getbuffer it suddenly crashes. does anyone using it? any help please :( // Create a render target view ID3D11Texture2D* pBackBuffer; // C++ version //hr = g_pSwapChain-GetBuffer( 0, __uuidof( ID3D11Texture2D ),(LPVOID*)pBackBuffer ); // D version(crashes) hr = g_pSwapChain.GetBuffer( 0, IID_ID3D11Texture2D, cast(LPVOID*)pBackBuffer ); What directX .lib file are you linking against? Whats the exact error that is given to you? When you run this from within visual studio you might get additional information about the problem. Kind Regards Bejamin Thaut d3dcompiler.lib, d3d11.lib, dxgi.lib i can't get any details on it, as it seems to be somewhere inside DirectX C++ part. i was thinking this is GUID problem, so i'd tried using IIDFromString on D3D11Texture2d GUID to get actual value with no luck(it always report invalid args).
Re: val.init
On Wednesday, 2 October 2013 at 02:10:35 UTC, Nick Sabalausky
wrote:
I thought variable.init was different from T.init and gave the
value of
the explicit initializer if one was used. Was I mistaken?:
import std.stdio;
void main()
{
int a = 5;
writeln(a.init); // Outputs 0, not 5
}
Not exactly. The spec does mention something similar regarding a
typedef [1]. Since typedef is deprecated I've never used it, but
IIRC it's effect is similar to defining a struct with a single
member. From this point of view it makes sense the init of a
typedef'ed primitive type is not necessarily equal to that
primitive type's init, since
struct A { int i = 5; }
void main() { writeln(A.init.i); }
prints 5.
[1] http://dlang.org/property#init
Re: directx bindings problem
Am 03.10.2013 11:57, schrieb evilrat: On Thursday, 3 October 2013 at 09:35:46 UTC, Benjamin Thaut wrote: Am 03.10.2013 08:19, schrieb evilrat: i'm trying directx bindings from dsource (http://dsource.org/projects/bindings/wiki/DirectX) and encountered problem, when calling swap chain getbuffer it suddenly crashes. does anyone using it? any help please :( // Create a render target view ID3D11Texture2D* pBackBuffer; // C++ version //hr = g_pSwapChain-GetBuffer( 0, __uuidof( ID3D11Texture2D ),(LPVOID*)pBackBuffer ); // D version(crashes) hr = g_pSwapChain.GetBuffer( 0, IID_ID3D11Texture2D, cast(LPVOID*)pBackBuffer ); What directX .lib file are you linking against? Whats the exact error that is given to you? When you run this from within visual studio you might get additional information about the problem. Kind Regards Bejamin Thaut d3dcompiler.lib, d3d11.lib, dxgi.lib i can't get any details on it, as it seems to be somewhere inside DirectX C++ part. i was thinking this is GUID problem, so i'd tried using IIDFromString on D3D11Texture2d GUID to get actual value with no luck(it always report invalid args). NO I mean are you sure the library paths are correctly set to the June 2010 DirectX SDK/lib path? Do you use 32 or 64 bit? You can get details on crashes inside DirectX by using the microsoft symbol server: http://support.microsoft.com/kb/311503 (assuming you use the microsoft debugger of course) Kind Regards Benjamin Thaut
Re: Ddoc WEB function
On 02/10/13 21:34, Jonathan M Davis wrote: It's not a bug at all. It's in https://github.com/D-Programming-Language/dlang.org/blob/master/std.ddoc ddoc is a macro language and does not at all restrict you to what comes with it, and the standard library uses quite a few macros that are specific to it (e.g. XREF for a link to another module in std). When you run dmd with -D, you can give it a .ddoc file which contains macros that you define (or redefine), and std.ddoc is the one that the standard library uses. Ahh, OK, thanks. If you to restrict yourself to the built-in ones in your code, then use the ones at http://dlang.org/ddoc.html And if you want to define more, then create your own .ddoc file with them in it. But Phobos uses std.ddoc, and we add new macros to it when we feel that it's appropriate. Fair enough, but ... , and is there any particular reason to favour WEB over, say, LINK2 ? It's less verbose. ... is there any difference between WEB and LINK2 apart from the length? And if so, why not just include WEB among the built-in macros?
Re: directx bindings problem
On Thursday, 3 October 2013 at 10:08:42 UTC, Benjamin Thaut wrote: NO I mean are you sure the library paths are correctly set to the June 2010 DirectX SDK/lib path? all paths are set correctly. Do you use 32 or 64 bit? 32 bit. You can get details on crashes inside DirectX by using the microsoft symbol server: http://support.microsoft.com/kb/311503 (assuming you use the microsoft debugger of course) i'm using visual studio debugger, maybe i should try this. but as i said it looks like guid problem.
Re: Ddoc WEB function
On Thursday, 3 October 2013 at 10:46:00 UTC, Joseph Rushton Wakeling wrote: On 02/10/13 21:34, Jonathan M Davis wrote: It's not a bug at all. It's in https://github.com/D-Programming-Language/dlang.org/blob/master/std.ddoc ddoc is a macro language and does not at all restrict you to what comes with it, and the standard library uses quite a few macros that are specific to it (e.g. XREF for a link to another module in std). When you run dmd with -D, you can give it a .ddoc file which contains macros that you define (or redefine), and std.ddoc is the one that the standard library uses. Ahh, OK, thanks. If you to restrict yourself to the built-in ones in your code, then use the ones at http://dlang.org/ddoc.html And if you want to define more, then create your own .ddoc file with them in it. But Phobos uses std.ddoc, and we add new macros to it when we feel that it's appropriate. Fair enough, but ... , and is there any particular reason to favour WEB over, say, LINK2 ? It's less verbose. ... is there any difference between WEB and LINK2 apart from the length? And if so, why not just include WEB among the built-in macros? Doesn't WEB just add http://; before the first parameter? LINK2 = a href=$1$+/a WEB = a href=http://$1;$+/a I don't think there should be too many predefined macros. At least not all related to HTML. But it's possible to override them, right? There are probably plenty of nice-to-have macros that would be convenient to have always available, but it's pretty trivial to add them yourself - or just use the phobos ddoc.
Re: directx bindings problem
Am 03.10.2013 12:47, schrieb evilrat: On Thursday, 3 October 2013 at 10:08:42 UTC, Benjamin Thaut wrote: NO I mean are you sure the library paths are correctly set to the June 2010 DirectX SDK/lib path? all paths are set correctly. Do you use 32 or 64 bit? 32 bit. You can get details on crashes inside DirectX by using the microsoft symbol server: http://support.microsoft.com/kb/311503 (assuming you use the microsoft debugger of course) i'm using visual studio debugger, maybe i should try this. but as i said it looks like guid problem. If you think it is a guid problem you could just open the c++ header lookup the GUID and compare it to the one in derlict
Re: directx bindings problem
On 10/3/13, evilrat evilrat...@gmail.com wrote: // Create a render target view ID3D11Texture2D* pBackBuffer; // C++ version //hr = g_pSwapChain-GetBuffer( 0, __uuidof( ID3D11Texture2D ),(LPVOID*)pBackBuffer ); // D version(crashes) hr = g_pSwapChain.GetBuffer( 0, IID_ID3D11Texture2D, cast(LPVOID*)pBackBuffer ); You're passing a null pointer (pBackBuffer). You should try this: ID3D11Texture2D backBuffer; hr = g_pSwapChain.GetBuffer( 0, IID_ID3D11Texture2D, cast(LPVOID*)backBuffer );
Re: directx bindings problem
On Thursday, 3 October 2013 at 11:21:14 UTC, Benjamin Thaut wrote: Am 03.10.2013 12:47, schrieb evilrat: On Thursday, 3 October 2013 at 10:08:42 UTC, Benjamin Thaut wrote: NO I mean are you sure the library paths are correctly set to the June 2010 DirectX SDK/lib path? all paths are set correctly. Do you use 32 or 64 bit? 32 bit. You can get details on crashes inside DirectX by using the microsoft symbol server: http://support.microsoft.com/kb/311503 (assuming you use the microsoft debugger of course) i'm using visual studio debugger, maybe i should try this. but as i said it looks like guid problem. If you think it is a guid problem you could just open the c++ header lookup the GUID and compare it to the one in derlict this is not derelict, it's old directx bindings that was part of winapi bindings i think.
Re: directx bindings problem
On Thursday, 3 October 2013 at 11:30:58 UTC, Andrej Mitrovic wrote: On 10/3/13, evilrat evilrat...@gmail.com wrote: // Create a render target view ID3D11Texture2D* pBackBuffer; // C++ version //hr = g_pSwapChain-GetBuffer( 0, __uuidof( ID3D11Texture2D ),(LPVOID*)pBackBuffer ); // D version(crashes) hr = g_pSwapChain.GetBuffer( 0, IID_ID3D11Texture2D, cast(LPVOID*)pBackBuffer ); You're passing a null pointer (pBackBuffer). You should try this: ID3D11Texture2D backBuffer; hr = g_pSwapChain.GetBuffer( 0, IID_ID3D11Texture2D, cast(LPVOID*)backBuffer ); this not works too(actually it would never be, because this is just interface). what i'm trying to do is what works on c++ just fine, so that texture should be null. actually now i'm think this bindings too outdated, or there is some ABI mismatch which i can't find out now... either way, i think creating a custom binding would be the best way. thanks for help anyway.
Bug again?
mixin template test()
{
int next;
}
void foo(alias l, alias t)()
{
t.next = l.next;
}
void main()
{
struct A
{
int next;
}
A a;
mixin test l1;
mixin test l2;
foo!(l1,a); //ok!
foo!(l1,l2);//compilation error!
}
Re: Bug again?
On Thursday, 3 October 2013 at 12:24:38 UTC, Zhouxuan wrote:
mixin template test()
{
int next;
}
void foo(alias l, alias t)()
{
t.next = l.next;
}
void main()
{
struct A
{
int next;
}
A a;
mixin test l1;
mixin test l2;
foo!(l1,a); //ok!
foo!(l1,l2);//compilation error!
}
Local aliasing problems..?
The error message is
Error: function D main is a nested function and cannot be
accessed from t.foo!(l1, l2).foo
Moving the mixins out of main works.
Re: Conflict between std.file write() and std.stdio write()
On Thursday, 3 October 2013 at 02:57:50 UTC, Andrej Mitrovic
wrote:
On 10/3/13, Craig Dillabaugh cdill...@cg.scs.carleton.ca
wrote:
void main( string[] args ) {
string str = Hello;
write( file.txt, str );
string hello_file = readText(file.txt);
writeln( hello_file );
}
You can also disambiguate by preferring one symbol over another
with an alias:
alias write = std.file.write;
void main( string[] args ) {
string str = Hello;
write( file.txt, str );
}
You can also put the alias inside the function.
Thanks.
It seems that std.file should include a writeText() function for
the sake of consistency that is the above alias. When you come
across readText() in the documentation you sort of expect that
such a function would exist, and then you spot write() below it,
and think hey that does what I need. Then you hit upon the
syntax error if you are also using std.stdio (which is a very
commonly used module).
Adding writeText() doesn't really add much to the library, but
having to jump through hoops (as minor as they may be) to perform
such a simple op is a bit of a pain for people new to the
language.
Craig
Re: Conflict between std.file write() and std.stdio write()
On Thursday, October 03, 2013 15:22:28 Craig Dillabaugh wrote: It seems that std.file should include a writeText() function for the sake of consistency that is the above alias. When you come across readText() in the documentation you sort of expect that such a function would exist, and then you spot write() below it, and think hey that does what I need. Then you hit upon the syntax error if you are also using std.stdio (which is a very commonly used module). Adding writeText() doesn't really add much to the library, but having to jump through hoops (as minor as they may be) to perform such a simple op is a bit of a pain for people new to the language. writeText would be redundant. write will already write arbitrary data to a file - including strings. writeText would add no functionality. Functions should add actual value, or they just clutter up the library. Conflicting functions is just part of life. The module system is designed to let you disambiguate them. We're not going to try and make all of the function names unique just because you might import a module with a conflicting function. If write is the best name for the function, then that's what we'll use, even if it conflicts with a function in another module. To do otherwise would be to ignore the features of the module system and force us to come up with worse names just to avoid conflicts. - Jonathan M Davis
Re: Ddoc WEB function
On Thursday, October 03, 2013 12:45:55 Joseph Rushton Wakeling wrote: If you to restrict yourself to the built-in ones in your code, then use the ones at http://dlang.org/ddoc.html And if you want to define more, then create your own .ddoc file with them in it. But Phobos uses std.ddoc, and we add new macros to it when we feel that it's appropriate. Fair enough, but ... I don't see the problem. If you want the standard set of macros, then look at the docs. If you want more, then add your own. We need more in the Phobos docs, so we define more - many of which wouldn't even make sense as standard macros. I see no reason to restrict Phobos to the standard set of macros. , and is there any particular reason to favour WEB over, say, LINK2 ? It's less verbose. ... is there any difference between WEB and LINK2 apart from the length? And if so, why not just include WEB among the built-in macros? I don't know how Walter arrived at the standard ones. I don't think that we ever mess with those at this point. If we need new ones, we add them to std.ddoc. WEB saves a bit of typing, so someone among the Phobos devs decided to add it, and we've ended up using it. But all it saves you is the http://, so for the common case at least, it's kind of redundant to have both (though you do need LINK2 for when it's not http). If someone wants WEB, they can just copy it from std.ddoc. There's a good chance that anyone doing a lot with ddoc will be copying and tweaking std.ddoc anyway. I don't see a lot of benefit in adding anything to the standard ones, particularly when there's a good chance that you're just going to end up overriding them all anyway in order to tweak them (std.ddoc does that with at least some of them - like the colors). - Jonathan M Davis
Re: Conflict between std.file write() and std.stdio write()
On Thursday, 3 October 2013 at 18:12:01 UTC, Jonathan M Davis wrote: On Thursday, October 03, 2013 15:22:28 Craig Dillabaugh wrote: It seems that std.file should include a writeText() function for the sake of consistency that is the above alias. When you come across readText() in the documentation you sort of expect that such a function would exist, and then you spot write() below it, and think hey that does what I need. Then you hit upon the syntax error if you are also using std.stdio (which is a very commonly used module). Adding writeText() doesn't really add much to the library, but having to jump through hoops (as minor as they may be) to perform such a simple op is a bit of a pain for people new to the language. writeText would be redundant. write will already write arbitrary data to a file - including strings. writeText would add no functionality. Functions should add actual value, or they just clutter up the library. Conflicting functions is just part of life. The module system is designed to let you disambiguate them. We're not going to try and make all of the function names unique just because you might import a module with a conflicting function. If write is the best name for the function, then that's what we'll use, even if it conflicts with a function in another module. To do otherwise would be to ignore the features of the module system and force us to come up with worse names just to avoid conflicts. - Jonathan M Davis Fair enough. As you point out the fix is pretty simple. However, I can't seem to remember in C++ or any other language (not that I know all that many other languages) coming across a function in the standard library that conflicted with another function in the standard library in this way. I am likely to get corrected on that claim though :o) Maybe it would be worth noting this conflict in the documentations for newbies. Craig
Re: Conflict between std.file write() and std.stdio write()
Craig Dillabaugh: However, I can't seem to remember in C++ or any other language (not that I know all that many other languages) coming across a function in the standard library that conflicted with another function in the standard library in this way. Generally Phobos should be designed to avoid name clashes as much as possible. Because Phobos functions are used often, and because specifying fully the path of function doesn't play well with UFCS chains (unless you use Alias!(), but it's long to write). Recently one name clash, with chunks, was removed from Phobos. Another clash, with splitter, is currently worked on. Bye, bearophile
Re: Conflict between std.file write() and std.stdio write()
On Thursday, October 03, 2013 20:57:20 Craig Dillabaugh wrote: On Thursday, 3 October 2013 at 18:12:01 UTC, Jonathan M Davis wrote: On Thursday, October 03, 2013 15:22:28 Craig Dillabaugh wrote: It seems that std.file should include a writeText() function for the sake of consistency that is the above alias. When you come across readText() in the documentation you sort of expect that such a function would exist, and then you spot write() below it, and think hey that does what I need. Then you hit upon the syntax error if you are also using std.stdio (which is a very commonly used module). Adding writeText() doesn't really add much to the library, but having to jump through hoops (as minor as they may be) to perform such a simple op is a bit of a pain for people new to the language. writeText would be redundant. write will already write arbitrary data to a file - including strings. writeText would add no functionality. Functions should add actual value, or they just clutter up the library. Conflicting functions is just part of life. The module system is designed to let you disambiguate them. We're not going to try and make all of the function names unique just because you might import a module with a conflicting function. If write is the best name for the function, then that's what we'll use, even if it conflicts with a function in another module. To do otherwise would be to ignore the features of the module system and force us to come up with worse names just to avoid conflicts. - Jonathan M Davis Fair enough. As you point out the fix is pretty simple. However, I can't seem to remember in C++ or any other language (not that I know all that many other languages) coming across a function in the standard library that conflicted with another function in the standard library in this way. I am likely to get corrected on that claim though :o) I'm sure that it could be found somewhere, but C++ avoids it for two reasons: 1. As good as the STL is, it's pathetically small. 2. It only uses one namespace, so it _has_ to avoid conflicts, even if that means using uglier names. Java or C# might have some conflicts (I'm not sure - they certainly have much richer standard libraries than C++ does), but they almost always avoid it, because they're don't even allow free functions, so you only end up having to worry about class names conflicting. Their module systems are also different from D's (particularly C#'s), which changes things a bit. Other languages like python tend to force you to give the full path anyway, which avoids conflicts. The reason that D runs into them is because the default is to pull everything into the current module when you import it. If we'd taken the approach of making you give the full import path by default or forcing you to explicitly import each symbol, then it wouldn't be a problem (though that would obviously cause other problems). And we'll definitely pick different names where appropriate, but if the best names for two different functions in two different modules happen to be the same name, then we're going to use it. And in same cases, we very purposely picked the same name, because the functions did the same type of thing (e.g. the functions in std.ascii and std.uni which do the same thing but for ASCII and Unicode respectively). - Jonathan M Davis
Re: Conflict between std.file write() and std.stdio write()
On Thursday, 3 October 2013 at 19:49:07 UTC, Jonathan M Davis wrote: On Thursday, October 03, 2013 20:57:20 Craig Dillabaugh wrote: On Thursday, 3 October 2013 at 18:12:01 UTC, Jonathan M Davis clip - Jonathan M Davis Fair enough. As you point out the fix is pretty simple. However, I can't seem to remember in C++ or any other language (not that I know all that many other languages) coming across a function in the standard library that conflicted with another function in the standard library in this way. I am likely to get corrected on that claim though :o) I'm sure that it could be found somewhere, but C++ avoids it for two reasons: 1. As good as the STL is, it's pathetically small. 2. It only uses one namespace, so it _has_ to avoid conflicts, even if that means using uglier names. Java or C# might have some conflicts (I'm not sure - they certainly have much richer standard libraries than C++ does), but they almost always avoid it, because they're don't even allow free functions, so you only end up having to worry about class names conflicting. Their module systems are also different from D's (particularly C#'s), which changes things a bit. Other languages like python tend to force you to give the full path anyway, which avoids conflicts. The reason that D runs into them is because the default is to pull everything into the current module when you import it. If we'd taken the approach of making you give the full import path by default or forcing you to explicitly import each symbol, then it wouldn't be a problem (though that would obviously cause other problems). And we'll definitely pick different names where appropriate, but if the best names for two different functions in two different modules happen to be the same name, then we're going to use it. And in same cases, we very purposely picked the same name, because the functions did the same type of thing (e.g. the functions in std.ascii and std.uni which do the same thing but for ASCII and Unicode respectively). - Jonathan M Davis That is an excellent explanation. Thank you. Do you think it would be worth noting the conflict in the documentation for readText()/write()? I should have mentioned in my original post that I likely could have figured out the workaround for this, and I posted here more because I was surprised that std.stdio and std.file would have a conflict! It seems like something folks new to D might run into with some frequency, and be thinking whats up with that!. If others think it is a good idea, maybe I will head over to gitHub and try to add something. Craig
Re: Conflict between std.file write() and std.stdio write()
On Thursday, October 03, 2013 22:57:22 Craig Dillabaugh wrote: On Thursday, 3 October 2013 at 19:49:07 UTC, Jonathan M Davis wrote: On Thursday, October 03, 2013 20:57:20 Craig Dillabaugh wrote: On Thursday, 3 October 2013 at 18:12:01 UTC, Jonathan M Davis clip - Jonathan M Davis Fair enough. As you point out the fix is pretty simple. However, I can't seem to remember in C++ or any other language (not that I know all that many other languages) coming across a function in the standard library that conflicted with another function in the standard library in this way. I am likely to get corrected on that claim though :o) I'm sure that it could be found somewhere, but C++ avoids it for two reasons: 1. As good as the STL is, it's pathetically small. 2. It only uses one namespace, so it _has_ to avoid conflicts, even if that means using uglier names. Java or C# might have some conflicts (I'm not sure - they certainly have much richer standard libraries than C++ does), but they almost always avoid it, because they're don't even allow free functions, so you only end up having to worry about class names conflicting. Their module systems are also different from D's (particularly C#'s), which changes things a bit. Other languages like python tend to force you to give the full path anyway, which avoids conflicts. The reason that D runs into them is because the default is to pull everything into the current module when you import it. If we'd taken the approach of making you give the full import path by default or forcing you to explicitly import each symbol, then it wouldn't be a problem (though that would obviously cause other problems). And we'll definitely pick different names where appropriate, but if the best names for two different functions in two different modules happen to be the same name, then we're going to use it. And in same cases, we very purposely picked the same name, because the functions did the same type of thing (e.g. the functions in std.ascii and std.uni which do the same thing but for ASCII and Unicode respectively). - Jonathan M Davis That is an excellent explanation. Thank you. Do you think it would be worth noting the conflict in the documentation for readText()/write()? I should have mentioned in my original post that I likely could have figured out the workaround for this, and I posted here more because I was surprised that std.stdio and std.file would have a conflict! It seems like something folks new to D might run into with some frequency, and be thinking whats up with that!. If others think it is a good idea, maybe I will head over to gitHub and try to add something. I'm inclined to think that there's no need, since people learning D should know how the module system works, and I'd prefer not to clutter the documentation, but I also haven't been a newbie for a very long time. - Jonathan M Davis
