Re: Deprecation

2019-01-18 Thread Steven Schveighoffer via Digitalmars-d-learn
On 1/18/19 5:53 PM, Ali wrote: Hello. I am having an issue with the code below. the out put after compiling is this : Deprecation: foreach: loop index implicitly converted from size_t to uint the code is : auto available = new int[cast(uint) max - min];     foreach (uint i, ref a;

Re: Deprecation

2019-01-18 Thread Neia Neutuladh via Digitalmars-d-learn
On Fri, 18 Jan 2019 22:53:23 +, Ali wrote: > Hello. I am having an issue with the code below. the out put after > compiling is this : > > Deprecation: foreach: loop index implicitly converted from size_t to > uint > > the code is : > > auto available = new int[cast(uint) max - min]; >

Re: Deprecation

2019-01-18 Thread H. S. Teoh via Digitalmars-d-learn
On Fri, Jan 18, 2019 at 10:53:23PM +, Ali via Digitalmars-d-learn wrote: > Hello. I am having an issue with the code below. the out put after > compiling is this : > > Deprecation: foreach: loop index implicitly converted from size_t to > uint > > the code is : > > auto available = new

Deprecation

2019-01-18 Thread Ali via Digitalmars-d-learn
Hello. I am having an issue with the code below. the out put after compiling is this : Deprecation: foreach: loop index implicitly converted from size_t to uint the code is : auto available = new int[cast(uint) max - min]; foreach (uint i, ref a; available)

Re: depreciated function delete

2019-01-18 Thread Ali via Digitalmars-d-learn
On Friday, 18 January 2019 at 21:37:38 UTC, Steven Schveighoffer wrote: On 1/18/19 4:32 PM, Ali wrote: On Friday, 18 January 2019 at 21:13:34 UTC, Steven Schveighoffer wrote: On 1/18/19 3:48 PM, alik wrote: Hi there. as you know delete function is depreciated. so I tried to use the __delete

Re: depreciated function delete

2019-01-18 Thread Steven Schveighoffer via Digitalmars-d-learn
On 1/18/19 4:32 PM, Ali wrote: On Friday, 18 January 2019 at 21:13:34 UTC, Steven Schveighoffer wrote: On 1/18/19 3:48 PM, alik wrote: Hi there. as you know delete function is depreciated. so I tried to use the __delete function for the code below: if (this.parse_buffer.length >

Re: depreciated function delete

2019-01-18 Thread Ali via Digitalmars-d-learn
On Friday, 18 January 2019 at 21:13:34 UTC, Steven Schveighoffer wrote: On 1/18/19 3:48 PM, alik wrote: Hi there. as you know delete function is depreciated. so I tried to use the __delete function for the code below: if (this.parse_buffer.length > this.parse_size)     {

Re: depreciated function delete

2019-01-18 Thread Steven Schveighoffer via Digitalmars-d-learn
On 1/18/19 3:48 PM, alik wrote: Hi there. as you know delete function is depreciated. so I tried to use the __delete function for the code below: if (this.parse_buffer.length > this.parse_size)     {     __delete(this.parse_buffer);    

depreciated function delete

2019-01-18 Thread alik via Digitalmars-d-learn
Hi there. as you know delete function is depreciated. so I tried to use the __delete function for the code below: if (this.parse_buffer.length > this.parse_size) { __delete(this.parse_buffer);

Re: byte + byte = int: why?

2019-01-18 Thread H. S. Teoh via Digitalmars-d-learn
On Fri, Jan 18, 2019 at 01:49:23PM -0500, Steven Schveighoffer via Digitalmars-d-learn wrote: > On 1/18/19 12:26 PM, Mek101 wrote: [...] > > Then why isn't int + int = long? If i did the example above, they > > wouldn't fit in a int for sure, yet the result is of the same type. > > Why should

Re: Deprecation: foreach: loop index implicitly converted from size_t to int

2019-01-18 Thread Jonathan M Davis via Digitalmars-d-learn
On Friday, January 18, 2019 8:34:22 AM MST Michael via Digitalmars-d-learn wrote: > On Friday, 18 January 2019 at 13:29:29 UTC, Adam D. Ruppe wrote: > > On Friday, 18 January 2019 at 12:27:17 UTC, Michael wrote: > >> This, to be, looks like quite the explicit conversion, no? > > > > Yeah, I

Re: byte + byte = int: why?

2019-01-18 Thread Steven Schveighoffer via Digitalmars-d-learn
On 1/18/19 12:26 PM, Mek101 wrote: On Friday, 18 January 2019 at 17:15:09 UTC, Steven Schveighoffer wrote: What is 127 + 127? Answer: 254. Which if converted to a byte is -127. Not what you might expect if you are doing addition. Quite similar to int.max + int.max Indeed. But this is where

Re: Alternative to Interfaces

2019-01-18 Thread Jonathan M Davis via Digitalmars-d-learn
On Friday, January 18, 2019 8:08:47 AM MST Kagamin via Digitalmars-d-learn wrote: > On Friday, 18 January 2019 at 00:08:00 UTC, 1001Days wrote: > > It works, but I have two questions regarding its efficacy: is > > it viable in the long run, and is it now possible to use > > delegates without the

Re: How to include curl.lib?

2019-01-18 Thread Andre Pany via Digitalmars-d-learn
On Friday, 18 January 2019 at 15:49:09 UTC, Head Scratcher wrote: On Thursday, 17 January 2019 at 20:42:48 UTC, Andre Pany wrote: You do not need to specify curl.lib but you have to bundle your executable with curl.dll. Recent Windows 10 versions might even come with curl.dll but I am not

Re: byte + byte = int: why?

2019-01-18 Thread Adam D. Ruppe via Digitalmars-d-learn
On Friday, 18 January 2019 at 17:26:35 UTC, Mek101 wrote: Then why isn't int + int = long? If i did the example above, they wouldn't fit in a int for sure, yet the result is of the same type. Why should byte be any different? Because C didn't define it that way. And C didn't define it that

Re: byte + byte = int: why?

2019-01-18 Thread H. S. Teoh via Digitalmars-d-learn
On Fri, Jan 18, 2019 at 05:26:35PM +, Mek101 via Digitalmars-d-learn wrote: > On Friday, 18 January 2019 at 17:15:09 UTC, Steven Schveighoffer wrote: > > What is 127 + 127? Answer: 254. Which if converted to a byte is > > -127. Not what you might expect if you are doing addition. > > Quite

Re: byte + byte = int: why?

2019-01-18 Thread H. S. Teoh via Digitalmars-d-learn
On Fri, Jan 18, 2019 at 05:09:52PM +, Mek101 via Digitalmars-d-learn wrote: > I have the following line of code: > > temp[fowardI] = temp[fowardI] + temp[backwardI]; > > Where temp is a byte array (byte[]). When I try to compile it dmd > gives me this error: > >

Re: byte + byte = int: why?

2019-01-18 Thread Adam D. Ruppe via Digitalmars-d-learn
On Friday, 18 January 2019 at 17:09:52 UTC, Mek101 wrote: Where temp is a byte array (byte[]) Oh btw, D's byte is signed, range -128 to 127, unlike C# where it is unsigned. C#'s `byte` is represented as D's `ubyte` (meaning "unsigned byte"), range 0-255.

Re: byte + byte = int: why?

2019-01-18 Thread Mek101 via Digitalmars-d-learn
On Friday, 18 January 2019 at 17:15:09 UTC, Steven Schveighoffer wrote: What is 127 + 127? Answer: 254. Which if converted to a byte is -127. Not what you might expect if you are doing addition. Quite similar to int.max + int.max In fact, D promotes all integral types smaller than int to int

Re: byte + byte = int: why?

2019-01-18 Thread Adam D. Ruppe via Digitalmars-d-learn
On Friday, 18 January 2019 at 17:09:52 UTC, Mek101 wrote: Meaning that the byte type doesn't have a + operator. Well, it DOES have a + operator, it just returns int that can be squished to a size if and only if the compiler proves it fits. A bit of background: the C language was designed on

Re: byte + byte = int: why?

2019-01-18 Thread Steven Schveighoffer via Digitalmars-d-learn
On 1/18/19 12:09 PM, Mek101 wrote: I have the following line of code:     temp[fowardI] = temp[fowardI] + temp[backwardI]; Where temp is a byte array (byte[]). When I try to compile it dmd gives me this error:     source/hash.d(11,25): Error: cannot implicitly convert expression

byte + byte = int: why?

2019-01-18 Thread Mek101 via Digitalmars-d-learn
I have the following line of code: temp[fowardI] = temp[fowardI] + temp[backwardI]; Where temp is a byte array (byte[]). When I try to compile it dmd gives me this error: source/hash.d(11,25): Error: cannot implicitly convert expression `cast(int)temp[fowardI] +

Re: How to include curl.lib?

2019-01-18 Thread Head Scratcher via Digitalmars-d-learn
On Thursday, 17 January 2019 at 20:42:48 UTC, Andre Pany wrote: You do not need to specify curl.lib but you have to bundle your executable with curl.dll. Recent Windows 10 versions might even come with curl.dll but I am not 100% sure. Thank you for your reply, Andre. My computer has

Re: Runtime heterogeneous collections?

2019-01-18 Thread Kagamin via Digitalmars-d-learn
On Thursday, 17 January 2019 at 02:21:21 UTC, Steven O wrote: void main() { alias Rec_type = Tuple!(int, "x", int, "y", int, "z"); RedBlackTree!Rec_type[1] test; } alias Rec_type1 = Tuple!(int, "x", int, "y", int, "z"); alias Rec_type2 = Tuple!(int, "x", int, "y", string, "z");

Re: Deprecation: foreach: loop index implicitly converted from size_t to int

2019-01-18 Thread Michael via Digitalmars-d-learn
On Friday, 18 January 2019 at 13:29:29 UTC, Adam D. Ruppe wrote: On Friday, 18 January 2019 at 12:27:17 UTC, Michael wrote: This, to be, looks like quite the explicit conversion, no? Yeah, I agree. But the language is silly. I just leave the type out of foreach and explicitly cast it inside

Re: Runtime heterogeneous collections?

2019-01-18 Thread Alex via Digitalmars-d-learn
On Friday, 18 January 2019 at 15:07:41 UTC, Steven Schveighoffer wrote: On 1/18/19 9:58 AM, Alex wrote: On Friday, 18 January 2019 at 13:31:28 UTC, Steven Schveighoffer wrote: [...] In this case, I would say Phobos lacks an appropriate interface definition, what do you think? But what is

Re: Runtime heterogeneous collections?

2019-01-18 Thread Steven Schveighoffer via Digitalmars-d-learn
On 1/18/19 10:10 AM, Neia Neutuladh wrote: On Fri, 18 Jan 2019 10:07:41 -0500, Steven Schveighoffer wrote: But what is the common interface between those 2 types? Even in Dcollections, where RedBlackTree came from, there was no interfaces that didn't specify the type they were dealing with. In

Re: Is there a nice syntax to achieve optional named parameters?

2019-01-18 Thread Neia Neutuladh via Digitalmars-d-learn
On Fri, 18 Jan 2019 09:39:31 +, John Burton wrote: > On Thursday, 17 January 2019 at 01:43:42 UTC, SrMordred wrote: > >> struct Config { >> string title; >> int width; >> } >> >> struct Window { >> this(Config config) > > It likely is a bad idea for a small struct like this

Re: Runtime heterogeneous collections?

2019-01-18 Thread Neia Neutuladh via Digitalmars-d-learn
On Fri, 18 Jan 2019 10:07:41 -0500, Steven Schveighoffer wrote: > But what is the common interface between those 2 types? Even in > Dcollections, where RedBlackTree came from, there was no interfaces that > didn't specify the type they were dealing with. In other words, there is > no common

Re: Alternative to Interfaces

2019-01-18 Thread Kagamin via Digitalmars-d-learn
On Friday, 18 January 2019 at 00:08:00 UTC, 1001Days wrote: It works, but I have two questions regarding its efficacy: is it viable in the long run, and is it now possible to use delegates without the GC? GC is just a handy memory management approach, it even works for C and C++, (example:

Re: Runtime heterogeneous collections?

2019-01-18 Thread Steven Schveighoffer via Digitalmars-d-learn
On 1/18/19 9:58 AM, Alex wrote: On Friday, 18 January 2019 at 13:31:28 UTC, Steven Schveighoffer wrote: To answer the OP, what he wants is an array of different RedBlackTrees. Since RedBlackTree is a class, his code is not far off from something that works. This does compile, and produces an

Re: Runtime heterogeneous collections?

2019-01-18 Thread Alex via Digitalmars-d-learn
On Friday, 18 January 2019 at 13:31:28 UTC, Steven Schveighoffer wrote: To answer the OP, what he wants is an array of different RedBlackTrees. Since RedBlackTree is a class, his code is not far off from something that works. This does compile, and produces an Object[]: auto arr = [

Re: Is there a nice syntax to achieve optional named parameters?

2019-01-18 Thread Kagamin via Digitalmars-d-learn
On Friday, 18 January 2019 at 09:39:31 UTC, John Burton wrote: It likely is a bad idea for a small struct like this but if it was much bigger would it makes sense to write this as :- this(const ref Config config) Which is what you might do in C++ or does D handle this differently?

Re: Runtime heterogeneous collections?

2019-01-18 Thread Steven Schveighoffer via Digitalmars-d-learn
On 1/17/19 11:06 PM, Jonathan M Davis wrote: On Thursday, January 17, 2019 1:21:41 AM MST Dukc via Digitalmars-d-learn wrote: On Thursday, 17 January 2019 at 02:27:20 UTC, Neia Neutuladh wrote: 1. Make a wrapper class. Now you can store Object[], or you can make a base class or base interface

Re: Deprecation: foreach: loop index implicitly converted from size_t to int

2019-01-18 Thread Adam D. Ruppe via Digitalmars-d-learn
On Friday, 18 January 2019 at 12:27:17 UTC, Michael wrote: This, to be, looks like quite the explicit conversion, no? Yeah, I agree. But the language is silly. I just leave the type out of foreach and explicitly cast it inside the body.

Re: Deprecation: foreach: loop index implicitly converted from size_t to int

2019-01-18 Thread Nicholas Wilson via Digitalmars-d-learn
On Friday, 18 January 2019 at 12:27:17 UTC, Michael wrote: Hello all, I am getting this deprecation warning when compiling using DMD64 D Compiler v2.084.0 on Linux. I'm a little unsure what the problem is, however, because the code producing these warnings tends to be of the form: foreach

Re: Deprecation: foreach: loop index implicitly converted from size_t to int

2019-01-18 Thread Steven Schveighoffer via Digitalmars-d-learn
On 1/18/19 7:27 AM, Michael wrote: Hello all, I am getting this deprecation warning when compiling using DMD64 D Compiler v2.084.0 on Linux. I'm a little unsure what the problem is, however, because the code producing these warnings tends to be of the form: foreach (int i, ref prop; props)

Deprecation: foreach: loop index implicitly converted from size_t to int

2019-01-18 Thread Michael via Digitalmars-d-learn
Hello all, I am getting this deprecation warning when compiling using DMD64 D Compiler v2.084.0 on Linux. I'm a little unsure what the problem is, however, because the code producing these warnings tends to be of the form: foreach (int i, ref prop; props) This, to be, looks like quite

Re: Is there a nice syntax to achieve optional named parameters?

2019-01-18 Thread evilrat via Digitalmars-d-learn
On Friday, 18 January 2019 at 09:39:31 UTC, John Burton wrote: On Thursday, 17 January 2019 at 01:43:42 UTC, SrMordred wrote: struct Config { string title; int width; } struct Window { this(Config config) It likely is a bad idea for a small struct like this but if it

Re: Is there a nice syntax to achieve optional named parameters?

2019-01-18 Thread John Burton via Digitalmars-d-learn
On Thursday, 17 January 2019 at 01:43:42 UTC, SrMordred wrote: struct Config { string title; int width; } struct Window { this(Config config) It likely is a bad idea for a small struct like this but if it was much bigger would it makes sense to write this as :-

Re: Read a text file in any position.

2019-01-18 Thread Giovanni Di Maria via Digitalmars-d-learn
On Friday, 18 January 2019 at 08:49:08 UTC, bauss wrote: On Friday, 18 January 2019 at 08:10:25 UTC, Giovanni Di Maria wrote: Hi All I have a text file like this: 11 22 33 44 55 66 77 .. I execute these functions: i = archive.readln(); i = archive.readln(); i

Re: Read a text file in any position.

2019-01-18 Thread bauss via Digitalmars-d-learn
On Friday, 18 January 2019 at 08:10:25 UTC, Giovanni Di Maria wrote: Hi All I have a text file like this: 11 22 33 44 55 66 77 .. I execute these functions: i = archive.readln(); i = archive.readln(); i = archive.readln(); i = archive.readln(); so "i" is

Read a text file in any position.

2019-01-18 Thread Giovanni Di Maria via Digitalmars-d-learn
Hi All I have a text file like this: 11 22 33 44 55 66 77 .. I execute these functions: i = archive.readln(); i = archive.readln(); i = archive.readln(); i = archive.readln(); so "i" is 44. Is there a method to move the pointer of file to beginning of