Re: Is this rdmd bug or my fault ?

[zabruk70 via Digitalmars-d-learn]

Can anybody explain:

Is dependencies file produced from command:
dmd -deps=moduleA.deps moduleA.d
must contains mention of moduleC?
Is dependencies file produced reccursively?

Thanks.

Re: Voldemort Type Construction Error

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, January 16, 2016 06:06:03 Kapps via Digitalmars-d-learn wrote:
> On Friday, 15 January 2016 at 20:04:47 UTC, Nordlöw wrote:
> > On Friday, 15 January 2016 at 16:51:24 UTC, Anon wrote:
> >> On Friday, 15 January 2016 at 14:04:50 UTC, Nordlöw wrote:
> >>> What have I missed?
> >>
> >> In line 126, `static struct Result()` is a template. Either
> >> drop the parens there, or change the call on line 187 to
> >> `Result!()(haystack, needles)`.
> >
> > Ahh, annoying mistake.
> >
> > Why is this allowed?
> >
> > /Per
>
> At least for functions, making them templates provides some
> benefits like inferring attributes. Not sure if it behaves the
> same way on structs by making all functions within it templates.

It does

struct S()
{
void foo()
{
}
}

void main() @safe
{
S!() s;
s.foo();
}

but having to do S!() for that rather than S is so ugly that I can't imagine
anyone actually doing it, whereas it's actually useful for functions -
particularly when you want to overload a templated function with one that
takes no template arguments. You _can_ finally overload those with normal
functions, but the overload rules don't work quite the same such that I
would normally avoid overloading a templated function with a non-templated
one.

- Jonathan M Davis

Re: c style casts

[Warwick via Digitalmars-d-learn]

On Friday, 15 January 2016 at 15:13:37 UTC, Jacob Carlborg wrote:

On 2016-01-15 11:16, Warwick wrote:
I though C style casts were not supported? But when I 
accidentaly did


int i;
if (uint(i) < length) 

it compiled and worked fine. Whys that?


Wouldn't a C style cast be:

int i;
if ((uint)i < length)


Yeah bad memory on my part, it's C++ cast, or one of them.

Convert some ints into a byte array without allocations?

[Samson Smith via Digitalmars-d-learn]

I'm trying to make a fast little function that'll give me a 
random looking (but deterministic) value from an x,y position on 
a grid. I'm just going to run each co-ord that I need through an 
FNV-1a hash function as an array of bytes since that seems like a 
fast and easy way to go. I'm going to need to do this a lot and 
quickly for a real time application so I don't want to waste a 
lot of cycles converting data or allocating space for an array.


In a nutshell how do I cast an int into a byte array?

I tried this:

byte[] bytes = cast(byte[])x;

Error: cannot cast expression x of type int to byte[]


What should I be doing instead?

Re: Functions that return type

[Timon Gehr via Digitalmars-d-learn]

On 01/16/2016 11:50 PM, data pulverizer wrote:

I guess the constraints are that of a static language.


(This is not true.)

Re: DUB - link error on Windows 10 64-bit

[Mike Parker via Digitalmars-d-learn]

On Saturday, 16 January 2016 at 20:28:02 UTC, Dibyendu Majumdar 
wrote:




I have installed DMD by unzipping the DMD archive (The 
installer does not work correctly on Windows 10). DUB installed 
as normal.


What problem did you have with the installer? Which version? I've 
installed DMD more than once on Windows 10 and it worked 
flawlessly.

Re: DUB - link error on Windows 10 64-bit

[Mike Parker via Digitalmars-d-learn]

On Sunday, 17 January 2016 at 02:48:47 UTC, Mike Parker wrote:
On Saturday, 16 January 2016 at 20:28:02 UTC, Dibyendu Majumdar 
wrote:




I have installed DMD by unzipping the DMD archive (The 
installer does not work correctly on Windows 10). DUB 
installed as normal.


What problem did you have with the installer? Which version? 
I've installed DMD more than once on Windows 10 and it worked 
flawlessly.


