Re: UDP enhancement
> It's location in the class my not be the same but that is, in > general, irrelevant unless you are messing with the bits of the class. Actually we do this a lot in C++ where I work to ensure proper alignment. We are also starting to do this in D where we have C++ <-> D bindings so we can make our D structs exactly match our C++ structs in memory. Personally I see less benefit over: public @property int value; This approach is nice. It can be used both when layout is important and when it is "don't care" and is clearer. I can look at the struct and immediately read its memory footprint. Your suggested proposal cannot be used when layout is important as it is left to the compiler. It would require a workaround to coerce the compiler into submission, or additional compiler circuitry making it even more complex and slowing it down.
Re: reddit discussion on replacing Python in 0install
On Tuesday, 11 June 2013 at 10:55:16 UTC, Nick Sabalausky wrote: On Tue, 11 Jun 2013 09:09:43 +0200 Jacob Carlborg wrote: On 2013-06-11 08:38, Nick Sabalausky wrote: > I just tried both on Debian 6: > > nick@debian6:~$ cat 1< /dev/null > cfws > cat: write error: Bad file descriptor > nick@debian6:~$ echo meh 1< /dev/null > bash: echo: write error: Bad file descriptor > > Maybe OSX behaves differently? I get the same on Mac OS X 10.6.3 using bash. Is Andrei perhaps using another shell? I think I remember him saying somewhere that he uses zsh, although I can't look it up or test it on zsh at the moment. Just tried zsh, bash, sh.. $ echo meh 1< /dev/null zsh: no output bash: Bad file descriptor sh: Bad file descriptor $ echo meh 2< /dev/null zsh: meh bash: meh sh: meh
Re: Slow performance compared to C++, ideas?
Two quick notes: a) Profile first the optimise. b) This probably wouldn't make 4x difference but in the C++ code you're passing most objects around by ref. In the D version you're passing structs by value. They are only small but there's a tight loop of recursion to consider... That said, I don't know the details of D optimisation all that well and it may be a non-issue in release builds. Stewart
Re: Struct with default ctor (Was: [dmd-beta] dmd 2.064 beta take 2)
On Monday, 20 May 2013 at 14:57:17 UTC, Dicebot wrote:
On Monday, 20 May 2013 at 14:49:32 UTC, estew wrote:
Now I want to access a pointer, write code using it etc. But I
need to manually track at development time whether it is
NotNull!T, Null!T, Maybe!T, Option!T or whatever. I cannot
just have a pointer anymore, knowing it's initialised to null.
Yes and this is awesome. This is correctness enforced by type
system. Because if you _don't_ track this, you have a possible
error in your code. Only difference between nullable and
non-nullable pointers by default is that latter _force_ you to
write correct code. Which is good.
True I grant you that, it was late when I posted :-) I've
actually come around a bit on this after sleeping on it and
rereading some of the posts. I am starting to like NotNull!T idea
but I'm a bit hesitant still with Maybe!T, Option!T.
I cannot remember the last time our team had NULL pointer issues.
We have 102 devs on four integrated products. Big enough to not
know context your code might be used in nor the implementation
details of all libraries. The only pointer troubles we see are
forget to init to NULL or reset to NULL after freeing resources.
All devs know raw pointers are initialised to NULL. We are C/C++.
So non-null pointers wouldn't make much difference to us here,
although it may make the code more readable which is always a
good thing. D needs nullable pointers though, of some form.
But I'm not convinced it would cost us less to have NotNull!T and
Nullable!T. I feel it is cheaper to mindlessly write "if(a is
null) {}" when using pointers than to worry at design time what
the behaviour of a pointer should be.
Design time is the second most expensive developer time for us.
The most expensive dev. time is changing a design that turned out
to be incorrect, or is now outdated for whatever reason. Moving
pointer behaviour to be a design time issue rather than "knowing
it could be NULL so check it" could increase the probability of
redesign bugs creeping in.
Still, I am loving the discussion in this thread it's very
interesting from both sides.
Stewart
Re: Struct with default ctor (Was: [dmd-beta] dmd 2.064 beta take 2)
I'm surprised people still have problems with null pointers. I for one am glad D has null by default makes life easy coming from C++ and Java. I may have missed something but what happens with the following code if I could not have a null pointer? int*[] pntrs = new int*[10]; Would I need to write something like? Null!(int*)[] pntrs = new Null!(int*)[10]; Personally, I'd rather have null by default as I find it less noisy and I don't need it spelled out in the code, it is implied. No it sound like initalizing something to null, then initialize it properly, assume all over the place that it is initialized to something else, and in some rare code path it blows up. OK, so the D gurus kindly introduce for us NotNull!T, Maybe!T, Option!T and SegFault!T (just for me). Now I want to access a pointer, write code using it etc. But I need to manually track at development time whether it is NotNull!T, Null!T, Maybe!T, Option!T or whatever. I cannot just have a pointer anymore, knowing it's initialised to null. Now I realise it needs to change from NotNull!T to Maybe!T...great yet more refactoring. Ok refactoring done (yay sed!) but you know what, now I need to find every access to that pointer and check for null. More error prone than this: If you are in doubt (i.e. most multi-threaded apps) then check if null, with the added comfort that D has initialised all pointers to NULL for you. If still in doubt, don't use pointers. If you want non-null pointers (please no) then it is all or nothing. Allowing some pointers null and others not, via Nullable!T or NotNull!T, immediately adds another layer of complexity. I don't want to hear: D pointers cannot be null...well ok, they can sometimes, it depends, you'll have to read the code. But don't worry, D is very easy to read... My 1 cent. Disregard if I have totally misunderstood the thread, possible as it is very late! :-) Cheers, Stewart
MOVED: How does array assignment for different sized types work?
Oops, wrong forum. I've moved this to digitalmars.D.learn. Sorry!
How does array assignment for different sized types work?
void main() {
float[3] v1 = [1.0, 2.0, 3.0];// No error
float[3] v = [1.0, 2.0, 3.0].dup; // Fails at runtime with
error message
}
Why does the array assignment work when "dup" is not used. My
understanding is that arrays, like classes, are references.
So I declare v1 as a float[3] point it at a double[3] literal. Is
v1 now a double[3] or a float[3]? Is there an implicit cast from
double[3] to float[3]?
The dup, gives a compile time error and if cast to float[] it
gives a runtime error. This is all good, I just don't quite
understand how the ref assignment is working...
Thanks,
Stewart
Re: What am I missin with const?
Sorry all, I just need to read the docs more carefully and do more homework! Especially the section "Immutable Member Functions" under Const and Immutable. ...couldn't be more obvious :-) Cheers, Stewart
What am I missin with const?
Hi,
Just started in D a week back after years of C/C++ head bashing
and have to say language is fantastic.
I have a small misunderstanding regarding const...well ok, a
fundamental misunderstanding by the looks of it:)
class A
{
ulong[] values;
...
const ulong[] getValue() const {
return this.values;
}
}
But this fails to compile with the following message:
Error: cannot implicitly convert expression (this.values) of type
const(ulong[]) to ulong[]
I just do not see it in the code. The function is const, so
this.values is const, and I am just returning that as a const
ulong[]. Am I not???
I don't get it? Any help explaining why this does not compile
would be appreciated!
Thanks,
Stewart
