Re: Atomicity of file-copying/moving
On Tuesday, 16 May 2017 at 08:32:56 UTC, Nordlöw wrote: What's the status of atomicity of file-copying and -moving (renaming) using std.file on different platforms? For renaming that's a good question, but for copying, no-one should make atomicity guarantees. It's inherently non-atomic, and if you try to build an atomic wrapper around it (by trying to catch failure cases and deleting the file), you'd be ignoring cases like power failure, system hang, process crash. Some of those could be achieved on some OSes, but I doubt all of them can on all OSes.
Is dmc package still required?
I just updated to 2.074.0. I see there's still a README.TXT which tells me (on windows) to download dmc, "which contains the linker and necessary libraries". Is this out of date? I see a "link.exe" in the dmd package. Granted it's a bit older, but do I care?
Re: null as parametr
On Sunday, 31 July 2016 at 05:41:55 UTC, AntonSotov wrote: 2 Seb Thank you! is (T: typeof (null)) - very comfortable An example of Seb's warning: What happens if you have: string s = null; MyFunc(s); I'm guessing it doesn't do what you want. But it isn't clear what you want - null is a value, not a type. It's just as if you were saying: is (T: typeof (-3))
Re: Some asm help for the 'thiscall' calling convention?
On Thursday, 14 July 2016 at 14:01:29 UTC, Kagamin wrote: On Wednesday, 13 July 2016 at 22:30:51 UTC, Adam Sansier wrote: Um, no, I revived it so that people searching for answers wouldn't be led astray by idiots who pretend to know everything. My word is not COM specification of course, there's the official documentation and tons of books about COM, what one prefers, they all say the same thing, one doesn't need to trust me on that. This one is a particularly good read: https://www.amazon.com/Inside-Microsoft-Programming-Dale-Rogerson/dp/1572313498/ explains all fundamentals of COM. COM is a model; in practice people pick the parts they need, and often still call it "COM". I see it used all the time between components that are built with the same compiler build, and so can be lax about calling convention. I've also seen cases with QueryInterface but lacking AddRef and Release, and I've seen the reverse. All of these were called "COM" by many people. So even if there's some ISO standard saying that COM must include all these elements, saying "everything else is not COM" would hinder communication.
Re: A slice can lose capacity simply by calling a function
I really don't think that it's an issue in general, but if you do want to guarantee that nothing affects the capacity of your array, then you're going to need to either wrap all access to it I agree with everything Jonathan said in both threads EXCEPT that this is not an issue. The syntax slice.capacity gives the impression that 'capacity' is a property of the slice. Such lack of consistency is a SERIOUS issue for D, especially when it occurs in something as basic as an array. One other place I see this problem is the semantics of utf8 strings. This is DEADLY for D adoption. Personally, I think I'll be trying out Rust now, and checking back on these two issues later. This makes me sad, D is so promising ... but unfortunately the high standards it sets in many areas, are completely undercut by such basic problems. I work on large systems, and I can't imagine building a large system in this state.
Re: Reading unicode chars..
On Tuesday, 2 September 2014 at 14:06:04 UTC, seany wrote: How do I read unicode chars that has code points \u1FFF and higher from a file? file.getcw() reads only part of the char, and D identifies this character as an array of three or four characters. Importing std.uni does not change the behavior. Thank you. Maybe someone else here will recognize this, but for me you'd need to supply more information. Std.file doesn't have getcw, I see one in std.stream which has an outdated warning and that getcw is documented as implementation-specific. So what platform are you on? Better yet, can you make a small code sample that shows what you're seeing?
Re: Does D provide automatic dereferencing for accessing members through pointers?
On Friday, 29 August 2014 at 02:10:46 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
In D you just use '.' throughout and it Just Works(tm).
Unless the property you're accessing is also a pointer property,
like
sizeof. Then you have to be careful. The below prints 4 then 8
(on 32-bit):
unittest {
import core.stdc.stdlib : malloc, free;
struct Foo
{
public int bar, baz;
}
auto foo = cast(Foo*)malloc(Foo.sizeof);
import std.stdio;
writeln(foo.sizeof);
writeln((*foo).sizeof);
free(foo);
}
Do pointers have any other cases like this besides 'sizeof'?
I couldn't find a list of pointer properties in the docs (whereas
I know
where the list of array properties is).
Re: Does D provide automatic dereferencing for accessing members through pointers?
On Friday, 29 August 2014 at 05:05:55 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
On Fri, Aug 29, 2014 at 04:37:37AM +, Andrew Godfrey via
Digitalmars-d-learn wrote:
Unless the property you're accessing is also a pointer
property, like
sizeof. Then you have to be careful.
True. Though if you're writing generic code, chances are that
what you
want is the pointer size rather than the size of the referenced
object.
You only really get into trouble when you have to explicitly
work with
pointers.
Thanks for the link.
'sizeof' is not so bad anyway because it's a property of the type.
It would be worse if pointers had properties.
If you're insane enough to do the following, then this happens...
struct Foo {
int bar() { return 10; }
}
int bar(Foo f) { return 42; }
int bar(Foo *f) { return 43; }
int bar(Foo **f) { return 44; }
unittest {
Foo foo;
auto pfoo = foo;
assert((*pfoo).bar == 10);
assert(pfoo.bar == 10);
auto ppfoo = pfoo;
assert(ppfoo.bar == 44);
}