OK, nevermind. I've seen your other post.

Re: Functions that return type

[Ali Çehreli via Digitalmars-d-learn]

On 01/16/2016 02:50 PM, data pulverizer wrote:

> I guess I have been writing a lot of julia where I take
> creating arrays and tuples of types for granted. In this case
> types are of type DataType. [...] I guess the constraints are
> that of a static language.

Exactly. I am sure every D compiler has the equivalent of DataType and 
every type used in a program has instances of it but such information 
disappears by the end of compilation, except their properties in the 
form of TypeInfo as sarn has already mentioned.


Ali

Question about OutputRange and std.range: put

[Uranuz via Digitalmars-d-learn]

Hello to forum readers!
I have a question about using OutputRange and std.range: put. I 
have the following code snippet to illustrate my question:


import std.range, std.stdio, std.string;

void main()
{
string greating = "Hello, "   ;
string username = "Bob";

put(greating, username);
put(greating, "!");

writeln(greating);
}

It doesn't compile. It says following:

Compilation output:
/opt/compilers/dmd2/include/std/range/primitives.d(335): Error: 
static assert  "Cannot put a string into a string."
/d52/f530.d(8):instantiated from here: put!(string, 
string)


Documentation about std.range.put says that one of code snippets, 
where *put* applies is when second argument is array of elements 
(If I understand it correctly with my knowledge of English). 
Especially the following line is there in doc for usage scenario:


r.doPut([ e ]); R specifically accepts an E[].

Can I put range or array f elements as second argument of put or 
it works only at per element basis? I think writing multiple 
items at a time should be more effective but maybe it's not 
supported for OutputRange? Could someone explain?

Re: Convert some ints into a byte array without allocations?

[Samson Smith via Digitalmars-d-learn]

On Saturday, 16 January 2016 at 15:42:39 UTC, bearophile wrote:

Yazan D:

On Saturday, 16 January 2016 at 14:42:27 UTC, Yazan D wrote:

ubyte[] b = (cast(ubyte*) )[0 .. int.sizeof];


Better to use the actual size:

ubyte[] b = (cast(ubyte*) )[0 .. a.sizeof];

Bye,
bearophile


Good thinking, I won't have to change it around if I change the 
type of my co-ords later.


Thanks :)

Re: Question about OutputRange and std.range: put

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, January 16, 2016 12:11:11 Uranuz via Digitalmars-d-learn wrote:
> Hello to forum readers!
> I have a question about using OutputRange and std.range: put. I
> have the following code snippet to illustrate my question:
>
> import std.range, std.stdio, std.string;
>
> void main()
> {
>   string greating = "Hello, " ;
>   string username = "Bob";
>
>   put(greating, username);
>   put(greating, "!");
>
>   writeln(greating);
> }
>
> It doesn't compile. It says following:
>
> Compilation output:
> /opt/compilers/dmd2/include/std/range/primitives.d(335): Error:
> static assert  "Cannot put a string into a string."
> /d52/f530.d(8):instantiated from here: put!(string,
> string)
>
> Documentation about std.range.put says that one of code snippets,
> where *put* applies is when second argument is array of elements
> (If I understand it correctly with my knowledge of English).
> Especially the following line is there in doc for usage scenario:
>
> r.doPut([ e ]);   R specifically accepts an E[].
>
> Can I put range or array f elements as second argument of put or
> it works only at per element basis? I think writing multiple
> items at a time should be more effective but maybe it's not
> supported for OutputRange? Could someone explain?

There are a few problems here. First off, when put is used with an array, it
fills the array. It doesn't append to it. So, you can't use a string as an
output range, since its elements are immutable. Here's an example with
int[]:

auto arr = new int[](5);
assert(arr == [0, 0, 0, 0, 0]);
auto output = arr;

put(output, 1);
assert(arr == [1, 0, 0, 0, 0]);
assert(output == [0, 0, 0, 0]);

put(output, [2, 3, 4]);
assert(arr == [1, 2, 3, 4, 0]);
assert(output == [0]);

