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; availa
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];
>
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 int[c
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)
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 fu
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 > this.parse_si
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)
{
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);
this.parse_buffer.lengt
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);
this.parse_buff
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 byte
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 agree.
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 C
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 G
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 100%
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
wa
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 si
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:
>
> source/hash.d(11,25):
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.
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
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
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
`cast(int
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] + cast(int)temp[backwar
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 curl.exe
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");
Tuple!(R
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 t
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 t
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 o
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 but
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 interfa
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: gc
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 Ob
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 = [
redB
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?
F
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
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.
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
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)
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 the
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
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 :-
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 =
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 44
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
file
43 matches
Mail list logo
