I do not really think it's a bad solution, to check several
scalar arguments that must obey the same condition; just
wondering if you have better ideas. Try to avoid modifying the
function's signature and defining custom types, unless you have a
really terrific idea.
void calc(double in1, dou
Oh... please forget it
What a terrible example :p I forgot why I was using pointers at
all... I must have had a reason to write this in the past ???
On Saturday, 11 March 2017 at 12:35:42 UTC, XavierAP wrote:
I do not really think it's a bad solution, to check several
scalar arguments that must obey the same condition; just
wondering if you have better ideas. Try to avoid modifying the
function's signature and defining custom types, unless
On Saturday, 11 March 2017 at 12:35:42 UTC, XavierAP wrote:
I do not really think it's a bad solution, to check several
scalar arguments that must obey the same condition; just
wondering if you have better ideas. Try to avoid modifying the
function's signature and defining custom types, unless
On Saturday, 11 March 2017 at 13:44:30 UTC, Satoshi wrote:
void calc(in double[] array...) {
foreach (x; array) { }
}
To do what I want it should be foreach(ref x; array) -- or const
ref. But also I don't want to modify the function signature,
certainly in this way. In another situation yes,
On Saturday, 11 March 2017 at 14:49:42 UTC, XavierAP wrote:
But also I don't want to modify the function signature,
certainly in this way.
It is already copied by the time you get in to the function
though because of the signature (unless they are constructed
in-place at the call site).
But
I'm trying to build the master branch of DMD on redhat 7.
I get the following errors:
ddmd/root/newdelete.c:26:8: error: expected identifier or ‘(’
before string constant
extern "C"
^
ddmd/root/newdelete.c:31:17: error: expected ‘=’, ‘,’, ‘;’, ‘asm’
or ‘__attribute__’ before ‘new’
v
On 03/11/2017 06:41 PM, Eric wrote:
I'm trying to build the master branch of DMD on redhat 7.
I get the following errors:
ddmd/root/newdelete.c:26:8: error: expected identifier or ‘(’ before
string constant
extern "C"
^
ddmd/root/newdelete.c:31:17: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ o
On Saturday, 11 March 2017 at 02:25:15 UTC, Paul D Anderson wrote:
On Saturday, 11 March 2017 at 00:34:03 UTC, Paul D Anderson
wrote:
On Friday, 10 March 2017 at 22:04:23 UTC, Paul D Anderson
wrote:
While building DMD -- "make -fwin32.mak release" -- I
received the following error message:
ec
On Saturday, 11 March 2017 at 17:54:55 UTC, ag0aep6g wrote:
Looks like a C compiler is used instead of a C++ compiler.
Despite the extension, dmd's *.c files are C++ code.
Yes, that's what I thought - redhat has gcc, but not g++. There
must
be a needed compile option...
On Saturday, 11 March 2017 at 17:54:55 UTC, ag0aep6g wrote:
On 03/11/2017 06:41 PM, Eric wrote:
I'm trying to build the master branch of DMD on redhat 7.
I get the following errors:
ddmd/root/newdelete.c:26:8: error: expected identifier or ‘(’
before
string constant
extern "C"
^
ddmd
On Sat, Mar 11, 2017 at 12:45:10PM +, XavierAP via Digitalmars-d-learn
wrote:
> On Saturday, 11 March 2017 at 12:35:42 UTC, XavierAP wrote:
> > I do not really think it's a bad solution, to check several scalar
> > arguments that must obey the same condition; just wondering if you
> > have bet
On Saturday, 11 March 2017 at 19:15:59 UTC, H. S. Teoh wrote:
What about just:
foreach (const ref p; [in1, in2, in3, in4])
I would think there will be already one copy from the local
parameter variables to the in situ array. Then from that one into
the for each element it's ref'd al
So a lovely C library does its own opaque allocation, and
provides access to the malloc'd memory, and that memory's length.
Instead of copying the results into garbage collected memory
(which would probably be smart) I was thinking about creating a
structure like:
struct WrappedString {
byt
cy wrote:
So a lovely C library does its own opaque allocation, and provides access
to the malloc'd memory, and that memory's length. Instead of copying the
results into garbage collected memory (which would probably be smart) I
was thinking about creating a structure like:
struct WrappedStr
Are there any general tips or best practices for bindings in dub
packages?
For example, I love the d2sqlite3 package. It just works out of
the box. No linker configuration or anything. However, that is
probably a testament to sqlite's lack of dependencies. That
cannot work for libraries, whic
On Saturday, 11 March 2017 at 22:39:02 UTC, cy wrote:
So a lovely C library does its own opaque allocation, and
provides access to the malloc'd memory, and that memory's
length. Instead of copying the results into garbage collected
memory (which would probably be smart) I was thinking about
cr
On Saturday, 11 March 2017 at 18:02:00 UTC, Stefan Koch wrote:
On Saturday, 11 March 2017 at 02:25:15 UTC, Paul D Anderson
wrote:
On Saturday, 11 March 2017 at 00:34:03 UTC, Paul D Anderson
wrote:
On Friday, 10 March 2017 at 22:04:23 UTC, Paul D Anderson
wrote:
[...]
I see John Colvin has al
int*[] foo;
foo.length = 5;
import std.c.string;
int* baz = cast(string*)malloc(50);
import std.c.stdio;
printf("%d %d", foo.length, baz.length );
prints:
Error: no property 'length' for type 'int*'
BUT:
string*[] foo;
foo.length = 5;
import std.c.string;
string* baz = cast(string*)malloc(50
Random D user wrote:
How come string* suddenly has a .length property?
due to automatic pointer dereferencing that `.` does. no, not a bug.
On Sunday, 12 March 2017 at 01:55:20 UTC, ketmar wrote:
Random D user wrote:
How come string* suddenly has a .length property?
due to automatic pointer dereferencing that `.` does. no, not a
bug.
Ah... right. Silly me. Of course, since string is actually
immutable(char)[].
That's bit of a
On Saturday, 11 March 2017 at 23:43:54 UTC, Nicholas Wilson wrote:
A string *is* a pointer length pair, an immutable(char)[].
Yes, but surely there's some silly requirement, like that the
pointer must only ever point to garbage collected memory, or
something?
ubyte[] arr; // or byte/char wh
cy wrote:
On Saturday, 11 March 2017 at 23:43:54 UTC, Nicholas Wilson wrote:
A string *is* a pointer length pair, an immutable(char)[].
Yes, but surely there's some silly requirement, like that the pointer
must only ever point to garbage collected memory, or something?
why should it? a sli
On Sunday, March 12, 2017 02:47:19 cy via Digitalmars-d-learn wrote:
> On Saturday, 11 March 2017 at 23:43:54 UTC, Nicholas Wilson wrote:
> > A string *is* a pointer length pair, an immutable(char)[].
>
> Yes, but surely there's some silly requirement, like that the
> pointer must only ever point t
I was wondering if there's a more elegant way to do something
like this?
template BitSize(T) {
enum BitSize = T.sizeof * 8;
}
struct Data(ParentType,ChildType) {
@property {
ChildType low() { return cast(ChildType)value; }
void low(ChildType lowVa
On Sunday, 12 March 2017 at 05:13:41 UTC, bauss wrote:
I was wondering if there's a more elegant way to do something
like this?
[...]
I saw one improvement to it which would be BitSize!ChildType
instead of taking parent type's bit size divided by two.
Also
value = ((highValue << 16 | low)
On Sunday, 12 March 2017 at 05:13:41 UTC, bauss wrote:
I was wondering if there's a more elegant way to do something
like this?
template BitSize(T) {
enum BitSize = T.sizeof * 8;
}
struct Data(ParentType,ChildType) {
@property {
ChildType low() { return cast(Chi
27 matches
Mail list logo