Add yes, put will take either an element or a range of elements - which is
why it's generally a bad idea to use put with UFCS (because an overloaded
put is unlikely to have all of the overloads that the free function
supports, but it will be used by the free function where appropriate).

Now, characters get a bit more interesting due to Unicode concerns. Narrow
strings - i.e. arrays of char or wchar - are not considered output ranges,
similar to how hasLength!string will return false (since with char (UTF-8)
and wchar (UTF-16) a single code point will not necessarily fit within a
single code unit, whereas with dchar (UTF-32), they're one and the same).
Whether that's how it _should_ work is debatable - particularly since the
main reason to not allow it is because with a short enough char[] or
wchar[], you can't guarantee that a dchar will fit, but you can't guarantee
that an input range of characters will fit either (and yet put accepts
those). But regardless, char[] and wchar[] are not currently considered
output ranges. So, if you want to use an array of characters as an output
range, it'll have to be dchar[].

Now, odds are what you really want is to use Appender. It _does_ append when
inserting elements rather than fill, and it _can_ be used with narrow
strings - including string. e.g.

auto output = appender!string();
assert(output.data.empty);
output.put("hello");
assert(output.data == "hello");

- Jonathan M Davis

Re: Convert some ints into a byte array without allocations?

[Samson Smith via Digitalmars-d-learn]

On Saturday, 16 January 2016 at 14:42:27 UTC, Yazan D wrote:

On Sat, 16 Jan 2016 14:34:54 +, Samson Smith wrote:


[...]


You can do this:
ubyte[] b = (cast(ubyte*) )[0 .. int.sizeof];

It is casting the pointer to `a` to a ubyte (or byte) pointer 
and then taking a slice the size of int.


This seems to work. Thankyou!

Re: Question about OutputRange and std.range: put

[Uranuz via Digitalmars-d-learn]

On Saturday, 16 January 2016 at 16:14:56 UTC, Jonathan M Davis 
wrote:
On Saturday, January 16, 2016 12:11:11 Uranuz via 
Digitalmars-d-learn wrote:

[...]


There are a few problems here. First off, when put is used with 
an array, it fills the array. It doesn't append to it. So, you 
can't use a string as an output range, since its elements are 
immutable. Here's an example with int[]:


[...]


Thanks for your response. After looking for some time in Phobos 
documentation I already found that it would be better to use 
Appender for this purpose. As far as I understand it allocates 
less often and I can reserve some memory from the start. I'll 
take this possibility into account when I'll do further small 
optimisations. Thanks again.

Re: Question about OutputRange and std.range: put

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, January 16, 2016 16:53:24 Uranuz via Digitalmars-d-learn wrote:
> On Saturday, 16 January 2016 at 16:14:56 UTC, Jonathan M Davis
> wrote:
> > On Saturday, January 16, 2016 12:11:11 Uranuz via
> > Digitalmars-d-learn wrote:
> >> [...]
> >
> > There are a few problems here. First off, when put is used with
> > an array, it fills the array. It doesn't append to it. So, you
> > can't use a string as an output range, since its elements are
> > immutable. Here's an example with int[]:
> >
> > [...]
>
> Thanks for your response. After looking for some time in Phobos
> documentation I already found that it would be better to use
> Appender for this purpose. As far as I understand it allocates
> less often and I can reserve some memory from the start. I'll
> take this possibility into account when I'll do further small
> optimisations. Thanks again.

Where using an array rather than Appender makes sense is when you want to
allocate a buffer and the reuse it over and over again rather than
allocating a new array and then growing it efficiently each time. But then
you have to be careful about how you use it, since arrays are quirkier when
using them as output ranges - and unlike Appender, they can fill up. So,
it's a question of what you're trying to do and what's reasonable in your
program.

- Jonathan M Davis

Re: Convert some ints into a byte array without allocations?

[Yazan D via Digitalmars-d-learn]

On Sat, 16 Jan 2016 14:34:54 +, Samson Smith wrote:

> I'm trying to make a fast little function that'll give me a random
> looking (but deterministic) value from an x,y position on a grid. I'm
> just going to run each co-ord that I need through an FNV-1a hash
> function as an array of bytes since that seems like a fast and easy way
> to go. I'm going to need to do this a lot and quickly for a real time
> application so I don't want to waste a lot of cycles converting data or
> allocating space for an array.
> 
> In a nutshell how do I cast an int into a byte array?
> 
> I tried this:
> 
> byte[] bytes = cast(byte[])x;
>> Error: cannot cast expression x of type int to byte[]
> 
> What should I be doing instead?

You can do this:
ubyte[] b = (cast(ubyte*) )[0 .. int.sizeof];

It is casting the pointer to `a` to a ubyte (or byte) pointer and then 
taking a slice the size of int.

Re: Convert some ints into a byte array without allocations?

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, January 16, 2016 14:34:54 Samson Smith via Digitalmars-d-learn 
wrote:
> I'm trying to make a fast little function that'll give me a
> random looking (but deterministic) value from an x,y position on
> a grid. I'm just going to run each co-ord that I need through an
> FNV-1a hash function as an array of bytes since that seems like a
> fast and easy way to go. I'm going to need to do this a lot and
> quickly for a real time application so I don't want to waste a
> lot of cycles converting data or allocating space for an array.
>
> In a nutshell how do I cast an int into a byte array?
>
> I tried this:
>
> byte[] bytes = cast(byte[])x;
> > Error: cannot cast expression x of type int to byte[]
>
> What should I be doing instead?

For this particular case, since you're hashing rather than doing something
like putting the resulting value on the wire, the cast that others suggested
may very well be the way to go, but the typesafe way to do the conversion
would be to use std.bitmanip.

int i = 12345;
auto arr = nativeToBigEndian(i);

where the result is ubyte[4], because the argument was an int. If it had
been a long, it would have been ubyte[8]. So, you avoid bugs where you get
the sizes wrong. The only reason that I can think of to _not_ do this in
your case would be speed, simply because you don't care about swapping the
endianness like you would when sending the data via a socket or whatnot. Of
course, if you knew that you were always going to be on little endian
machines, you could also use nativeToLittleEndian to avoid the swap, though
that still might be slower than a simple cast depending on the optimizer (it
uses a union internally).

But it will be less error-prone to use those functions, and if you _do_
actually need to swap endianness, then they're exactly what you should be
using. We've had cases that have come up where using those functions
prevented bugs precisely because the person writing the code got the sizes
wrong (and the compiler complained, since nativeToBigEndian and friends
deal with the sizes in a typesafe manner).

- Jonathan M Davis

Re: Convert some ints into a byte array without allocations?

[Yazan D via Digitalmars-d-learn]

On Sat, 16 Jan 2016 14:42:27 +, Yazan D wrote:
> 
> You can do this:
> ubyte[] b = (cast(ubyte*) )[0 .. int.sizeof];
> 
> It is casting the pointer to `a` to a ubyte (or byte) pointer and then
> taking a slice the size of int.

You can also use a union:

union Foo
{
  int i;
  ubyte[4] b;
}

// write to int part
Foo f = Foo(a);
// then read from ubyte part
writeln(foo.b);

ps. I am not sure of the aliasing rules in D for unions. In C, this is 
allowed, but in C++, this is undefined behaviour AFAIK.

Re: Convert some ints into a byte array without allocations?

[bearophile via Digitalmars-d-learn]

Yazan D:

On Saturday, 16 January 2016 at 14:42:27 UTC, Yazan D wrote:

ubyte[] b = (cast(ubyte*) )[0 .. int.sizeof];


Better to use the actual size:

ubyte[] b = (cast(ubyte*) )[0 .. a.sizeof];

Bye,
bearophile

Re: Convert some ints into a byte array without allocations?

[Samson Smith via Digitalmars-d-learn]

On Saturday, 16 January 2016 at 16:28:21 UTC, Jonathan M Davis 
wrote:
On Saturday, January 16, 2016 14:34:54 Samson Smith via 
Digitalmars-d-learn wrote:
I'm trying to make a fast little function that'll give me a 
random looking (but deterministic) value from an x,y position 
on a grid. I'm just going to run each co-ord that I need 
through an FNV-1a hash function as an array of bytes since 
that seems like a fast and easy way to go. I'm going to need 
to do this a lot and quickly for a real time application so I 
don't want to waste a lot of cycles converting data or 
allocating space for an array.


In a nutshell how do I cast an int into a byte array?

I tried this:

byte[] bytes = cast(byte[])x;
> Error: cannot cast expression x of type int to byte[]

What should I be doing instead?


For this particular case, since you're hashing rather than 
doing something like putting the resulting value on the wire, 
the cast that others suggested may very well be the way to go, 
but the typesafe way to do the conversion would be to use 
std.bitmanip.


int i = 12345;
auto arr = nativeToBigEndian(i);

where the result is ubyte[4], because the argument was an int. 
If it had been a long, it would have been ubyte[8]. So, you 
avoid bugs where you get the sizes wrong. The only reason that 
I can think of to _not_ do this in your case would be speed, 
simply because you don't care about swapping the endianness 
like you would when sending the data via a socket or whatnot. 
Of course, if you knew that you were always going to be on 
little endian machines, you could also use nativeToLittleEndian 
to avoid the swap, though that still might be slower than a 
simple cast depending on the optimizer (it uses a union 
internally).


But it will be less error-prone to use those functions, and if 
you _do_ actually need to swap endianness, then they're exactly 
what you should be using. We've had cases that have come up 
where using those functions prevented bugs precisely because 
the person writing the code got the sizes wrong (and the 
compiler complained, since nativeToBigEndian and friends deal 
with the sizes in a typesafe manner).


- Jonathan M Davis


If I'm hoping to have my hash come out the same on both bigendian 
and littleendian machines but not send the results between 
machines, should I take these precautions? I want one machine to 
send the other a seed (in an endian safe way) and have both 
machines generate the same hashes.


Here's the relevant code:

uint coordHash(int x, int y, uint seed){
seed = FNV1a((cast(ubyte*) )[0 .. x.sizeof], seed);
return FNV1a((cast(ubyte*) )[0 .. y.sizeof], seed);
}
// Byte order matters for the below function
uint FNV1a(ubyte[] bytes, uint code){
for(int iii = 0; iii < bytes.length; ++iii){
code ^= bytes[iii];
code *= FNV_PRIME_32;
}
return code;
}

Am I going to get the same outcome on all machines or would a 
byte array be divided up in reverse order to what I'd expect on 
some machines? If it is... I don't mind writing separate versions 
depending on endianness with 
version(BigEndian)/version(LittleEndian) to get around a runtime 
check... I'm just unsure of how endianness factors into the order 
of an array...

Re: Convert some ints into a byte array without allocations?

[Johannes Pfau via Digitalmars-d-learn]

Am Sat, 16 Jan 2016 18:05:46 +
schrieb Samson Smith :

> On Saturday, 16 January 2016 at 16:28:21 UTC, Jonathan M Davis 
> wrote:
> >
> > But it will be less error-prone to use those functions, and if 
> > you _do_ actually need to swap endianness, then they're exactly 
> > what you should be using. We've had cases that have come up 
> > where using those functions prevented bugs precisely because 
> > the person writing the code got the sizes wrong (and the 
> > compiler complained, since nativeToBigEndian and friends deal 
> > with the sizes in a typesafe manner).
> >
> > - Jonathan M Davis  
> 
> If I'm hoping to have my hash come out the same on both bigendian 
> and littleendian machines but not send the results between 
> machines, should I take these precautions? I want one machine to 
> send the other a seed (in an endian safe way) and have both 
> machines generate the same hashes.
> 
> Here's the relevant code:
> 
> uint coordHash(int x, int y, uint seed){
>   seed = FNV1a((cast(ubyte*) )[0 .. x.sizeof], seed);
>   return FNV1a((cast(ubyte*) )[0 .. y.sizeof], seed);
> }
> // Byte order matters for the below function
> uint FNV1a(ubyte[] bytes, uint code){
>   for(int iii = 0; iii < bytes.length; ++iii){
>   code ^= bytes[iii];
>   code *= FNV_PRIME_32;
>   }
>   return code;
> }
> 
> Am I going to get the same outcome on all machines or would a 
> byte array be divided up in reverse order to what I'd expect on 
> some machines? If it is... I don't mind writing separate versions 
> depending on endianness with 
> version(BigEndian)/version(LittleEndian) to get around a runtime 
> check... I'm just unsure of how endianness factors into the order 
> of an array...

If you use the simple pointer cast you will end up with different byte
orders on little vs big endian machines. Endianness does not affect
array order in general:

ubyte[] myArray = [1, 2, 3, 4];
myArray[0] == 1, myArray[1] == 2, ...


This is the same on big vs little endian machines. Endianness does
affect the representation of (multi-byte)numbers:

int a = 42;
ubyte[4] b = *cast(ubyte[4])

This will generate [42, 0, 0, 0] on little endian, [0, 0, 0, 42] on big
endian.


So if you want the same byte output for all architectures, just choose
either big or little endian (which one doesn't matter). Then convert
the values on the other architecture (e.g. if you choose little endian,
do nothing on little endian, swap bytes on big endian).


TLDR; Just use nativeToBigEndian or nativeToLittleEndian from
std.bitmanip, these functions do the right thing. These functions do not
use runtime checks, they use version(Big/LittleEndian)
internally. nativeToBigEndian does not do anything on big endian
machines, nativeToLittleEndian doesn't do anything on little endian
machines.

Re: Functions that return type

[data pulverizer via Digitalmars-d-learn]

On Saturday, 16 January 2016 at 21:22:15 UTC, data pulverizer 
wrote:
Is it possible to create a function that returns Type like 
typeof() does? Something such as:


Type returnInt(){
return int;
}

More to the point what is the Type of a type such as int?

Thanks


p.s. I am aware I could do typeof(1) to return int, but I am 
looking for something more elegant and some understanding.

Re: Functions that return type

[rsw0x via Digitalmars-d-learn]

On Saturday, 16 January 2016 at 21:22:15 UTC, data pulverizer 
wrote:
Is it possible to create a function that returns Type like 
typeof() does? Something such as:


Type returnInt(){
return int;
}


Functions return values, not types. You would use a template to 
"return" a type.




More to the point what is the Type of a type such as int?

Thanks


What is the value of a value such as 9? A type is a type, it does 
not have a type.


If this is not clear, I can try to make it clearer.

DUB - link error on Windows 10 64-bit

[Dibyendu Majumdar via Digitalmars-d-learn]

Hi

I am using DUB on Windows 10 64-bit with DMD. I have simple 
project with following configuration:


{
"name": "testing",
"description": "A minimal D application.",
"copyright": "Copyright © 2016, dibyendu",
"authors": ["dibyendu"],
"targetType": "dynamicLibrary",
"libs": ["somelib"],
"lflags-windows-x86_64": ["/LIBPATH:c:\\lib\\"],
}

I get link errors such as:

error LNK2019: unresolved external symbol _d_assert
error LNK2019: unresolved external symbol _d_unittest
error LNK2001: unresolved external symbol _DllMainCRTStartup

I have installed DMD by unzipping the DMD archive (The installer 
does not work correctly on Windows 10). DUB installed as normal.


Would appreciate any tips on what I am doing wrong.

Thanks and Regards
Dibyendu

Re: DUB - link error on Windows 10 64-bit

[Robert M. Münch via Digitalmars-d-learn]

On 2016-01-16 20:28:02 +, Dibyendu Majumdar said:

I have installed DMD by unzipping the DMD archive (The installer does 
not work correctly on Windows 10). DUB installed as normal.


Check your paths in sc.ini Looks like the D link libraries are not found.

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: Convert some ints into a byte array without allocations?

[Johannes Pfau via Digitalmars-d-learn]

Am Sat, 16 Jan 2016 15:46:00 +
schrieb Samson Smith :

> On Saturday, 16 January 2016 at 14:42:27 UTC, Yazan D wrote:
> > On Sat, 16 Jan 2016 14:34:54 +, Samson Smith wrote:
> >  
> >> [...]  
> >
> > You can do this:
> > ubyte[] b = (cast(ubyte*) )[0 .. int.sizeof];
> >
> > It is casting the pointer to `a` to a ubyte (or byte) pointer 
> > and then taking a slice the size of int.  
> 
> This seems to work. Thankyou!

You need to be careful with that code though. As you're taking the
address of the a variable, b.ptr will point to a. If a is on the stack
you must make sure you do not escape the b reference.


Another option is using static arrays:
ubyte[a.sizeof] b = *(cast(ubyte[a.sizeof]*));

Static arrays are value types. Whenever you pass b to a function it's
copied and you don't have to worry about the lifetime of a.

This pointer cast (int => ubyte[4]) is safe, but the inverse operation,
casting from ubyte[4] to int, is not safe. For the inverse operation
you'd have to use unions as shown in Yazans response.

Functions that return type

[data pulverizer via Digitalmars-d-learn]

Is it possible to create a function that returns Type like 
typeof() does? Something such as:


Type returnInt(){
return int;
}

More to the point what is the Type of a type such as int?

Thanks

Re: Functions that return type

[data pulverizer via Digitalmars-d-learn]

On Saturday, 16 January 2016 at 21:59:22 UTC, data pulverizer 
wrote:
On Saturday, 16 January 2016 at 21:22:15 UTC, data pulverizer 
wrote:
Is it possible to create a function that returns Type like 
typeof() does? Something such as:


Type returnInt(){
return int;
}

More to the point what is the Type of a type such as int?

Thanks


p.s. I am aware I could do typeof(1) to return int, but I am 
looking for something more elegant and some understanding.


Thanks for all the answers. I guess I have been writing a lot of 
julia where I take creating arrays and tuples of types for 
granted. In this case types are of type DataType. I am aware that 
you can create tuples of types in D, but then it cannot be easily 
manipulated e.g. (int, float)[0] = string or similar. You have to 
immediately alias it and there are a limited number of operations 
you can do with the resulting type. I guess the constraints are 
that of a static language.

Re: Functions that return type

[anonymous via Digitalmars-d-learn]

On Saturday, 16 January 2016 at 21:22:15 UTC, data pulverizer 
wrote:
Is it possible to create a function that returns Type like 
typeof() does? Something such as:


Type returnInt(){
return int;
}


No. A function cannot return a type. A template can evaluate to a 
type, though:



template returnInt(){
alias returnInt = int;
}



More to the point what is the Type of a type such as int?


Types don't have types. You can check if something is a type with 
an IsExpression: `is(T)` is true if T is a type.

Re: Functions that return type

[sarn via Digitalmars-d-learn]

On Saturday, 16 January 2016 at 21:22:15 UTC, data pulverizer 
wrote:
Is it possible to create a function that returns Type like 
typeof() does? Something such as:


Type returnInt(){
return int;
}


A type itself isn't a runtime value.  I think the closest thing 
is a TypeInfo object:


https://dlang.org/library/object/type_info.html
https://dlang.org/spec/expression.html#TypeidExpression

Re: Convert some ints into a byte array without allocations?

[tsbockman via Digitalmars-d-learn]

On Saturday, 16 January 2016 at 14:46:47 UTC, Yazan D wrote:

You can also use a union:

union Foo
{
  int i;
  ubyte[4] b;
}

// write to int part
Foo f = Foo(a);
// then read from ubyte part
writeln(foo.b);

ps. I am not sure of the aliasing rules in D for unions. In C, 
this is allowed, but in C++, this is undefined behaviour AFAIK.


I sure hope it's not undefined behaviour in D, seeing as this 
technique is used several places in the standard library.

Re: DUB - link error on Windows 10 64-bit

[Dibyendu Majumdar via Digitalmars-d-learn]

On Saturday, 16 January 2016 at 20:50:51 UTC, Robert M. Münch 
wrote:


Check your paths in sc.ini Looks like the D link libraries are 
not found.


Well as far as I can tell they are correct (unchanged from 
whatever the installer set them to):


; environment for both 32/64 bit
[Environment]
DFLAGS="-I%@P%\..\..\src\phobos" 
"-I%@P%\..\..\src\druntime\import"


; optlink only reads from the Environment section so we need this 
redundancy

; from the Environment32 section (bugzilla 11302)
LIB="%@P%\..\lib"


[Environment32]
LIB="%@P%\..\lib"
LINKCMD=%@P%\link.exe


[Environment64]
LIB="%@P%\..\lib64"

Re: DUB - link error on Windows 10 64-bit

[Mike Parker via Digitalmars-d-learn]

On Saturday, 16 January 2016 at 21:51:15 UTC, Dibyendu Majumdar 
wrote:




Well as far as I can tell they are correct (unchanged from 
whatever the installer set them to):


; environment for both 32/64 bit
[Environment]
DFLAGS="-I%@P%\..\..\src\phobos" 
"-I%@P%\..\..\src\druntime\import"


; optlink only reads from the Environment section so we need 
this redundancy

; from the Environment32 section (bugzilla 11302)
LIB="%@P%\..\lib"


[Environment32]
LIB="%@P%\..\lib"
LINKCMD=%@P%\link.exe


[Environment64]
LIB="%@P%\..\lib64"


Have you verified that this is the only DMD installation on your 
path?

function argument accepting function or delegate?

[Jon D via Digitalmars-d-learn]

My underlying question is how to compose functions taking 
functions as arguments, while allowing the caller the flexibility 
to pass either a function or delegate.


Simply declaring an argument as either a function or delegate 
seems to prohibit the other. Overloading works. Are there better 
ways?


An example:

auto callIntFn (int function(int) f, int x) { return f(x); }
auto callIntDel (int delegate(int) f, int x) { return f(x); }
auto callIntFnOrDel (int delegate(int) f, int x) { return f(x); }
auto callIntFnOrDel (int function(int) f, int x) { return f(x); }

void main(string[] args) {
alias AddN = int delegate(int);
AddN makeAddN(int n) { return x => x + n; }

auto addTwo = makeAddN(2);// Delegate
int function(int) addThree = x => x + 3;  // Function

// assert(callIntFn(addTwo, 4) == 6); // Compile error
// assert(callIntDel(addThree, 4) == 7);  // Compile error
assert(callIntDel(addTwo, 4) == 6);
assert(callIntFn(addThree, 4) == 7);
assert(callIntFnOrDel(addTwo, 4) == 6);
assert(callIntFnOrDel(addThree, 4) == 7);
}

---Jon

Re: function argument accepting function or delegate?

[rsw0x via Digitalmars-d-learn]

On Sunday, 17 January 2016 at 06:27:41 UTC, Jon D wrote:
My underlying question is how to compose functions taking 
functions as arguments, while allowing the caller the 
flexibility to pass either a function or delegate.


[...]


Templates are an easy way.

---
auto call(F, Args...)(F fun, auto ref Args args) { return 
fun(args); }

---
Would probably look nicer with some constraints from std.traits.

Re: function argument accepting function or delegate?

[Jon D via Digitalmars-d-learn]

On Sunday, 17 January 2016 at 06:49:23 UTC, rsw0x wrote:

On Sunday, 17 January 2016 at 06:27:41 UTC, Jon D wrote:
My underlying question is how to compose functions taking 
functions as arguments, while allowing the caller the 
flexibility to pass either a function or delegate.


[...]


Templates are an easy way.

---
auto call(F, Args...)(F fun, auto ref Args args) { return 
fun(args); }

---
Would probably look nicer with some constraints from std.traits.


Thanks much, that works!