Re: Learning D - first steps and best practices
On 2013-10-01 19:32:05 +, qznc said: On Sunday, 29 September 2013 at 07:49:21 UTC, Jonathan M Davis wrote: I confess that I don't understand why so many people are fixated on having a standard style, particularly when it's very, very clear that most everyone disagrees on what counts as good style. What little we have in terms of official style guidlelines for D can be found here: http//:dlang.org/dstyle.html I think nowadays programmers expect their language to come with more opinion and best practices. In contrast, the C++ world is too fragmented for consistent advice. I believe, the best solution would be to include an auto-formatter (like go fmt), so people can simply reformat the code before and after editing. You could also store the code not as text but as a datastructure like a parse tree. Then the editing environment is free to handle this information the way it wants...
Warnings/What should I know?
I'm learning D. I'm curious about surprises I may get. I typically use C++, C# and javascript
Re: mutable, const, immutable guidelines
On Thu, Oct 17, 2013 at 09:08:16AM +0200, qznc wrote:
> On Wednesday, 16 October 2013 at 20:33:23 UTC, H. S. Teoh wrote:
> >I'm of the view that code should only require the minimum of
> >assumptions it needs to actually work. If your code can work with
> >mutable types, then let it take a mutable (unqualified) type. If your
> >code works without modifying input data, then let it take const. Only
> >if your code absolutely will not work correctly unless the data is
> >guaranteed to never change, ever, by anyone, should it take
> >immutable.
>
> What about functions, which are not thread-safe?
>
> auto percentageDistribution(const int[] percentages) {
> [...]
> assert (sum == 100);
> [...]
> }
>
> Not a realistic example, but it should do. This function checks that
> the sum of all percentages equals 100, but a concurrent modification
> might break this. You could require an immutable array to avoid that.
> Alternatively, the absence of "shared" could be considered enough to
> express this.
In D, variables are thread-local by default, and only shared if
explicitly stated so. If this function took shared(const(int)[]), or you
pass it something that's __gshared, then you might have a point. But in
normal D code I'd recommend against doing that.
Currently, D has some issues in the area of shared, requiring a cast to
strip shared from the type. So basically the onus is on the caller to
ensure that when shared is stripped from the type it's actually safe
from concurrent modification. In which case the above code should be OK
as-is.
T
--
Guns don't kill people. Bullets do.
Re: mutable, const, immutable guidelines
On Thu, Oct 17, 2013 at 08:56:08AM +0200, qznc wrote:
> On Wednesday, 16 October 2013 at 20:33:23 UTC, H. S. Teoh wrote:
> >I'm of the view that code should only require the minimum of
> >assumptions it needs to actually work. If your code can work with
> >mutable types, then let it take a mutable (unqualified) type. If your
> >code works without modifying input data, then let it take const. Only
> >if your code absolutely will not work correctly unless the data is
> >guaranteed to never change, ever, by anyone, should it take
> >immutable.
>
> Sounds reasonable. Which one of the following would you prefer?
>
> foo1(const T t) {
> takes_immutable(t.idup);
> }
>
> foo2(immutable(T) t) {
> takes_immutable(t);
> }
>
> I'd say foo2, which puts the burden of the copy on the caller.
> However, if the caller already has an immutable value an unecessary
> copy is avoided.
Well, that's a bit too generic to really decide one way or the other.
What do foo1 and foo2 do? I don't think it's fair to say one or the
other is superior without more context. It depends on what you're trying
to achieve.
T
--
Too many people have open minds but closed eyes.
Re: how would D be different if string were const(char)[]?
On Thursday, 17 October 2013 at 19:17:38 UTC, Daniel Davidson
wrote:
True and I believe they do it without an immutable keyword.
They do, but it's a special case, as opposed to D.
I'm not questioning the value of a non-mutable type, just
trying to get to the heart of why the keyword immutable is
preferred over const in this example.
As Dicebot said, NOBODY can modify immutable, while they can
modify const. YOU are the only one that can't modify const. It
could change right under you at any time.
Dicebot clarified it - essentially it is because sharing can
creep in before it gets settled into a const(char)[] context.
And once sharing has potentially happened you can't undo it
except for transitive deep copy.
Had D gone with:
struct String {
const(char)[] s_;
this(char[] s) { s_ = s.dup; }
}
and not allowed any modification of elements you would still
have immutable without the keyword. Granted, it would not be
efficient so I see the benefit.
That'd be a special case like in other languages, which isn't
necessary in D because of immutable.
Strings/slices have sharing. Can the same issue/benefit occur
with primitives? Would you ever have a need for
`immutable(int)` over `const(int)`?
Only if there's indirection, e.g., int vs. pointer to int.
Re: how would D be different if string were const(char)[]?
On Thursday, 17 October 2013 at 19:53:34 UTC, Jonathan M Davis wrote: For value types, there's no real difference between immutable and const. Because they're value types, you can't have mutable references to them. The differences between const and immutable only really come into play once you're dealing with reference types, because then you can end up with differently qualified references to the same data. It is important to make clarify that this is true only for directly accessible value types. Once any single level of indirection is in question, `const` stops giving any guarantees. This is exactly the case for `const(char)[]` vs `immutable(char)` - `const(char)` itself is a value type but pointer to `const(char)` can also store pointer to mutable `char`.
Re: What version of the DMD front end is this GDC using?
On Thu, Oct 17, 2013 at 09:52:17PM +0100, Spacen Jasset wrote: > Hello, > > Which version of the DMD front end is this gdc release using? You can find out with this code: pragma(msg, __VERSION__); > jason@adrastea:~$ gdc -v > Using built-in specs. > COLLECT_GCC=gdc > COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6/lto-wrapper > Target: i686-linux-gnu > Configured with: ../src/configure -v > --with-pkgversion='Ubuntu/Linaro 4.6.3-4ubuntu1' > --with-bugurl=file:///usr/share/doc/gdc-4.6/README.Bugs > --enable-languages=c,c++,d --prefix=/usr --program-suffix=-4.6 > --enable-shared --enable-linker-build-id --with-system-zlib > --libexecdir=/usr/lib --without-included-gettext > --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 > --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu > --enable-libstdcxx-time=yes --enable-gnu-unique-object > --disable-libmudflap --enable-plugin --disable-werror > --with-arch-32=i686 --with-tune=generic --disable-libquadmath > --enable-checking=release --build=i686-linux-gnu > --host=i686-linux-gnu --target=i686-linux-gnu > Thread model: posix > gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-4ubuntu1) 4.6.3 looks really old, probably it's 2.060 or earlier. T -- Talk is cheap. Whining is actually free. -- Lars Wirzenius
Re: Starting D with a project in mind.
Does anybody know if this is now fixed ? :- https://bitbucket.org/goshawk/gdc/issue/120/fsection-anchors-broken-on-arm I might be wrong but I could be facing this bug when trying to run any of the vibe.d samples, here's an example :- (gdb) cont Continuing. Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x001ad15c in gc_addRange () at ../../../../gcc-4.8-20131010/libphobos/libdruntime/gc/gc.d:293 #2 0x00174fb4 in vibe.utils.memory.T19FreeListObjectAllocTS4vibe4core7drivers13libevent2_tcp10TCPContextVb0Vb1Z.T5allocTC4vibe4core6driver10DriverCoreTPS6deimos6event212eventstruct10eventbaseTiTPS6deimos6event211bufferevent11buffereventTS4vibe4core3net14NetworkAddressTS4vibe4core3net14NetworkAddressZ.alloc() () #3 0x00034008 in vibe.core.drivers.libevent2_tcp.onConnect() () #4 0x00043430 in vibe.core.core.CoreTask.run() () #5 0x001a37fc in fiber_entryPoint () at ../../../../gcc-4.8-20131010/libphobos/libdruntime/core/thread.d:3800 #6 0xb6cbe0b0 in setcontext () from /lib/arm-linux-gnueabihf/libc.so.6 #7 0xb6cbe0b0 in setcontext () from /lib/arm-linux-gnueabihf/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Re: matrix business in D
On 10/17/2013 01:31 PM, Yura wrote: Dear D programmers, I am very new to D programming language. I just started to learn it as an alternative to python since the latter sometimes is too slow. My question is whether there some simple ways to solve linear algebra problems in D programming language? E.g. matrix multiplication, diagonalization, SVD decomposition? If there is something, I would definitely stick to D programming language in my projects. PS I am not a proffesinal programmer and I am sorry if this question has already been discussed. Thaks in advance! I don't know the answer but the following two threads seem relevant: http://forum.dlang.org/thread/aszatcbdiucurlnqr...@forum.dlang.org http://forum.dlang.org/thread/rhldihvykaaneubyr...@forum.dlang.org Ali
Re: Questions about VisualD
On 17.10.2013 20:44, Namespace wrote: And it seems that VisualD ignores all of my Tasks. My Tasklist is always empty, whats wrong? Or is this not implemented? The Tasklist is not implemented. That is a real minus. :/ Any chance that this comes with the next release? Probably not in the next release. It has been sitting on the todo list for a couple of years...
Re: Function pointer to member function.
On Thursday, 17 October 2013 at 03:21:38 UTC, Chris Cain wrote:
On Thursday, 17 October 2013 at 01:17:21 UTC, TheFlyingFiddle
wrote:
I would like to get access to a member function pointer. Taking
the this* as
the first argument.
...snip...
How should i implement getFP above? Is it even possible?
Well, it's certainly possible. If you were to do this:
```
delegate void(int) dg = &a.bar;
dg(1);
```
then you'd see the behavior you're looking for. Basically the
class reference is stored in dg.ptr and the function is in
dg.funcptr.
With that in mind, I whipped this up:
```
import std.stdio;
class Foo {
char c;
this() {
c = 'a';
}
this(char _c) {
c = _c;
}
void bar(int i) {
writeln("i = ", i, " c = ", c);
}
}
import std.traits;
//ParentOf!S is pseudocode representing __traits(parent, S)
//ReturnType!S function(ParentOf!S, ParameterTypeTuple!S)
auto getFP(alias S)() if(isSomeFunction!S) {
mixin("alias Parent = " ~ __traits(parent, S).stringof ~
";");
return (Parent r, ParameterTypeTuple!S t) {
ReturnType!S delegate(ParameterTypeTuple!S) dg;
dg.funcptr = &S;
dg.ptr = cast(void*) r;
return dg(t);
};
}
void main() {
Foo a = new Foo();
Foo b = new Foo('b');
auto fp = getFP!(Foo.bar);
fp(a, 1);
fp(b, 2);
}
```
Now one thing to note is that I'm not confident it's bug-free.
It does work in this test case, but I couldn't use
__traits(parent, S) as a type, so I used a mixin to kind of
force it to work. So I'm not fully sure whether it will work in
all cases, but if someone else has some improvements, that's
fine.
Another thing: I didn't spend too much time on the template
constraint. "isSomeFunction" is almost certainly too
permissive. I just threw it together and I haven't coded in D
for a while.
I hope this helped!
Thanks, this works well for my needs.
Re: Questions about VisualD
On Thursday, 17 October 2013 at 18:18:39 UTC, Rainer Schuetze wrote: On 17.10.2013 00:18, Namespace wrote: I've clicked on "Build Phobos browse info" and now I have absolute no idea how I can restore my old class view for my current project. Any suggestions? You want to remove the phobos info from the class view? You'll have to delete the generated json files from the folder given in the global "Visual D Settings" and restart VS. You meant the JSON paths. I found it by accident. Now I can continue working...
What version of the DMD front end is this GDC using?
Hello, Which version of the DMD front end is this gdc release using? jason@adrastea:~$ gdc -v Using built-in specs. COLLECT_GCC=gdc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6/lto-wrapper Target: i686-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-4ubuntu1' --with-bugurl=file:///usr/share/doc/gdc-4.6/README.Bugs --enable-languages=c,c++,d --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --disable-werror --with-arch-32=i686 --with-tune=generic --disable-libquadmath --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu Thread model: posix gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-4ubuntu1)
matrix business in D
Dear D programmers, I am very new to D programming language. I just started to learn it as an alternative to python since the latter sometimes is too slow. My question is whether there some simple ways to solve linear algebra problems in D programming language? E.g. matrix multiplication, diagonalization, SVD decomposition? If there is something, I would definitely stick to D programming language in my projects. PS I am not a proffesinal programmer and I am sorry if this question has already been discussed. Thaks in advance!
Re: how would D be different if string were const(char)[]?
On Thursday, October 17, 2013 21:17:37 Daniel Davidson wrote: > Strings/slices have sharing. Can the same issue/benefit occur > with primitives? Would you ever have a need for `immutable(int)` > over `const(int)`? For value types, there's no real difference between immutable and const. Because they're value types, you can't have mutable references to them. The differences between const and immutable only really come into play once you're dealing with reference types, because then you can end up with differently qualified references to the same data. - Jonathan M Davis
Re: how would D be different if string were const(char)[]?
On Thursday, 17 October 2013 at 18:28:31 UTC, Meta wrote:
On Thursday, 17 October 2013 at 13:08:18 UTC, Daniel Davidson
wrote:
If it would be no different then why prefer immutable(char)[]
for string?
Strings are immutable in quite a few other languages. Ex: Java,
Python. I found this old article written by Walter:
http://www.drdobbs.com/architecture-and-design/invariant-strings/228700475
True and I believe they do it without an immutable keyword. I'm
not questioning the value of a non-mutable type, just trying to
get to the heart of why the keyword immutable is preferred over
const in this example. Dicebot clarified it - essentially it is
because sharing can creep in before it gets settled into a
const(char)[] context. And once sharing has potentially happened
you can't undo it except for transitive deep copy.
Had D gone with:
struct String {
const(char)[] s_;
this(char[] s) { s_ = s.dup; }
}
and not allowed any modification of elements you would still have
immutable without the keyword. Granted, it would not be efficient
so I see the benefit.
Strings/slices have sharing. Can the same issue/benefit occur
with primitives? Would you ever have a need for `immutable(int)`
over `const(int)`?
Re: Questions about VisualD
On Thursday, 17 October 2013 at 18:18:39 UTC, Rainer Schuetze wrote: On 17.10.2013 00:18, Namespace wrote: I've clicked on "Build Phobos browse info" and now I have absolute no idea how I can restore my old class view for my current project. Any suggestions? You want to remove the phobos info from the class view? You'll have to delete the generated json files from the folder given in the global "Visual D Settings" and restart VS. In "Settings" are only VSSETTINGS files. No .json. Or which "Settings" did you mean? And why is there no option in VisualD to do that? :/ And it seems that VisualD ignores all of my Tasks. My Tasklist is always empty, whats wrong? Or is this not implemented? The Tasklist is not implemented. That is a real minus. :/ Any chance that this comes with the next release?
Re: how would D be different if string were const(char)[]?
On Thursday, 17 October 2013 at 13:08:18 UTC, Daniel Davidson wrote: If it would be no different then why prefer immutable(char)[] for string? Strings are immutable in quite a few other languages. Ex: Java, Python. I found this old article written by Walter: http://www.drdobbs.com/architecture-and-design/invariant-strings/228700475
Re: Questions about VisualD
On 17.10.2013 00:18, Namespace wrote: I've clicked on "Build Phobos browse info" and now I have absolute no idea how I can restore my old class view for my current project. Any suggestions? You want to remove the phobos info from the class view? You'll have to delete the generated json files from the folder given in the global "Visual D Settings" and restart VS. And it seems that VisualD ignores all of my Tasks. My Tasklist is always empty, whats wrong? Or is this not implemented? The Tasklist is not implemented.
Re: how would D be different if string were const(char)[]?
On Thursday, October 17, 2013 18:50:25 Dicebot wrote: > Well, yeah. it is memory safe but you can't slice a string and be > sure its value won't change silently - comparable semantical > safety disaster IMHO. Yeah. You have to be concerned about whether the values change, which makes the string situation considerably worse. But you have to be careful with the term "safe," because around here that almost always means memory safety. - Jonathan M Davis
Re: how would D be different if string were const(char)[]?
Well, yeah. it is memory safe but you can't slice a string and be sure its value won't change silently - comparable semantical safety disaster IMHO.
Re: how would D be different if string were const(char)[]?
On Thursday, October 17, 2013 15:18:19 Dicebot wrote: > On Thursday, 17 October 2013 at 13:08:18 UTC, Daniel Davidson > > wrote: > > If it would be no different then why prefer immutable(char)[] > > for string? > > Allocation-free slicing would have been illegal/unsafe then as > someone could have possibly modified underlying chars via mutable > reference. It wouldn't have to be illegal, and there's nothing unsafe about it. You can slice fully mutable arrays as much as you like without allocating any memory, and it's perfectly safe. However, you can't rely on the elements of a const array not being modified (because a mutable reference to the same data could modify it), and you can't share it across threads (as unlike immutable, const is not implicitly shared). So, dealing with strings if they were const(char)[] would probably be more bug-prone, and you'd be forced to dup your strings far more often in order to guarantee that they weren't being altered by a mutable reference somewhere. On top of that, you really wouldn't gain anything. So, it would definitely be a bad idea. Defaulting to immutable(char)[] makes a lot of sense, and you can still use const(char)[] or char[] if you want to, so it's not like it's particularly limiting either. - Jonathan M Davis
Re: Spawning a pty in D
On Thursday, 17 October 2013 at 13:53:39 UTC, Colin Grogan wrote: Anyone have any experience with this? I actually have been writing a terminal emulator for the last few weeks https://github.com/adamdruppe/terminal-emulator But for reading and writing from the pty, I just used the unix read and write syscalls instead of wrapping it. tbh I don't think there's much point in wrapping it; I think std.stdio.File is hard to use for any byte-at-a-time tasks anyway... If you do want to wrap it... well I think you'd have to modify phobos. The constructor that takes a FILE* is private. (std.stdio is itself just a wrapper around C's ) But I wouldn't even bother, it is easiest to just use "import core.sys.posix.unistd;" and then read()/write() to it. As an aside, I'd prefer to do this in a pure D way, and not have to compile against any external C libraries, does anyone know if it is possible to spawn a pty in D without resorting to calling external C libs? eh you could probably open /dev/ptmx and the other /dev/pts/* to test and reimplement what openpty does yourself, but there really is no pure D way, because it is perfectly normal in D to use C interfaces to talk to the operating system (it IS possible to use D without a C lib, but even druntime assumes it is there). I've never seen a unix install without the terminal util lib, so it is basically part of the OS.
Spawning a pty in D
Im having an issue
I can link to the C header file pty.h
(http://man7.org/linux/man-pages/man3/openpty.3.html) and call
forkpty like here:
http://dpaste.dzfl.pl/c3b07855
You have to compile that by linking with the util library
( add "libs-posix": ["util"] to dubs package.json )
For ease of reference, the main function is:
import std.stdio;
import pty;
void main(){
int master, slave;
char[16] name;
int pid = forkpty(&master, &name[0], null, null);
writefln("PID: %s", pid);
writefln("Master : %s", master);
writefln("Filename: %s", name);
}
If I run that I get:
~/Projects/D/dexpect$ ./dexpect
PID: 2224
Master : 3
Filename: /dev/pts/6�
(As you can see, I'm attempting to create a D version of the
expect library, good way to learn some of the intricacies of D
and will be useful I suspect)
What I get back is a file name and a File Descriptor to the
master side of the pty.
How do I then open this file and perform IO on it, preferably in
a D way (std.stdio.File hopefully) rather than through C's mess
of function calls?
If I open /dev/pts/6 with File("/dev/pts/6", "rw") and attempt to
write to it, I get a "Bad file descriptor" error.
Reading from that file blocks (which I think is correct...)
Anyone have any experience with this?
As an aside, I'd prefer to do this in a pure D way, and not have
to compile against any external C libraries, does anyone know if
it is possible to spawn a pty in D without resorting to calling
external C libs?
Sorry for the long post!
Thanks
Re: mutable, const, immutable guidelines
On Wednesday, 16 October 2013 at 20:33:23 UTC, H. S. Teoh wrote: On Wed, Oct 16, 2013 at 09:45:09PM +0200, Daniel Davidson wrote: On Wednesday, 16 October 2013 at 19:12:48 UTC, Dicebot wrote: [...] >I think any usage of immutable with types/entities not >initially >designed for immutability is an potential mistake and in that >sense it is good that change has broken the user code. Same >goes >for operating on immutable entity in generic code as if it is >a >value type without actually checking it via introspection. I don't disagree. Now, what does it mean to "initially design for immutability" and what are the guidelines. I thought that was kind of what we were talking about here. How to effectively use const and immutable. Thanks - this is most helpful. I'd say that user code should use const, not immutable (unless the library provides a way of constructing immutable instances of the type, of course), because immutable makes assumptions about implementation details, which should not be known unless you break encapsulation. As a user of a properly encapsulated type, I can't make any guarantees about its immutability; the best I can do is to promise I don't change it myself -- i.e., const. The distinction between user code and the rest (non-user code?) is not enough for me to get clear guidance. I am writing user code, the vast majority will be in libraries because I find that helpful. I would hate to have a separate set of rules for my code and the code I use. We should strive for guidelines that work in general - as in this is a good way to do D. But leaving "user code" aside, I like the argument and the vote for const over immutable. Immutable should be used in library code to provide strong guarantees to the user: since you're the one responsible for implementing the type, you're in the position to make guarantees about its uniqueness (and hence, immutability). I don't see the benefit of separating usage of types, usually via functions where mutability guarantees adorn the types, and implementation guarantees in a world with turtles all the way down. Maybe if those guarantees are totally hidden from user code via encapsulation then the impact of immutable and the difficulties of dealing with it are lessened. But then is the immutable guarantee for the user or just the developer of the encapsulated non-user code? How about this... here is a plea for ideas on a good use of immutable for a type with potentially mutable aliasing. String I think is a great use of immutable but char will likely never have aliasing introduced to it. At this stage I want the information for educational purposes, because based on this thread and my experimentation - Ali's presentation guidelines aside - I am about to abandon immutable altogether. The fight is too hard and my skills too weakened. [...] One general idea that was presented by Ali is that an immutable parameter means that not only are you guaranteeing that you will not change your data, but also that no one else, even in another thread will. That sounds appealing. After all, who doesn't want the data they are using in a function to not change from underneath them? I'm actually wary of this view, to be honest. An immutable parameter means you expect your *caller* to provide you with a value that cannot be changed, not by you, nor by anybody else, ever. Sure, it's nice to have, but that imposes a rather high bar on your callers. They have to be responsible to guarantee that whatever they hand to you cannot be changed by anything or anyone else, at any time. If they can do this, then great; if not, they won't be able to call your function. I now agree with you on this, especially since it goes with my new guideline of don't use immutable. Suppose you have highly structured, deeply nested reference data you read from a nosql DB. Surely there is opportunity and some benefit to use immutable? The result of the query is just a read only data source. But then that data will be consumed - presumably by functions with either immutable or const parameters. If all signatures use const then when can you benefit from the fact that the data is really immutable (by the time it gets to a function with const parm the fact that it really was/is immutable is lost. I'm of the view that code should only require the minimum of assumptions it needs to actually work. If your code can work with mutable types, then let it take a mutable (unqualified) type. If your code works without modifying input data, then let it take const. Only if your code absolutely will not work correctly unless the data is guaranteed to never change, ever, by anyone, should it take immutable. I don't have the instincts yet to really buy this. Perhaps a specific example would be helpful. I think most of the time `foo(ref const(T) t)` is written such that it is assumed t is never changed during the span of foo
Re: how would D be different if string were const(char)[]?
Small example, this is valid D:
void main()
{
char[] mut = "aaa".dup;
const(char)[] str = mut;
mut[1] = 'b';
assert (str == "aaa"); // oops
}
Re: how would D be different if string were const(char)[]?
On Thursday, 17 October 2013 at 13:08:18 UTC, Daniel Davidson wrote: If it would be no different then why prefer immutable(char)[] for string? Allocation-free slicing would have been illegal/unsafe then as someone could have possibly modified underlying chars via mutable reference.
how would D be different if string were const(char)[]?
If it would be no different then why prefer immutable(char)[] for string?
Re: Questions about VisualD
On Wednesday, 16 October 2013 at 22:18:57 UTC, Namespace wrote: I've clicked on "Build Phobos browse info" and now I have absolute no idea how I can restore my old class view for my current project. Any suggestions? And it seems that VisualD ignores all of my Tasks. My Tasklist is always empty, whats wrong? Or is this not implemented? No one knows what to do?
Re: Checking if a string contains a string?
On Thursday, October 17, 2013 08:27:17 Jeremy DeHaan wrote: > Maybe I am just tired or something, but I tried searching for a > way that is already included in phobos for checking if a string > contains another string and couldn't find anything. I managed to > write my own function for doing this, but I figured I would ask > in case I am crazy and just missed a built in method for doing > this. You can you use std.algorithm.canFind if all you care about is if one string is in the other. You can even use std.algorithm.boyerMooreFinder with find to use the boyer moore algorithm (though in that case, since for some reason, canFind doesn't have an overload which takes a BoyerMooreFinder, you'd have to use find and check whether the result was empty - and if it is, then the string wasn't there). But depending on what exactly you're trying to do, many of the functions in the "searching" section at the top of std.algorithm could be used: http://dlang.org/phobos/std_algorithm.html - Jonathan M Davis
Re: cannot call impure function ~this
In this case, the created struct literal A() will be moved out to the function getA(). So dtor is not called and compiler should not cause "cannot call impure function" error. I filed a bug report and posted possible compiler fix. http://d.puremagic.com/issues/show_bug.cgi?id=11286 https://github.com/D-Programming-Language/dmd/pull/2677 Kenji Hara Nice, thank you!
Re: cannot call impure function ~this
On Wednesday, 16 October 2013 at 07:58:09 UTC, Namespace wrote:
On Wednesday, 16 October 2013 at 07:32:27 UTC, monarch_dodra
wrote:
On Wednesday, 16 October 2013 at 07:27:25 UTC, Namespace wrote:
On Wednesday, 16 October 2013 at 07:23:45 UTC, monarch_dodra
wrote:
On Tuesday, 15 October 2013 at 21:37:40 UTC, Namespace wrote:
I get this error:
/d701/f223.d(11): Error: pure function 'f223.getA' cannot
call impure function 'f223.A.~this'
with this code:
import std.stdio;
struct A {
public:
~this() {
writeln("DTor");
}
}
A getA() pure nothrow {
return A();
}
void main()
{
A a = getA();
writeln("end of main");
}
But without pure and nothrow I get this output:
end of main
DTor
Why the compiler thinks that the function should/could call
A::~this?
It could have something to do with the fact that RVO is an
optimization *opportunity* that the compiler is allowed to
go for, even if it changes the program output.
Hoewever, being an *opportunity*, the compiler still has to
make sure the code is valid without said optimization, which
in this case, isn't: getA would destroy it's temporary after
blitting it on the stac, leading to an impure call.
So it _could_ be impure, but mostly it isn't, right?
I guess that's one way to put it. I'd say it *is* impure, but
all its impure bits have been optimized out. That's my
explanation anyways.
I'm curious: Is this a problem for you? The function calling
getA *can't* be pure either, so marking getA as pure is ...
I was going to say useless, but I guess "pure" is always an
optimization opportunity for the compiler.
I'd file an ER, you never know.
No, I was just curious what's behind it. So specifically why
the compiler could call the destructor.
In this case, the created struct literal A() will be moved out to
the function getA(). So dtor is not called and compiler should
not cause "cannot call impure function" error.
I filed a bug report and posted possible compiler fix.
http://d.puremagic.com/issues/show_bug.cgi?id=11286
https://github.com/D-Programming-Language/dmd/pull/2677
Kenji Hara
Re: Interfacing via Java Native Interface
Concluding, I can post the could if you like, or I can first try compiling it for ARM :-) This might help :- http://forum.dlang.org/post/dpzvxpncqabzxebgd...@forum.dlang.org
Re: mutable, const, immutable guidelines
On Wednesday, 16 October 2013 at 20:33:23 UTC, H. S. Teoh wrote:
I'm of the view that code should only require the minimum of
assumptions
it needs to actually work. If your code can work with mutable
types,
then let it take a mutable (unqualified) type. If your code
works
without modifying input data, then let it take const. Only if
your code
absolutely will not work correctly unless the data is
guaranteed to
never change, ever, by anyone, should it take immutable.
What about functions, which are not thread-safe?
auto percentageDistribution(const int[] percentages) {
[...]
assert (sum == 100);
[...]
}
Not a realistic example, but it should do. This function checks
that the sum of all percentages equals 100, but a concurrent
modification might break this. You could require an immutable
array to avoid that. Alternatively, the absence of "shared" could
be considered enough to express this.
Re: mutable, const, immutable guidelines
On Wednesday, 16 October 2013 at 20:33:23 UTC, H. S. Teoh wrote:
I'm of the view that code should only require the minimum of
assumptions
it needs to actually work. If your code can work with mutable
types,
then let it take a mutable (unqualified) type. If your code
works
without modifying input data, then let it take const. Only if
your code
absolutely will not work correctly unless the data is
guaranteed to
never change, ever, by anyone, should it take immutable.
Sounds reasonable. Which one of the following would you prefer?
foo1(const T t) {
takes_immutable(t.idup);
}
foo2(immutable(T) t) {
takes_immutable(t);
}
I'd say foo2, which puts the burden of the copy on the caller.
However, if the caller already has an immutable value an
unecessary copy is avoided.
