On Tuesday, 30 January 2018 at 17:41:53 UTC, jsako wrote:
So what's considered the best alternative to void pointers in D
if you don't want to use objects? Make a tagged Union of all
possible datatypes in the struct? Have a Byte array and cast
that instead of a void pointer? Some sort of magic
The common C way to get a blob of generic data at runtime is to
use void pointers like so:
struct Structo {
int type;
void* data;
}
Then cast the void pointer to whatever data you needed based on
the type. I imagine D has a better mechanism for this sort of
thing, but after some
On Tuesday, 17 May 2016 at 18:25:46 UTC, ag0aep6g wrote:
On 05/17/2016 07:43 PM, Alex wrote:
The relation is: some object A contains the pointer/iota/(if
at all)
some object B makes slices of the thing, which is in A.
Ok, so you have some object that stores a void pointer. The
pointer is
On 05/17/2016 07:43 PM, Alex wrote:
The relation is: some object A contains the pointer/iota/(if at all)
some object B makes slices of the thing, which is in A.
Ok, so you have some object that stores a void pointer. The pointer is
going to be null at all times. Then you slice that pointer.
On Tuesday, 17 May 2016 at 17:25:48 UTC, ag0aep6g wrote:
On 05/17/2016 05:33 PM, Alex wrote:
But, if the slicing is made by means of iota, there is no (at
least no
explicit) dependence between the slices, which could be made by
different objects.
How is this dependency expressed with slices?
On 05/17/2016 05:33 PM, Alex wrote:
But, if the slicing is made by means of iota, there is no (at least no
explicit) dependence between the slices, which could be made by
different objects.
How is this dependency expressed with slices?
I'm ready to admit, that the process will work with
On Tuesday, 17 May 2016 at 13:25:34 UTC, ag0aep6g wrote:
On 05/17/2016 03:14 PM, Alex wrote:
For a slice I surely need two numbers. But this should all be,
what I
need for a slice. For a iota, I need a maximum, which is not
provided
(at least at this moment) to the object containing the
On 05/17/2016 03:14 PM, Alex wrote:
For a slice I surely need two numbers. But this should all be, what I
need for a slice. For a iota, I need a maximum, which is not provided
(at least at this moment) to the object containing the pointer/iota thing.
The slice's length is practically the same
On Tuesday, 17 May 2016 at 12:24:58 UTC, ag0aep6g wrote:
On 05/17/2016 12:53 PM, Alex wrote:
2. If I want to be able to slice a iota, I have to initialize
it with
the last number. But the object, which stores the pointer does
not need
to know anything about this number. So, I rather would not
On 05/17/2016 12:53 PM, Alex wrote:
2. If I want to be able to slice a iota, I have to initialize it with
the last number. But the object, which stores the pointer does not need
to know anything about this number. So, I rather would not like to pass
this number only for being able to instantiate
On 05/17/2016 10:16 AM, Rene Zwanenburg wrote:
Additionally, some people recommend never using -release. It depends on
that type of program you're writing, but the performance gain is often
not worth the loss in safety. Think of the number of exploits enabled by
C's lack of bounds checking.
On 05/17/2016 08:53 AM, Alex wrote:
the elements of the slice are accessible just for reading, right, but
with them I reference the data in other objects.
If the slice's pointer is invalid, then its elements are not accessible
at all.
On Tuesday, 17 May 2016 at 08:45:44 UTC, Alex wrote:
so...
besides
void*, ubyte*, a pointer to a strange, not constructible
struct, I could take a iota too...
a comment on my own:
even every type of the above mentioned is possible, there are
slightly differences between them:
1. As I don't
On Tuesday, 17 May 2016 at 08:16:15 UTC, Rene Zwanenburg wrote:
On Tuesday, 17 May 2016 at 06:55:35 UTC, Alex wrote:
with dmd test44.d -release
the results are:
You may want to pass '-O -inline' as well. -O enables general
optimizations, -inline enables function inlining.
-release is for
On Monday, 16 May 2016 at 23:01:44 UTC, ag0aep6g wrote:
On 05/17/2016 12:53 AM, Alex wrote:
Just as the reality (in my head) is: you can count something
without
having written the natural numbers before you start to count...
iota does that, too. A iota struct doesn't store all the
numbers
On Monday, 16 May 2016 at 22:54:31 UTC, ag0aep6g wrote:
On 05/17/2016 12:43 AM, Alex wrote:
The point is, that in my model the slice has a meaning itself.
So, the
language provides one of a needed constructs...
Huh? As far as I understand, the pointer of the slice is
invalid, and you never
On 05/17/2016 12:43 AM, Alex wrote:
The point is, that in my model the slice has a meaning itself. So, the
language provides one of a needed constructs...
Huh? As far as I understand, the pointer of the slice is invalid, and
you never dereference it. What kind of additional meaning can the
On Monday, 16 May 2016 at 22:28:04 UTC, ag0aep6g wrote:
I can't say that I understand the setup you describe. But are
you sure that iota has a higher cost than (ab)using a slice?
I mean, they're pretty much exactly the same: an offset, a
length, and an increment operation. If inlining
On 05/16/2016 11:33 PM, Alex wrote:
Well... not wanting to have a variable, which stores numbers, which are
natural numbers, beginning with zero, used for counting only.
But you have such a variable: b. I may still be missing the point.
On 05/16/2016 11:35 PM, Alex wrote:
Background:
Say, I have objects of kind E, which operate on structs of kind M. The
problem: if an action is done on a struct, say M42, there should be also
some action done on other structs, which have some relation to M42, but
neither the operating object,
On Monday, 16 May 2016 at 21:41:20 UTC, Steven Schveighoffer
wrote:
Hey, there's nothing wrong with for-loops. Just trying to
answer the question :)
You could also do something like:
foreach(i; 0 .. b.length) writeln([i]);
Ha! Yes! :)
Thanks :)
-Steve
On 5/16/16 5:38 PM, Alex wrote:
On Monday, 16 May 2016 at 21:15:16 UTC, Steven Schveighoffer wrote:
On 5/16/16 4:39 PM, Alex wrote:
// something that does not worked as expected:
// how to rewrite a for loop
for(auto i = 0; i < b.length; i++) writeln([i]);
// into a foreach
On Monday, 16 May 2016 at 21:15:16 UTC, Steven Schveighoffer
wrote:
On 5/16/16 4:39 PM, Alex wrote:
// something that does not worked as expected:
// how to rewrite a for loop
for(auto i = 0; i < b.length; i++) writeln([i]);
// into a foreach loop?
What you need is a
Background:
Say, I have objects of kind E, which operate on structs of kind
M. The problem: if an action is done on a struct, say M42, there
should be also some action done on other structs, which have some
relation to M42, but neither the operating object, nor M42 is
aware of them (and the
On Monday, 16 May 2016 at 21:04:32 UTC, ag0aep6g wrote:
Typo here. Should be `ptr[a .. b]`.
Thanks
void main()
{
void* ptr; // this will stay uninitialized during the
whole program
run
The pointer is being initialized, though. To null, which is why
your shenanigans below work
On 5/16/16 4:39 PM, Alex wrote:
// something that does not worked as expected:
// how to rewrite a for loop
for(auto i = 0; i < b.length; i++) writeln([i]);
// into a foreach loop?
What you need is a range that produces void * instead element itself.
This would probably
On 05/16/2016 10:39 PM, Alex wrote:
// This function is intentionally templated, as it should take slices
and return something
// boundchecked only
@nogc T[] getSlice(T)(T* ptr, size_t a, size_t b)
{
return T[a .. b];
Typo here. Should be `ptr[a .. b]`.
}
void main()
{
void* ptr;
Hi all!
Let's talk about void pointers a little bit. Found this already
http://forum.dlang.org/thread/codoixfeqstvqswir...@forum.dlang.org?page=1
but my question/problem differs from the above, so maybe, I have
found a useful application for void pointers...
Form of the posting: I have some
I'm not sure if this is a bug or not:
struct Foo { }
void test(void* test) { assert(0); }
void test(Foo* test) { }
void main()
{
test(null);
}
The call matches the second overload: void test(Foo* test). But
shouldn't this be an ambiguous call?
On Thu, 24 May 2012 14:50:38 +0200, Andrej Mitrovic wrote:
I'm not sure if this is a bug or not:
struct Foo { }
void test(void* test) { assert(0); }
void test(Foo* test) { }
void main()
{
test(null);
}
The call matches the second overload: void test(Foo* test). But
Justin Whear:
Perhaps it should be ambiguous due to the special nature of
null,
Maybe a compile-time error is better here.
Bye,
bearophile
Maybe a compile-time error is better here.
http://d.puremagic.com/issues/show_bug.cgi?id=8146
32 matches
Mail list logo
