On Wednesday, 6 September 2023 at 12:15:02 UTC, Adam D Ruppe
wrote:
On Wednesday, 6 September 2023 at 12:04:40 UTC, d007 wrote:
extern(C) int test(ref scope const(ubyte)[32] b);
extern(C) int test(ref scope const(ubyte[32]) b);
These are the same thing since the ref cannot be rebound
anyway
On Wednesday, 6 September 2023 at 12:04:40 UTC, d007 wrote:
extern(C) int test(ref scope const(ubyte)[32] b);
extern(C) int test(ref scope const(ubyte[32]) b);
These are the same thing since the ref cannot be rebound anyway;
a static array just is its contents.
```d
extern(C) int test(ref scope const(ubyte)[32] b);
```
This will automatic become this in ctfe relection
```d
extern(C) int test(ref scope const(ubyte[32]) b);
```
LDC2 1.34.0 DMD v2.104.2
On Thursday, 27 October 2022 at 01:57:15 UTC, Salih Dincer wrote:
You should help the compiler with return type:
I love D, enjoys it when I code...:)
I played a little on the code, and the following is possible and
beautiful:
```d
// If you type auto instead of ubyte as return type
On Wednesday, 26 October 2022 at 21:10:54 UTC, 0xEAB wrote:
I know this is advanced stuff, but the compiler *could* even
prove that the calculation(s) won’t go beyond `ubyte.max`.
```d
//... => char?
return (decimal - ubyte(10) + ubyte('A'));
return '\xFF';
}
```
You should h
On 10/26/22 14:19, Ali Çehreli wrote:
>https://dlang.org/spec/type.html#integer-promotions
Reading "Value Range Propagation" further down that link, I learned that
e.g. masking 'decimal' with 0xf makes the code compile:
return ((decimal & 0xf) + ubyte('0'))
On 10/26/22 14:10, 0xEAB wrote:
> I guess, this fancy behavior is inherited from C.
Yes. It is called integer promotions:
https://dlang.org/spec/type.html#integer-promotions
(The next section is related as well.)
> I know this is advanced stuff, but the compiler *could* even prove that
>
```d
@safe:
void main()
{
import std.stdio : writeln;
writeln(ubyte(4).toHexDigit);
}
ubyte toHexDigit(ubyte decimal) pure nothrow @nogc
{
if (decimal < 10)
return (decimal + ubyte('0'));
if (decimal < 16)
return (decimal - ubyte(10) + ubyte('A'));
On 1/7/22 5:04 PM, eugene wrote:
On Friday, 7 January 2022 at 21:17:33 UTC, Steven Schveighoffer wrote:
In C you have one choice (printf), but that choice may not fit your
needs.
There are 2 buffers (RX one and TX one, both of 'reasonable' size)
(it's the effing echo-server, nothing more)
as the buffer size or
you received just error data.
Then, accessing the ubyte[] data directly via `.ptr`/ casting it
to char* without knowing the possible content seems not a good
idea - if you are using any function that returns bytes till it
finds a needle or terminating '\0'.
I know it's
On Thursday, 30 December 2021 at 09:34:27 UTC, eugene wrote:
```d
char[] s = cast(char[])ioCtx.buf[0 ..
strlen(cast(char*)ioCtx.buf.ptr) - 1];
// -1 is to eliminate terminating '\n'
writefln("got '%s' from '%s:%d'", s, client.addr, client.port);
```
Is there some more concise/elegant way to
On Friday, 7 January 2022 at 21:17:33 UTC, Steven Schveighoffer
wrote:
In C you have one choice (printf), but that choice may not fit
your needs.
There are 2 buffers (RX one and TX one, both of 'reasonable' size)
(it's the effing echo-server, nothing more)
* print content of RX-buffer,
On Friday, 7 January 2022 at 20:40:02 UTC, Adam D Ruppe wrote:
On Friday, 7 January 2022 at 20:33:05 UTC, eugene wrote:
* python guys have memory leaks
* js guys have memory leaks
GC isn't actually there to prevent memory leaks.
Aha, unless you'll build GC into OS core :)
Its main job is
On 1/7/22 2:54 PM, eugene wrote:
A couple of impressions...
* Does .until() make a copy of original string? And GC then will take
care of it?
No, `until` will iterate the string one character at a time until it
sees that character (excluding it). It doesn't make a copy of the data.
In
On Friday, 7 January 2022 at 20:33:05 UTC, eugene wrote:
* python guys have memory leaks
* js guys have memory leaks
GC isn't actually there to prevent memory leaks. Its main job is
to guard against use-after-free memory corruption bugs.
Actually, technically, the paradigm is "infinite
On Friday, 7 January 2022 at 20:08:00 UTC, H. S. Teoh wrote:
So it should be good even for GC-phobic code.
Nice term - "GC-phobic" :)
But looking from my cave - it's not a phobia, it's an
observation.
We've got a huge and complex project at my job, and...
* python guys have memory leaks
*
On Friday, 7 January 2022 at 20:08:00 UTC, H. S. Teoh wrote:
The simplest way to handle a C string from D is just to use
.fromStringz:
yes, this approach was used in some my previous traival
On Sunday, 2 January 2022 at 15:13:06 UTC, Paul Backus wrote:
On Sunday, 2 January 2022 at 09:15:32 UTC, eugene wrote:
```
p1.d(9): Error: cannot cast expression `until(b[], '\x0a',
Flag.yes)` of type `Until!("a == b", ubyte[], char)` to
`char[]`
```
Here's a working vers
On Fri, Jan 07, 2022 at 07:54:28PM +, eugene via Digitalmars-d-learn wrote:
[...]
> * Does .until() make a copy of original string? And GC then will take
> care of it?
No, it's one of the lazy range functions that lazily evaluates the
string and does not allocate.
> * So many ways to do
On Monday, 3 January 2022 at 02:50:46 UTC, Steven Schveighoffer
wrote:
On 1/2/22 4:15 AM, eugene wrote:
On Sunday, 2 January 2022 at 08:39:57 UTC, eugene wrote:
```d
writefln("'%s, world'", cast(char[])b[].until('\n'));
}
```
You missed a set of parentheses.
That was lack of attention
On 1/2/22 4:15 AM, eugene wrote:
On Sunday, 2 January 2022 at 08:39:57 UTC, eugene wrote:
```d
import std.stdio;
import std.string;
```
oops...
```d
import std.stdio;
import std.string;
import std.algorithm : until;
void main() {
ubyte[8] b = [0x68, 0x65, 0x6C, 0x6C, 0x6F, 0x0A, 0x00
On Sunday, 2 January 2022 at 09:15:32 UTC, eugene wrote:
```
p1.d(9): Error: cannot cast expression `until(b[], '\x0a',
Flag.yes)` of type `Until!("a == b", ubyte[], char)` to `char[]`
```
Here's a working version:
```d
import std.stdio;
import std.string;
import std.algorit
On Sunday, 2 January 2022 at 08:39:57 UTC, eugene wrote:
```d
import std.stdio;
import std.string;
```
oops...
```d
import std.stdio;
import std.string;
import std.algorithm : until;
void main() {
ubyte[8] b = [0x68, 0x65, 0x6C, 0x6C, 0x6F, 0x0A, 0x00, 0x00];
/* "hello\
)
```
instead of
```d
char[] s = cast(char[])b[0 .. $];
```
```d
import std.stdio;
import std.string;
void main() {
ubyte[8] b = [0x68, 0x65, 0x6C, 0x6C, 0x6F, 0x0A, 0x00, 0x00];
/* "hello\n\0\0" */
auto s = cast(string)b;
writefln("'%s, world'", s);
writefln(&q
ing;
void main() {
ubyte[8] b = [0x68, 0x65, 0x6C, 0x6C, 0x6F, 0x0A, 0x00, 0x00];
/* "hello\n\0\0" */
writefln("'%s, world'", cast(char[])b[].until('\n'));
}
```
```
@mono:~/2-coding/d-lang/misc$ dmd p1.d
p1.d(8): Error: no property `until` for type `ubyte[]`
```
``
On Thursday, 30 December 2021 at 18:07:15 UTC, eugene wrote:
On Thursday, 30 December 2021 at 17:52:20 UTC, eugene wrote:
much better than my initial
You can also write
```d
auto s = cast(string)b; // or cast(string)(b)
```
instead of
```d
char[] s = cast(char[])b[0 .. $];
```
On Thursday, 30 December 2021 at 09:34:27 UTC, eugene wrote:
I suspect the question was asked somewhere before.
If so just give a link.
Anyway:
```d
class IoContext {
...
ubyte[] buf;
...
this(uint bufSize) {
buf = new ubyte[bufSize];
}
}
```
The buffer contains
On Thursday, 30 December 2021 at 17:52:20 UTC, eugene wrote:
everything as needed.
Nevertheless, I do have zeroes in the buffer, so:
```d
import std.stdio;
import std.string;
void main() {
ubyte[8] b = [0x68, 0x65, 0x6C, 0x6C, 0x6F, 0x0A, 0x00, 0x00];
/* "hello\n\0\0" */
character, allowing `strip` to work.
Yes, you are right:
```d
import std.stdio;
import std.string;
void main() {
ubyte[8] b1 = [0x68, 0x65, 0x6C, 0x6C, 0x6F, 0x0A, 0x00,
0x00];
ubyte[8] b2 = [0x68, 0x65, 0x6C, 0x6C, 0x6F, 0x0A, 0x0A,
0x0A];
/* "hello\n\0\0" */
On Thursday, 30 December 2021 at 17:31:27 UTC, eugene wrote:
On Thursday, 30 December 2021 at 16:49:17 UTC, Tejas wrote:
I _think_ the above code is correct, please verify
Self-contained example:
```d
import std.stdio;
import std.string;
void main() {
ubyte[8] b = [0x68, 0x65, 0x6C
On Thursday, 30 December 2021 at 17:16:10 UTC, Tejas wrote:
I'll need to know the error message
There is none, see example in my prev message
because the following works:
```d
import std;
void main()
{
ubyte[] c ;
c.length = 100;
char[] arr = cast(char[])c[0 .. $];
foreach
On Thursday, 30 December 2021 at 16:49:17 UTC, Tejas wrote:
I _think_ the above code is correct, please verify
Self-contained example:
```d
import std.stdio;
import std.string;
void main() {
ubyte[8] b = [0x68, 0x65, 0x6C, 0x6C, 0x6F, 0x0A, 0x00, 0x00];
/* "hello\n\0\0" */
cast(char[])ioCtx.buf[0 .. $];
writefln("got '%s' from '%s:%d'", s.strip, client.addr,
client.port);
// strip does not work :(
```
I'll need to know the error message, because the following works:
```d
import std;
void main()
{
ubyte[] c ;
c.length = 100;
char[] a
On Thursday, 30 December 2021 at 16:49:17 UTC, Tejas wrote:
```d
char[] s = cast(char[])ioCtx.buf[0 .. $];// please remember
that in `[0 .. $]` last index is automatically `length - 1` but
just buf[$] will be an error since there the actual `length`
will be used
```
I _think_ the above code
On Thursday, 30 December 2021 at 09:34:27 UTC, eugene wrote:
```d
char[] s = cast(char[])ioCtx.buf[0 ..
strlen(cast(char*)ioCtx.buf.ptr) - 1];
// -1 is to eliminate terminating '\n'
writefln("got '%s' from '%s:%d'", s, client.addr, client.port);
```
Is there some more concise/elegant way to do
On Thursday, 30 December 2021 at 09:34:27 UTC, eugene wrote:
I suspect the question was asked somewhere before.
If so just give a link.
Anyway:
```d
class IoContext {
...
ubyte[] buf;
...
this(uint bufSize) {
buf = new ubyte[bufSize];
}
}
```
```d
class
On Thursday, 30 December 2021 at 16:00:59 UTC, Era Scarecrow
wrote:
The answer i ended up with was a quick conversion to a UTF in
order to print it. Seems you might have to convert to Latin-1.
For a moment I only have symbols from the lower half of ASCII
table.
I meant - can that be done as
On Thursday, 30 December 2021 at 09:34:27 UTC, eugene wrote:
The buffer contains (ascii) string terminated with '\n'. In
order to print it not as an array of numbers (buf is 1024 bytes
long), but as usual string I do
Few years ago i asked a similar question, not to do UTF-8 but to
do Ascii.
I suspect the question was asked somewhere before.
If so just give a link.
Anyway:
```d
class IoContext {
...
ubyte[] buf;
...
this(uint bufSize) {
buf = new ubyte[bufSize];
}
}
```
The buffer contains (ascii) string terminated with '\n'.
In order to print
On Thursday, 23 September 2021 at 00:30:45 UTC, Ruby The Roobster
wrote:
I figured out something weird. The variable 'i' is passed by
reference, yet the variable 'i' of the loop isn't being
incremented by posfunc. I assume foreach creates a new i
variable at the start of each new loop.
Yep:
On Thursday, 23 September 2021 at 00:17:49 UTC, jfondren wrote:
On Thursday, 23 September 2021 at 00:06:42 UTC, Ruby The
Roobster wrote:
So, I have the following function:
```d
writeln(tempcolor); //For this matter, the program
correctly reports tempcolor as 1...
for(ubyte j = 0;j
On Thursday, 23 September 2021 at 00:06:42 UTC, Ruby The Roobster
wrote:
So, I have the following function:
```d
writeln(tempcolor); //For this matter, the program
correctly reports tempcolor as 1...
for(ubyte j = 0;j < tempcolor; j++ /*trying ++j has same
effect*/ ) { //tempco
So, I have the following function:
```d
public Sprite ReadSpriteFromFile(immutable(char)[] filename) {
//Reads a sprite in my made up .spr format(trash, why does this
even exist)
ubyte[] ftext;
Color[] colors;
Point[][] points
On 8/10/20 2:53 PM, Bruce Carneal wrote:
No biggee but it looks like there is some duplicate code at the end of
the __alignPad unittest.
Hah! I think I copy-pasted that intending to write a new test, but then
tried it separately and found another issue
(typeid(__vector(ubyte[32])).talign
On Monday, 10 August 2020 at 13:52:46 UTC, Steven Schveighoffer
wrote:
On 8/9/20 8:46 AM, Steven Schveighoffer wrote:
On 8/9/20 8:37 AM, Steven Schveighoffer wrote:
I think this has come up before, there may even be a bug
report on it.
Found one, I'll see if I can fix the array runtime:
On Monday, 10 August 2020 at 13:52:46 UTC, Steven Schveighoffer
wrote:
On 8/9/20 8:46 AM, Steven Schveighoffer wrote:
On 8/9/20 8:37 AM, Steven Schveighoffer wrote:
I think this has come up before, there may even be a bug
report on it.
Found one, I'll see if I can fix the array runtime:
On 8/9/20 8:46 AM, Steven Schveighoffer wrote:
On 8/9/20 8:37 AM, Steven Schveighoffer wrote:
I think this has come up before, there may even be a bug report on it.
Found one, I'll see if I can fix the array runtime:
https://issues.dlang.org/show_bug.cgi?id=10826
Bruce, I have a PR to
On Sunday, 9 August 2020 at 12:37:06 UTC, Steven Schveighoffer
wrote:
On 8/9/20 8:09 AM, Bruce Carneal wrote:
[...]
All blocks in the GC that are more than 16 bytes are aligned by
32 bytes. You shouldn't have any 16 byte blocks here, because
each element is 32 bytes long.
However, if your
On 8/9/20 8:37 AM, Steven Schveighoffer wrote:
I think this has come up before, there may even be
a bug report on it.
Found one, I'll see if I can fix the array runtime:
https://issues.dlang.org/show_bug.cgi?id=10826
-Steve
On 8/9/20 8:09 AM, Bruce Carneal wrote:
On Sunday, 9 August 2020 at 09:58:18 UTC, Johan wrote:
On Sunday, 9 August 2020 at 01:03:51 UTC, Bruce Carneal wrote:
The .alignof attribute of __vector(ubyte[32]) is 32 but initializing
an array of such vectors via an assignment to .length has given me
On Sunday, 9 August 2020 at 10:02:32 UTC, kinke wrote:
On Sunday, 9 August 2020 at 01:03:51 UTC, Bruce Carneal wrote:
Is sub .alignof alignment expected here? IOW, do I have to
manually manage memory if I want alignments above 16?
IIRC, yes when using the GC, as that only guarantees 16-bytes
On Sunday, 9 August 2020 at 09:58:18 UTC, Johan wrote:
On Sunday, 9 August 2020 at 01:03:51 UTC, Bruce Carneal wrote:
The .alignof attribute of __vector(ubyte[32]) is 32 but
initializing an array of such vectors via an assignment to
.length has given me 16 byte alignment (and subsequent seg
On Sunday, 9 August 2020 at 05:49:23 UTC, user1234 wrote:
On Sunday, 9 August 2020 at 01:56:54 UTC, Bruce Carneal wrote:
On Sunday, 9 August 2020 at 01:03:51 UTC, Bruce Carneal wrote:
Manually managing the alignment eliminated the seg faulting.
Additionally, I found that
On Sunday, 9 August 2020 at 01:03:51 UTC, Bruce Carneal wrote:
Is sub .alignof alignment expected here? IOW, do I have to
manually manage memory if I want alignments above 16?
IIRC, yes when using the GC, as that only guarantees 16-bytes
alignment. Static arrays on the stack should be
On Sunday, 9 August 2020 at 01:03:51 UTC, Bruce Carneal wrote:
The .alignof attribute of __vector(ubyte[32]) is 32 but
initializing an array of such vectors via an assignment to
.length has given me 16 byte alignment (and subsequent seg
faults which I suspect are related).
Is sub .alignof
On Sunday, 9 August 2020 at 01:56:54 UTC, Bruce Carneal wrote:
On Sunday, 9 August 2020 at 01:03:51 UTC, Bruce Carneal wrote:
The .alignof attribute of __vector(ubyte[32]) is 32 but
initializing an array of such vectors via an assignment to
.length has given me 16 byte alignment
On Sunday, 9 August 2020 at 01:03:51 UTC, Bruce Carneal wrote:
The .alignof attribute of __vector(ubyte[32]) is 32 but
initializing an array of such vectors via an assignment to
.length has given me 16 byte alignment (and subsequent seg
faults which I suspect are related).
Is sub .alignof
The .alignof attribute of __vector(ubyte[32]) is 32 but
initializing an array of such vectors via an assignment to
.length has given me 16 byte alignment (and subsequent seg faults
which I suspect are related).
Is sub .alignof alignment expected here? IOW, do I have to
manually manage
On Saturday, 18 April 2020 at 15:20:42 UTC, kdevel wrote:
On Saturday, 18 April 2020 at 08:39:52 UTC, tsbockman wrote:
https://code.dlang.org/packages/checkedint
Hm.
$ dub test
Generating test runner configuration 'checkedint-test-library'
for 'library' (library).
Excluding package.d
On Saturday, 18 April 2020 at 15:20:42 UTC, kdevel wrote:
On Saturday, 18 April 2020 at 08:39:52 UTC, tsbockman wrote:
https://code.dlang.org/packages/checkedint
Hm.
$ dub test
Generating test runner configuration 'checkedint-test-library'
for 'library' (library).
Excluding package.d
On Saturday, 18 April 2020 at 08:39:52 UTC, tsbockman wrote:
[...]
You also get a deprecation message, about an integral
promotion not being performed. I believe the result is
correct and the warning can be ignored.
So the warning is a bug?
The deprecation message is a consequence of a
On Friday, 17 April 2020 at 21:25:34 UTC, kdevel wrote:
A curiosity. Usually you cast into the type on the left. But
Checked!(short, Throw) b = cast (Checked!(short, Throw)) a;
does not compile:
Error: template std.experimental.checkedint.Checked!(int,
Throw).Checked.opCast cannot
On Friday, 17 April 2020 at 21:25:34 UTC, kdevel wrote:
On Friday, 17 April 2020 at 12:59:20 UTC, Simen Kjærås wrote:
A curiosity. Usually you cast into the type on the left. But
Checked!(short, Throw) b = cast (Checked!(short, Throw)) a;
does not compile:
Error: template
On Friday, 17 April 2020 at 12:59:20 UTC, Simen Kjærås wrote:
[Deleted text makes sense]
And assigning from an int to a short may discard data, so it's
statically disallowed by Checked.
This is a deliberate design choice, and the appropriate way to
handle it is with a cast:
unittest {
On Friday, 17 April 2020 at 08:59:19 UTC, kdevel wrote:
On Friday, 17 April 2020 at 04:29:06 UTC, Meta wrote:
Unlike C/C++, char is not a numeric type in D; It's a UTF-8
code point:
Thanks, it's a code /unit/. main reads now:
void main ()
{
bar!ubyte;
bar!byte;
bar!ushort;
bar
On Friday, 17 April 2020 at 04:29:06 UTC, Meta wrote:
Unlike C/C++, char is not a numeric type in D; It's a UTF-8
code point:
Thanks, it's a code /unit/. main reads now:
void main ()
{
bar!ubyte;
bar!byte;
bar!ushort;
bar!short;
bar!uint;
bar!int;
bar!ulong;
bar!long
On Tuesday, 20 August 2019 at 09:49:21 UTC, Daniel Kozak wrote:
On Tue, Aug 20, 2019 at 11:30 AM ads via Digitalmars-d-learn
wrote:
you do not allow a person to think about a problem (and it’s easy
here).
you carried him through a puddle now, but when he dives into Sea
D, you will not be
On Tuesday, August 20, 2019 3:27:36 AM MDT ads via Digitalmars-d-learn
wrote:
> import std.stdio;
>
> ubyte[] extend(in uint[] arr)
> {
> ubyte[] result;
> foreach (n; arr)
> {
> if (n < 10)
> {
> result ~= n;
>
On Tuesday, 20 August 2019 at 09:27:36 UTC, ads wrote:
import std.stdio;
ubyte[] extend(in uint[] arr)
{
ubyte[] result;
foreach (n; arr)
{
if (n < 10)
result ~= n;
e
On Tue, Aug 20, 2019 at 11:30 AM ads via Digitalmars-d-learn
wrote:
>
>
> How can I get around this? I want to ensure that the array is not
> mutated in the function in the signature too.
>
https://run.dlang.io/is/tehp3j
import std.stdio;
ubyte[] extend(in uint[] arr)
{
import std.stdio;
ubyte[] extend(in uint[] arr)
{
ubyte[] result;
foreach (n; arr)
{
if (n < 10)
{
result ~= n;
// source/app.d(10,11): Error: cannot
append type const(uint) to type ub
On Wed, Aug 14, 2019 at 03:11:44PM +, berni via Digitalmars-d-learn wrote:
[...]
> but unfortunately this does not work:
>
> >ubyte[] convert_string_pair(string first, string second)
> >{
> >return 0x00 ~ first ~ 0x00 ~ second ~ 0x00;
I've got a function which takes two strings and should return
them as a ubyte[] with additional zero bytes in between and
around. This works:
ubyte[] convert_string_pair(string first, string second)
{
auto b = new ubyte[](0);
b ~= 0x00 ~ first ~ 0x00 ~ second ~ 0x00
On Wednesday, 14 August 2019 at 15:11:44 UTC, berni wrote:
The reason is, that this expression creates a string and not a
ubyte[]...
it should be ok to just cast it in this case.
On Monday, 5 August 2019 at 18:21:36 UTC, matheus wrote:
On Monday, 5 August 2019 at 01:41:06 UTC, Ali Çehreli wrote:
...
Two examples with foreach and ranges. The 'ubyte.max + 1'
expression is int. The compiler casts to ubyte (because we
typed ubyte) in the foreach and we cast to ubyte
On Monday, 5 August 2019 at 01:41:06 UTC, Ali Çehreli wrote:
...
Two examples with foreach and ranges. The 'ubyte.max + 1'
expression is int. The compiler casts to ubyte (because we
typed ubyte) in the foreach and we cast to ubyte in the range:
...
Maybe it was a bad example of my part
On 08/04/2019 11:12 AM, matheus wrote:
Hi,
The snippet below will produce an "infinite loop" because obviously
"ubyte u" will overflow after 255:
import std.stdio;
void main(){
ubyte u = 250;
for(;u<256;++u){
writeln(u);
}
}
Question: Is there
On Sunday, 4 August 2019 at 18:38:34 UTC, Paul Backus wrote:
...
Use std.experimental.checkedint:
import std.stdio;
import std.experimental.checkedint;
void main()
{
for(Checked!(ubyte, Throw) u = ubyte(250); u < 256; ++u) {
writeln(u.get);
}
}
An exception will be thrown w
overflow or even an warning (Only
if "some" flag was active).
If you want to prevent overflow you must either use BigInt or
wrap ubyte in a struct that doesn't allow overflow
Could you please elaborate about this struct wrapping? Do you
mean manually check on change?
overflow or even an warning (Only
if "some" flag was active).
Use std.experimental.checkedint:
import std.stdio;
import std.experimental.checkedint;
void main()
{
for(Checked!(ubyte, Throw) u = ubyte(250); u < 256; ++u) {
writeln(u.get);
}
}
An exception will be th
was active).
If you want to prevent overflow you must either use BigInt or
wrap ubyte in a struct that doesn't allow overflow
Could you please elaborate about this struct wrapping? Do you
mean manually check on change?
Matheus.
On Sunday, 4 August 2019 at 18:12:48 UTC, matheus wrote:
Hi,
The snippet below will produce an "infinite loop" because
obviously "ubyte u" will overflow after 255:
import std.stdio;
void main(){
ubyte u = 250;
for(;u<256;++u){
writeln(u);
}
}
Q
Hi,
The snippet below will produce an "infinite loop" because
obviously "ubyte u" will overflow after 255:
import std.stdio;
void main(){
ubyte u = 250;
for(;u<256;++u){
writeln(u);
}
}
Question: Is there a way (Flag) to prevent this?
Matheus.
(ubyte []) A;
auto q = cast (ubyte []) B;
assert (p == q);
}
```
is that it *isn't* reinterpreted in the case of an
enum / array literal, the cast actually transcribes similar to
your .map example. Look carefully at the difference of case A and
B in my example code: the only difference is whether the int
array uses auto or enum.
I'm not going from ubyte to int, I'm going
On Fri, Feb 15, 2019 at 04:17:12PM +, Dennis via Digitalmars-d-learn wrote:
> I assumed that casting an int[] to a ubyte[] would keep all bytes and
> quadruple the length of the original array. But when the array is a
> literal, it keeps the same length but truncates every in
I assumed that casting an int[] to a ubyte[] would keep all bytes
and quadruple the length of the original array. But when the
array is a literal, it keeps the same length but truncates every
int element to a ubyte:
```
import std.stdio;
void main()
{
// enum:
enum litA = [0x10203040
:
slice of static array temporary returned by fnv64.finish() assigned to
longer lived variable arr
What should use instead of?
I'm guessing you wrote:
ubyte[] arr = fnv64.finish();
??
You want:
auto arrtmp = fnv64.finish();
auto arr = arrtmp[];
Basically, what you were doing
On Wednesday, 23 May 2018 at 19:49:27 UTC, Jonathan M Davis wrote:
On Wednesday, May 23, 2018 19:36:07 Dr.No via
Digitalmars-d-learn wrote:
[...]
As the template constraint in the error message says, read
requires an input range. Static arrays are not input ranges.
You need to give it
On Wednesday, May 23, 2018 19:36:07 Dr.No via Digitalmars-d-learn wrote:
> read fails with both uint and ulong on 64bit platform:
>
> Error: template std.bitmanip.read cannot deduce function from
> argument types !(ulong)(ubyte[8]), candidates are:
> C:\ldc2-1.9.0-windows-x64\bi
read fails with both uint and ulong on 64bit platform:
Error: template std.bitmanip.read cannot deduce function from
argument types !(ulong)(ubyte[8]), candidates are:
C:\ldc2-1.9.0-windows-x64\bin\..\import\std\bitmanip.d(3213,3):
std.bitmanip.read(T, Endian endianness
On Monday, May 21, 2018 18:13:26 Dr.No via Digitalmars-d-learn wrote:
> I'm trying to do some hashing at compile time with xxhash
> algorithm but I get this error:
>
> ..\..\..\AppData\Local\dub\packages\xxhash-master\xxhash\src\xxhash.d(39,3
> 7): Error: reinterpreting cast f
I'm trying to do some hashing at compile time with xxhash
algorithm but I get this error:
..\..\..\AppData\Local\dub\packages\xxhash-master\xxhash\src\xxhash.d(39,37):
Error: reinterpreting cast from const(ubyte)* to const(uint)* is not supported
in CTFE
this is line 39
(https://github.com
On Tuesday, May 01, 2018 20:13:41 Dr.No via Digitalmars-d-learn wrote:
> I'm trying to do an optimization here: a hash function which
> expect a ubye[] array as argument, would just work if I cast
> string to ubyte[] but I need to convert it to upper case, so I'd
> like to do tha
On 05/01/2018 10:13 PM, Dr.No wrote:
I'm trying to do an optimization here: a hash function which expect a
ubye[] array as argument, would just work if I cast string to ubyte[]
but I need to convert it to upper case, so I'd like to do that lazily,
so that the byte is converted to its upper
I'm trying to do an optimization here: a hash function which
expect a ubye[] array as argument, would just work if I cast
string to ubyte[] but I need to convert it to upper case, so I'd
like to do that lazily, so that the byte is converted to its
upper case version soon as it's requested. I'm
On 03/17/2018 11:36 AM, Jonathan wrote:
`(a+b)&0xff` What is this syntax?! Could you give a link to this in the
D documentation?
Here is my description of bitwise AND:
http://ddili.org/ders/d.en/bit_operations.html#ix_bit_operations.&,%20bitwise%20and
The section titled "Masking" on the
the compiler that you want it
to fit there by doing stuff like
ubyte a = 200;
ubyte b = 100;
ubyte c = (a+b)&0xff;
or something like that, so the expression is specifically
proven to fit in the byte with compile time facts.
`(a+b)&0xff` What is this syntax?! Could you give a link to
this
actually doesn't need to do math that way, if you were
writing assembly, it would just work. This is just an annoying
rule brought over by C.
Can I prevent the initial implicit casts?
Nope, though you can help tell the compiler that you want it
to fit there by doing stuff like
ubyte a = 200
assembly, it would just work. This is just an annoying
rule brought over by C.
Can I prevent the initial implicit casts?
Nope, though you can help tell the compiler that you want it to
fit there by doing stuff like
ubyte a = 200;
ubyte b = 100;
ubyte c = (a+b)&0xff;
or something like that
1 - 100 of 329 matches
Mail list logo
