On Wednesday, 15 August 2012 at 01:42:11 UTC, Ali Çehreli wrote:
Agreed. The function code must be compiled to use certain
amount of data from the program stack for that particular
parameter. That size of that parameter must be known at compile
time.
The compiler could in theory examine the e
On 08/14/2012 06:22 PM, Era Scarecrow wrote:
> On Wednesday, 15 August 2012 at 00:37:32 UTC, ReneSac wrote:
>> And my last question of my first post: I can't use "auto" for the
>> "out" values right? An enhancement proposal like this would be
>> compatible with D?
>
> I would say No. Maybe if
On Wednesday, 15 August 2012 at 00:37:32 UTC, ReneSac wrote:
And my last question of my first post: I can't use "auto" for
the "out" values right? An enhancement proposal like this would
be compatible with D?
I would say No. Maybe if it was a union, but I don't think
so;.It still needs t
Thanks, this indeed works. One "obvious" (when your program
starts to behave weirdly...) down side of this solution: it needs
a different dummy for each optional out value of a function, or
else multiple variables will be modifying the same dummy.
And, of course, a different dummy for each typ
In the array structure, either the length is how many elements
of that type there are, or how many bytes total the array takes
up. This can create a slight problem if used in a union (or so
I've found).
Currently this is how it works:
union {
ubyte[] ub;
int[] i;
}
i = new int
http://www.reddit.com/r/cpp/comments/y6gwk/norvigs_python_sudoku_solver_ported_to_c11/
http://nonchalantlytyped.net/blog/2012/08/13/sudoku-solver-in-c11/
His C++11 port is 316 lines long:
https://gist.github.com/3345676
How many lines for a (not golfed) D translation of the original
Python cod
Is it possible to somehow have a separate -Df flag for even file
that I compile?
ddoc is frustrating beyond words to figure out
On Tuesday, 14 August 2012 at 21:33:34 UTC, Jonathan M Davis
wrote:
On Tuesday, August 14, 2012 23:28:08 Andrew Spott wrote:
This appears to be the correct answer. I was mostly just
confused. something #defined is just replaced by the C
preprocessor (or so I thought), which means that in C, you
On Tuesday, August 14, 2012 23:28:08 Andrew Spott wrote:
> This appears to be the correct answer. I was mostly just
> confused. something #defined is just replaced by the C
> preprocessor (or so I thought), which means that in C, you would
> be passing 0 to PetscInitialize... which seems weird.
0
On Tuesday, 14 August 2012 at 20:10:13 UTC, Simen Kjaeraas wrote:
On Tue, 14 Aug 2012 21:27:25 +0200, Andrew
wrote:
I'm trying to interface with C code, where I have a function
definition that takes two const char[]'s:
PetscErrorCode PetscInitialize(int*, char***, const char[],
const
char[
On 2012-08-14 20:29, David Nadlinger wrote:
Nice hack, but when using this on functions you don't control, be aware
that parameter names are officially not considered part of the API (as
it became clear in the named parameter-related discussions). This
implies that e.g. the parameter names of Ph
How about cast(const(char[]))([0]) ?
Although I think what you actually want is probably just null,
since a C function expecting an array is expecting a pointer, and
passing cast(const(char[]))([0]) satisfies the signature but
gives you a non-null array. I would guess what you really want to
On Tue, 14 Aug 2012 21:27:25 +0200, Andrew wrote:
I'm trying to interface with C code, where I have a function
definition that takes two const char[]'s:
PetscErrorCode PetscInitialize(int*, char***, const char[], const
char[]);
However, the typical way that you pass "Null" values instead of
t
On Tuesday, 14 August 2012 at 19:27:26 UTC, Andrew wrote:
I'm trying to interface with C code, where I have a function
definition that takes two const char[]'s:
PetscErrorCode PetscInitialize(int*, char***, const char[],
const
char[]);
However, the typical way that you pass "Null" values inst
I'm trying to interface with C code, where I have a function
definition that takes two const char[]'s:
PetscErrorCode PetscInitialize(int*, char***, const char[], const
char[]);
However, the typical way that you pass "Null" values instead of
the last two arguments is "PETSC_NULL"
The problem is
On Tuesday, 14 August 2012 at 16:06:33 UTC, Jacob Carlborg wrote:
I don't know if this works any better:
https://github.com/jacob-carlborg/orange/blob/master/orange/util/Reflection.d#L29
It's a simple implementation.
Nice hack, but when using this on functions you don't control, be
aware tha
On 2012-08-14 06:40, Ellery Newcomer wrote:
pragma(msg, __traits(parameterNames, Constructors[0]));
gives me
tok.d(19): Error: unrecognized trait parameterNames
I don't know if this works any better:
https://github.com/jacob-carlborg/orange/blob/master/orange/util/Reflection.d#L29
It's a si
Ellery Newcomer:
I was thinking about adding keyword argument support to pyd
wrapped functions.
Maybe you have to process the JSON output?
Bye,
bearophile
.s, .c, .d files (source files), are not linked. What is
linked, are object files (.obj or .o).
GCC either compiles the .s file to an object file, or passes it
to assembler to do it - I don't know.
I think what you need to is to create an object file from the
.s file and link it to your D ex
19 matches
Mail list logo
