My thoughts & experiences with D so far, as a novice D coder

Chris Cain clcain at uncg.edu
Thu Mar 28 15:22:48 PDT 2013


On Thursday, 28 March 2013 at 20:24:50 UTC, Vidar Wahlberg wrote:
> A bit on the side: It seems to me as importing std.bitmanip 
> somehow adds new properties to my array (".read()" and 
> ".write()", for example). Not necessarily a bad thing, more of 
> "I've not seen this before, I was expecting that I were to 
> concatenate the bytes from the conversion to my buffer using ~".

Sorry about the repeated postings ... I'm trying to read & answer 
it while also dealing with the norovirus :x

---

import std.stdio : writeln;
void main() {
     ubyte[] array;
     array ~= 5.toUbytes();
     array ~= 6.toUbytes();
     writeln(array);
}

ubyte[T.sizeof] toUbytes(T)(T val) @safe {
     ubyte[T.sizeof] buf;
     std.bitmanip.append!T(buf[], val);
     return buf;
}

---

I see your latest post and see that you don't necessary care how 
to do it, but, I figured I might as well provide yet another way 
that's @safe and simple.

On Thursday, 28 March 2013 at 20:24:50 UTC, Vidar Wahlberg wrote:
> Great, I have a solution, so I go back to my project and 
> implement it like I implemented it in my test code, but when I 
> compile my project after this addition I get a new cryptic 
> error message: "Error: __overloadset isn't a template".
> After digging a bit I realized that it's because in my project 
> I also import std.file, apparently there are some collisions 
> between std.bitmanip and std.file. Again it's solvable, but 
> it's yet another fight with the language/standard library. I 
> would also assume that it's not that uncommon for a module that 
> use std.bitmanip to also use std.file, meaning that this error 
> potentially may occur often.

Yeah, that's a bit of an issue. Weird cryptic error. Oh well, as 
a general rule, try to import only the parts of the module you're 
actually using. This does two great things: it prevents namespace 
pollution causing errors like you've seen, and it documents WHERE 
someone has to look in order to find documentation on a function 
you're using in your module.

As 1100110 noted, using a fully qualified ID is also a potential 
solution, especially if you only intend on using it in one place 
and the line isn't very noisy to begin with (as I showed in my 
example above).

> "why is this done like this, couldn't it be done much easier?".

Maybe. What needs to be made easier and how would you suggest to 
fix it? The error message, certainly. Probably the documentation 
too. But the API itself seems sane to me in this instance, it 
just needs a better description.


More information about the Digitalmars-d mailing list