Re: Linking a C program with D library
On Wednesday, 15 August 2018 at 06:39:50 UTC, Mike Parker wrote: String literals are implicitly convertible to const(char)* and are guaranteed to be nul-terminated like a C string, so this works: [...] Does that help? Yes, indeed. I think I possibly read about literal strings being nul-terminated somewhere but it must've slipped my mind.
Re: A devil self reference
On Wednesday, 15 August 2018 at 21:42:11 UTC, Jonathan M Davis
wrote:
What are you actually trying to do? Aside from the circular
reference issues, using the address of a struct like that is
very risky, because if the struct is ever moved, it will change.
Yeah... my functions are all ref. Or work with slices...
Also, even if the circular reference worked, the struct is then
in a dynamic array on the heap, whereas the dynamic array
itself is on the stack. So, you're trying to subtract a stack
pointer from a heap pointer.
Hm... didn't thought of that. Does this matter?
My current form is like that:
´´´
void main()
{
S.c.sarr.length = 5;
S.c.sarr[2 .. 4].usefulFun;
}
struct Container
{
S[] sarr;
}
struct S
{
static Container c;
size_t id()
{
return - c.sarr.ptr;
}
void anotherUsefulFun()
{
/*
works on "neighbors" of this, which are only
available,
if c.sarr is "well-known"
*/
}
}
void usefulFun(S[] slice)
{
import std.stdio;
writeln(slice[0].id);
}
´´´
It works. After a lot of debugging and head aches, it works as I
want to. But, only until I try to copy the array, as you said.
I'm aware of the problem, and I worked it out so far, that on
copies of the array sarr only the operations are done, which do
not need the pointer stuff.
Like dumping the data, for example, or querying elementary
properties. Even querying for id on a array copy is ok, if I do
it with another function, let's call it indexOf :)
What doesn't work are the calls to "neighbor"-acting functions,
but these are not needed on sarr copies.
The project is almost finished, so, I'm mainly after a learn
effect now. What I'm looking for, is something what would
simplify my structure. So... I can think at least of two things:
1. something, where I don't need the dangerous pointer stuff.
2. something, which works well after I copy it.
If the circular stuff worked, it would simplify my life a lot. I
could define some constructors, for copying data between arrays,
whereas the pointer stuff would maintain itself, as it would be
"integrated" into the type. But ok, I see, that this is at least
kind of strange...
Re: A devil self reference
On Wednesday, August 15, 2018 10:40:49 AM MDT Alex via Digitalmars-d-learn
wrote:
> Hi all.
> Finally, I arrived at something like this:
>
> ´´´
> void main()
> {
> S!(sarr)[] sarr;
> }
>
> struct S(alias Reference)
> {
> size_t id()
> in
> {
> // not static assert, only because a pointer is never known in
> advance
> assert(Reference.ptr <= );
> }
> do
> {
> return - Reference.ptr;
> }
> }
> ´´´
>
> Of course, this does not compile, because I try to use an
> identifier before I defined it.
>
> However, the reason I dare to ask is, that all the stuff with the
> weird self reference is compile time known.
>
> So, is there a possibility to define something like the thing
> above?
What are you actually trying to do? Aside from the circular reference
issues, using the address of a struct like that is very risky, because if
the struct is ever moved, it will change. Also, even if the circular
reference worked, the struct is then in a dynamic array on the heap, whereas
the dynamic array itself is on the stack. So, you're trying to subtract a
stack pointer from a heap pointer.
- Jonathan M Davis
Re: Array!bool -> Chunks -> foreach: out of bounds
On 8/15/18 2:12 PM, Steven Schveighoffer wrote: https://issues.dlang.org/show_bug.cgi?id=19171 PR: https://github.com/dlang/phobos/pull/ -Steve
Re: Array!bool -> Chunks -> foreach: out of bounds
On 8/15/18 2:05 PM, Steven Schveighoffer wrote: On 8/15/18 12:27 PM, 0xEAB wrote: On Wednesday, 15 August 2018 at 15:13:50 UTC, Kagamin wrote: It's a bug: Is it a known one? Nope. And I figured out the problem. Will submit a fix. https://issues.dlang.org/show_bug.cgi?id=19171 -Steve
Re: Array!bool -> Chunks -> foreach: out of bounds
On 8/15/18 12:27 PM, 0xEAB wrote: On Wednesday, 15 August 2018 at 15:13:50 UTC, Kagamin wrote: It's a bug: Is it a known one? Nope. And I figured out the problem. Will submit a fix. -Steve
Re: A devil self reference
On Wednesday, 15 August 2018 at 16:40:49 UTC, Alex wrote:
Hi all.
Finally, I arrived at something like this:
´´´
void main()
{
S!(sarr)[] sarr;
}
struct S(alias Reference)
{
size_t id()
in
{
// not static assert, only because a pointer is never known
in advance
assert(Reference.ptr <= );
}
do
{
return - Reference.ptr;
}
}
´´´
Of course, this does not compile, because I try to use an
identifier before I defined it.
However, the reason I dare to ask is, that all the stuff with
the weird self reference is compile time known.
So, is there a possibility to define something like the thing
above?
containment in a container is also wanted...
struct Container
{
S!(sarr)[] sarr;
}
but also not possible in this form because of a circular
reference.
A devil self reference
Hi all.
Finally, I arrived at something like this:
´´´
void main()
{
S!(sarr)[] sarr;
}
struct S(alias Reference)
{
size_t id()
in
{
// not static assert, only because a pointer is never known in
advance
assert(Reference.ptr <= );
}
do
{
return - Reference.ptr;
}
}
´´´
Of course, this does not compile, because I try to use an
identifier before I defined it.
However, the reason I dare to ask is, that all the stuff with the
weird self reference is compile time known.
So, is there a possibility to define something like the thing
above?
Re: Array!bool -> Chunks -> foreach: out of bounds
On Wednesday, 15 August 2018 at 15:13:50 UTC, Kagamin wrote: It's a bug: Is it a known one?
Re: Array!bool -> Chunks -> foreach: out of bounds
It's a bug: auto s=ar[]; s.popFront(); auto s1=s[0..0]; //out of bounds
Re: Convert output of map() to array of strings
On Wednesday, 15 August 2018 at 13:53:02 UTC, Andrey wrote:
Hello,
I have the following code:
string[] list;
string text;
// ...
enum pattern = ctRegex!`^[0-9]+$`;
list = text.split('\n').map!(line =>
line.matchFirst(pattern).hit);
Compiler says that it can't convert result of map function to
string[]...
The result of `map` is a lazily-evaluated range. To convert it to
an array, use `std.array.array`:
import std.array: array;
//...
list = text
.split('\n')
.map!(line => line.matchFirst(pattern).hit)
.array;
Convert output of map() to array of strings
Hello,
I have the following code:
string[] list;
string text;
// ...
enum pattern = ctRegex!`^[0-9]+$`;
list = text.split('\n').map!(line =>
line.matchFirst(pattern).hit);
Compiler says that it can't convert result of map function to
string[]...
What I want:
1. Split some text into lines using separator '\n'.
2. Apply to each line a regex pattern and extract matched text.
3. Result of these operations assign to variable of type string[].
Tried to do this:
list = text.split('\n').map!(line =>
line.matchFirst(pattern).hit).to!(string[]);
but no success...
Array!bool -> Chunks -> foreach: out of bounds
core.exception.AssertError@/src/phobos/std/container/array.d(1667): Using out
of bounds indexes on an Array
Should this code[1] really try to access something out of bounds
and assert?
Also: shouldn't this assertion[2] be perhaps inside
`version(D_NoBoundsChecks){} else { ... }` block?
Kind regards,
Elias
[1] https://run.dlang.io/is/l6eyCF
[2]
https://github.com/dlang/phobos/blob/v2.081.2/std/container/array.d#L1667
Re: tryTo: non-throwing variant of std.conv.to
On Wednesday, 15 August 2018 at 10:38:23 UTC, Jonathan M Davis wrote: Would it be sane to add these to std.conv alongside existing std.conv.to so that underlying logic in std.conv.to can be reused? If so, AFAICT, existing std.conv.to should be implemented on Put something together to get early feedback on the idea: https://github.com/dlang/phobos/pull/6665
Re: tryTo: non-throwing variant of std.conv.to
On Wednesday, 15 August 2018 at 09:26:26 UTC, Seb wrote: If so, AFAICT, existing std.conv.to should be implemented on top of std.conv.tryTo. Well, for now you can use `ifThrown` from std.exception: https://dlang.org/phobos/std_exception.html#ifThrown --- "foo".to!int.ifThrown(42) But the whole idea is to avoid both throwing and catching exceptions at all. As this results in orders of magnitudes of drop in performance for the throwing case. That's the reason why Folly has this aswell. Thanks anyway, Seb.
Re: Concat enum of strings into one string
On Tuesday, 14 August 2018 at 16:03:05 UTC, vit wrote:
import std.traits : EnumMembers;
import std.string : join;
import std.algorithm : map;
pragma(msg, [EnumMembers!Type].map!(x => cast(string)x).join("
"));
Thank you!
Jonathan M Davis, I understood.
Re: is this a betterC bug ?
On Wednesday, 15 August 2018 at 08:14:53 UTC, Petar Kirov
[ZombineDev] wrote:
It's not a bug, it's all about how the type system is set up.
The type of an array literal expression like `[1, 2, 3]` is
`int[]` (a slice of an array of ints), so no matter if you do:
auto readonly(T)(const(T)[] x) { return x; }
auto arr1 = [1, 2, 3];
auto arr2 = [1, 2, 3].readonly;
constarr3 = [1, 2, 3];
enum arr4 = [1, 2, 3];
static immutable arr5 = [1, 2, 3];
scopearr6 = [1, 2, 3];
In all instances the type will be `int[]` modulo type
qualifiers.
Static arrays are completely different types, that just happen
to accept
assignments from slices. Their two defining properties are:
1. Their length is fixed at compile-time, meaning that you can
do:
import std.array, std.meta;
auto x = [1, 2, 3, 4, 5].staticArray;
enum length = x.length;
pragma (msg, length);
alias seq = AliasSeq!(0, 42, length);
static foreach (i; 0 .. length) { }
static foreach (i; seq) { }
2. Where slices are reference types, static arrays are value
types which means that each assignment will copy an entire
array.
Basically they behave like a `struct { int _arr_0 = 0, _arr_1 =
1, _arr_2 = 2; }`.
https://run.dlang.io/is/iD9ydu
Thanks for the detailed explanation; it make sense now.
Mike
Re: tryTo: non-throwing variant of std.conv.to
On Wednesday, August 15, 2018 3:21:29 AM MDT Per Nordlöw via Digitalmars-d-
learn wrote:
> Have anybody thought about non-throwing variants of std.conv.to
> typically named `tryTo`
> similar to what Folly
>
> https://github.com/facebook/folly/blob/master/folly/docs/Conv.md#non-throw
> ing-interfaces
>
> does, for instance, as
>
> tryTo(str).then([](int i) { use(i); });
>
> ?
>
> Would it be sane to add these to std.conv alongside existing
> std.conv.to so that underlying logic in std.conv.to can be reused?
>
> If so, AFAICT, existing std.conv.to should be implemented on top
> of std.conv.tryTo.
Yes. I've considered writing a set of conversion functions like std.conv.to
which return a Nullable!T (where the target type is T) and return
Nullable!T.init when the conversion fails rather than throwing, and they
really should be in std.conv alongside to, reusing logic as much as
reasonably possible, but it's not a small project. It's come up off and on
for a while now, so I expect that someone will do it eventually (and I may
at some point if no one else does), but obviously, someone has to actually
take the time to do it, or it's not going to happen.
- Jonathan M Davis
Re: tryTo: non-throwing variant of std.conv.to
On Wednesday, 15 August 2018 at 09:21:29 UTC, Per Nordlöw wrote:
Have anybody thought about non-throwing variants of std.conv.to
typically named `tryTo`
similar to what Folly
https://github.com/facebook/folly/blob/master/folly/docs/Conv.md#non-throwing-interfaces
does, for instance, as
tryTo(str).then([](int i) { use(i); });
?
Would it be sane to add these to std.conv alongside existing
std.conv.to so that underlying logic in std.conv.to can be
reused?
If so, AFAICT, existing std.conv.to should be implemented on
top of std.conv.tryTo.
Well, for now you can use `ifThrown` from std.exception:
https://dlang.org/phobos/std_exception.html#ifThrown
---
"foo".to!int.ifThrown(42)
---
https://run.dlang.io/is/nlZKOw
Usage of optionals/nullables is sadly not very common in Phobos
and I think if we want everything to work nicely, we probably
have to start a new standard library (or do massive refactorings
of the existing one.)
tryTo: non-throwing variant of std.conv.to
Have anybody thought about non-throwing variants of std.conv.to
typically named `tryTo`
similar to what Folly
https://github.com/facebook/folly/blob/master/folly/docs/Conv.md#non-throwing-interfaces
does, for instance, as
tryTo(str).then([](int i) { use(i); });
?
Would it be sane to add these to std.conv alongside existing
std.conv.to so that underlying logic in std.conv.to can be reused?
If so, AFAICT, existing std.conv.to should be implemented on top
of std.conv.tryTo.
Re: is this a betterC bug ?
On Wednesday, 15 August 2018 at 08:14:53 UTC, Petar Kirov [ZombineDev] wrote: https://run.dlang.io/is/iD9ydu I made a typo in one of the comments. Here's the fixed version: https://run.dlang.io/is/HRqYcZ
Re: is this a betterC bug ?
On Tuesday, 14 August 2018 at 17:49:32 UTC, Mike Franklin wrote:
On Tuesday, 14 August 2018 at 17:22:42 UTC, Seb wrote:
FYI: staticArray will be part of 2.082, it already works with
dmd-nightly:
That just seems wrong. Isn't the fact that `staticArray` is
needed a bug in the compiler? I think the compiler could have
lowered to something like that automatically to avoid the
library workaround.
Mike
It's not a bug, it's all about how the type system is set up. The
type of an array literal expression like `[1, 2, 3]` is `int[]`
(a slice of an array of ints), so no matter if you do:
auto readonly(T)(const(T)[] x) { return x; }
auto arr1 = [1, 2, 3];
auto arr2 = [1, 2, 3].readonly;
constarr3 = [1, 2, 3];
enum arr4 = [1, 2, 3];
static immutable arr5 = [1, 2, 3];
scopearr6 = [1, 2, 3];
In all instances the type will be `int[]` modulo type qualifiers.
Static arrays are completely different types, that just happen to
accept
assignments from slices. Their two defining properties are:
1. Their length is fixed at compile-time, meaning that you can do:
import std.array, std.meta;
auto x = [1, 2, 3, 4, 5].staticArray;
enum length = x.length;
pragma (msg, length);
alias seq = AliasSeq!(0, 42, length);
static foreach (i; 0 .. length) { }
static foreach (i; seq) { }
2. Where slices are reference types, static arrays are value
types which means that each assignment will copy an entire array.
Basically they behave like a `struct { int _arr_0 = 0, _arr_1 =
1, _arr_2 = 2; }`.
https://run.dlang.io/is/iD9ydu
Re: Linking a C program with D library
On Wednesday, 15 August 2018 at 02:40:22 UTC, Joe wrote:
I understand that, Mike. However if I'm not mistaken given
something in C like
char* strs[] = { "This", "is a", "test"};
AFAIK, even with -betterC and an extern (C), the literals will
still be understood by D as type "string", and there is no
other way around it, right?
I could put the array and the function in its own C file for
the time being, but instead chose to replace the toStringz by a
small hack: use memcpy to copy the string to a stack fixed, big
enough array and a NUL terminator.
String literals are implicitly convertible to const(char)* and
are guaranteed to be nul-terminated like a C string, so this
works:
import core.stdc.stdio;
extern(C) void main()
{
const(char)* foo = "foo";
puts(foo);
}
https://run.dlang.io/is/FZSXc3
For plain char*, a simple cast works:
char* foo = cast(char*)"foo";
The problem is with the array initializer, as the C-style {x, y,
z} only works on structs in D, and D's [x, y, z] requires
TypeInfo, which isn't available in -betterC, a problem you run
into even when your array is string[].
However, the initializer works fine with static arrays in
-betterC, so this works:
import core.stdc.stdio;
extern(C):
void some_c_func(const char** strs, size_t numStrs) {
for(size_t i=0; ihttps://run.dlang.io/is/pxmGyh
Does that help?
