Re: Why my app require MSVCR120.dll?
On Friday, 6 November 2015 at 18:34:45 UTC, Cauterite wrote: On Friday, 6 November 2015 at 13:16:46 UTC, Suliman wrote: On Windows 7 it's work fine. On Windows 10 (clean install) it's do not start and require MSVCR120.dll D doesn't make particularly heavy use of the C runtime, so there's a good chance you can link against a different C runtime DLL — preferably one that's always available by default like msvcrt.dll. How can I link with msvcrt.dll ?
Re: Why my app require MSVCR120.dll?
On Wednesday, 18 January 2017 at 09:54:43 UTC, Suliman wrote: On Friday, 6 November 2015 at 18:34:45 UTC, Cauterite wrote: On Friday, 6 November 2015 at 13:16:46 UTC, Suliman wrote: On Windows 7 it's work fine. On Windows 10 (clean install) it's do not start and require MSVCR120.dll D doesn't make particularly heavy use of the C runtime, so there's a good chance you can link against a different C runtime DLL — preferably one that's always available by default like msvcrt.dll. How can I link with msvcrt.dll ? Or maybe there is way to statically link with MSVCR120.dll?
Re: Printing a floats in maximum precision
On Wednesday, 18 January 2017 at 03:36:39 UTC, Nicholas Wilson wrote: Alternatively use %a to print in hex to verify exact bit patterns. +1, if it doesn't have to be human-readable.
Re: iterating through members of bitfields
On Wednesday, 18 January 2017 at 01:15:05 UTC, Ali Çehreli wrote:
Not available but it should be possible to parse the produced
code:
import std.bitmanip;
string makeBitFieldPrinter(string fieldImpl) {
return q{
void printBitFields() const {
import std.stdio: writeln;
writeln("Please improve this function by parsing
fieldImpl. :)");
}
};
}
struct S {
enum myFields = bitfields!(int, "a", 24,
byte, "b", 8);
pragma(msg, "This is the mixed-in bit field
code\n-\n",
myFields, "\n--");
mixin (myFields);
mixin (makeBitFieldPrinter(myFields));
}
void main() {
const s = S();
s.printBitFields();
}
Of course that would depend on the implementation of
bitfields(), which can change without notice.
Ali
Thanks Ali, I was using bitfields according to documentation, but
now I see that way I can't access the mixin string:
struct S {
mixin(bitfields!(
bool, "f1",1,
uint, "f2",4,
uint, "f3",3)
);
}
Re: iterating through members of bitfields
I've "solved" the same problem by using AliasSeq to generate bitfields so that for iterating over bitfields I can iterate over alias sequence and mixin code. Not very good but it works.
Re: Where is floating point next{Up,Down}?
On Tuesday, 17 January 2017 at 23:41:27 UTC, Nordlöw wrote: On Tuesday, 17 January 2017 at 23:38:46 UTC, Ali Çehreli wrote: Found'em! :) https://dlang.org/phobos/std_math.html#.nextUp Thanks! (Shouts into the soundless void) https://github.com/pineapplemachine/mach.d/blob/master/mach/math/floats/neighbors.d
Assigning in constructor.
Is it undefined behavior to assign to a pointer in the constructor of a struct?
Re: Returning Arrays from Functions
On Wednesday, 18 January 2017 at 22:51:17 UTC, Samwise wrote: numbs[] = getInp(help, file, inp, args); This is wrong, try just `numbs = getImp(...);` numbs[] = xxx will copy stuff into the existing array, which is empty right now. You want to jut keep the slice the function passes back.
__traits(isRef, this) cannot distinguish l-value- from r-value-passed this
A compilation of
struct T
{
int x;
@disable this(this); // this has no effect on the issue
ref inout(T) memberFun() inout
{
pragma(msg, "memberFun:", __traits(isRef, this) ? "ref" :
"non-ref", " this");
return this;
}
}
void freeFun()(auto ref const T x)
{
pragma(msg, "freeFun:", __traits(isRef, x) ? "ref" :
"non-ref", " this");
}
unittest
{
T t;
freeFun(t); // `param` passed by reference
freeFun(T.init); // `param` passed by move
t.memberFun(); // `this` passed by what?
T.init.memberFun(); // `this` passed by what?
}
currently prints
memberFun:non-ref this
freeFun:ref this
freeFun:non-ref this
That is, we cannot distinguish an l-value-call to `memberFun`
from an r-value-call. Opposite to what we can when combining
`auto ref`-parameters with `__traits(isRef)` as shown with
function `freeFun` in the code example above.
Disabling the postblit has no effect on the issue.
I need this for enabling efficient delayed evaluation for unary
and binary arithmetic operators in my GNU MP wrapper described
earlier at
http://forum.dlang.org/thread/plqysfanwuoiuslfy...@forum.dlang.org
Any clues on how to retrieve this information?
Re: switch statement with variable branches
On 01/18/2017 05:22 PM, Yuxuan Shui wrote:
Somehow I can't use ubyte variables behind 'case', but ulong works fine.
Why is that?
void main() {
alias TestType = ulong; // won't compile if = ubyte
import std.stdio;
TestType a,b,c;
readf("%s %s %s ", , , );
switch(c){
case a: writeln("a");break;
case b: writeln("b");break;
default: assert(false);
}
}
case expressions must be constants:
"The case expressions must all evaluate to a constant value or
array, or a runtime initialized const or immutable variable of
integral type."
https://dlang.org/spec/statement.html#SwitchStatement
The fact that it compiles for ulong looks like a bug to me. It compiles
probably because switch is most likely implemented in terms of a chained
if-else-if statements by the compiler and it just works because there is
no explicit check whether they are constant or not.
Ali
Re: Intelligent enums
On Thursday, 19 January 2017 at 03:47:34 UTC, Ignacious wrote:
On Thursday, 19 January 2017 at 02:59:04 UTC, Ignacious wrote:
I have the need to create an enum flag like structure to
specify certain properties of a type easily.
e.g.,
enum properties
{
Red,
Blue,
Hot,
Sexy,
Active,
...
}
But some properties will be mutually exclusive. I would like
to contain all those rules for in the enum itself for obvious
reasons(encapsulation).
I guess I'm going to be told to use static and structs, but
I'm hoping for a more elegant solution.
I should be clear that I'm using these as flags using
EumToFlags and I want to prevent certain flags from betting set
in certain combinations that are invalid.
If their only use is for Enum to flags (i.e. you don't care at
all about the enum)
then you can use std.bitmanip.bitfields to logically group the
combinations.
i.e. have all the mutually exclusive combination in the same
field.
e.g.
struct properties
{
enum colour { red, blue }
// any other mutually exclusive combinations.
mixin(bitfields!(colour, "colour" , 1
bool , "hot" , 1));
}
Re: DMD Refuses to Compile Multiple Source Files
On Wednesday, 18 January 2017 at 23:12:15 UTC, Mike Parker wrote: (source files), then use the import statement to make the declarations in other modules. Sorry, this should read "make the implementations available to other modules".
Re: Assigning in constructor.
On Wednesday, 18 January 2017 at 23:08:07 UTC, Adam D. Ruppe wrote: On Wednesday, 18 January 2017 at 22:57:22 UTC, NotSpooky wrote: Is it undefined behavior to assign to a pointer in the constructor of a struct? Yes: http://dlang.org/spec/struct.html "A struct is defined to not have an identity; that is, the implementation is free to make bit copies of the struct as convenient." That means it might copy and/or move it without giving you a chance to update the pointer. Updating in postblit can help sometimes but still the compiler and library are allowed to move structs without notice. You already answered on the IRC so thanks X2. So, it's problematic to have pointers to structs in all cases according to spec?
alias not valid with ~
class Y
{
int y;
alias y this;
}
class X
{
Y[] x;
alias x this;
}
Yet X ~= 3; fails.
3 should be implicitly convertible to Y and then ~ should assign
it.
?
cannot alias array ;/
alias a = myarray[k]; fails myarray is a multidimensial array that I want to reduce writing it every time but D complains that it can't alias it. I simply want it to do a direct substitution, nothing fancy, just to reducing typing.
Function template advice
I have a simple comparison function:
struct Foo {
string bar;
}
auto sameGroup(T,S) (T a, S b) {
static assert (is(T == string) || is(T == Foo));
static assert (is(S == string) || is(S == Foo));
string aStr;
string bStr;
static if (is(T == string)){
aStr = a;
} else {
aStr = a.bar;
}
static if (is(S == string)){
bStr = b;
} else {
bStr = b.bar;
}
return equal (aStr,bStr);
}
This works, but just wondered if there was an easier way?
Is there a way to do "static if" in shorthand, like:
auto aStr = (static if (is(T==string)) ? a : a.bar
Returning Arrays from Functions
I've done a whole bunch of looking around, and I don't see any mention of returning a dynamic array from a function. When I try it though, it just returns the .length value of the array, rather than the contents of the array. Does anyone know why this is, and what I can do to make it behave the way I want it to?
Re: DMD Refuses to Compile Multiple Source Files
On Wednesday, 18 January 2017 at 19:28:20 UTC, Samwise wrote: On Wednesday, 18 January 2017 at 04:25:42 UTC, Mike Parker wrote: extern(C), not simply extern. It turns off the name mangling. But really, the proper thing to do is to drop the prototype and import the module with the implementation. It's tge way modules are intended to be used. Unless you're doing something specidic like writing a library that calls an arbitrary user function. Alright, so I misunderstood what ketmar was saying. His solution did work. I'm just not sure I understand what you are trying to say here: But really, the proper thing to do is to drop the prototype and import the module with the implementation. This will still preserve my multiple source files, without worrying about the headers, right? Thanks, ~Sam Yes. Take a look at some random projects from code.dlang.org and look at the way they have laid out their modules and what they import and from where.
Re: DMD Refuses to Compile Multiple Source Files
Thanks loads. I got it working using those modules. ~Sam
Re: __traits(isRef, this) cannot distinguish l-value- from r-value-passed this
On Thursday, 19 January 2017 at 00:44:51 UTC, Nordlöw wrote: Any clues on how to retrieve this information? Another much more common use case: Chained property setters could be optimized iff the property setter is called on an r-value, that is when `__traits(isRef,this)` is `false` Typically usages such as f(S.init.setX(2).setY(3)) and auto s = S.init.setX(2).setY(3) should all result in only *one* single construction of `S` (in the `S.init` expression).
Re: alias not valid with ~
On 19/01/2017 3:08 PM, Ignacious wrote:
class Y
{
int y;
alias y this;
}
class X
{
Y[] x;
alias x this;
}
Yet X ~= 3; fails.
3 should be implicitly convertible to Y and then ~ should assign it.
?
This should not fail:
X x = new X;
x ~= 3;
This should fail as x is a member of an instance of class X:
X ~= 3;
Re: Function template advice
On 01/18/2017 02:02 PM, Jordan Wilson wrote:
I have a simple comparison function:
struct Foo {
string bar;
}
auto sameGroup(T,S) (T a, S b) {
static assert (is(T == string) || is(T == Foo));
static assert (is(S == string) || is(S == Foo));
string aStr;
string bStr;
static if (is(T == string)){
aStr = a;
} else {
aStr = a.bar;
}
static if (is(S == string)){
bStr = b;
} else {
bStr = b.bar;
}
return equal (aStr,bStr);
}
This works, but just wondered if there was an easier way?
Is there a way to do "static if" in shorthand, like:
auto aStr = (static if (is(T==string)) ? a : a.bar
Yes, can be better with something similar to the following:
struct Foo {
string bar;
}
string value(U : Foo)(U u) {
return u.bar;
}
string value(U : string)(U u) {
return u;
}
auto sameGroup(T,S) (T a, S b) {
static assert (is(T == string) || is(T == Foo));
static assert (is(S == string) || is(S == Foo));
import std.algorithm;
return equal (value(a), value(b));
}
void main() {
assert(sameGroup("a", "b") == false);
assert(sameGroup("a", Foo("a")) == true);
assert(sameGroup(Foo("x"), "b") == false);
assert(sameGroup(Foo("z"), Foo("z")) == true);
}
Ali
Re: Returning Arrays from Functions
On Wednesday, 18 January 2017 at 22:37:25 UTC, Adam D. Ruppe
wrote:
What code do you have now?
This is the basic function. It takes all those boolean arguments
and does things depending on them, and then takes any extra args
that getopt didn't parse and reads them into numbs. That code
works fine, because I write it out after that's done but before I
pass it back to main().
ulong[] getInp (bool help, bool file, bool inp, string[] args) {
//...
writeln(numbs);
return numbs;
}
Here is what I've got in main (Minus some more stuff). Right now
it's just printing out what it gets, but it will use other
functions to apply operations to numbs later.
int main(string[] args) {
ulong[] numbs;
//...
numbs[] = getInp(help, file, inp, args);
writeln(numbs);
return 0;
}
That prints out an empty array. If I initialize one element,
(numbs[0] ~= 0;) then it prints out numbs.length. Really kinda
weird... Thanks,
~Sam
Re: Assigning in constructor.
On Wednesday, 18 January 2017 at 23:08:07 UTC, Adam D. Ruppe wrote: On Wednesday, 18 January 2017 at 22:57:22 UTC, NotSpooky wrote: Is it undefined behavior to assign to a pointer in the constructor of a struct? Yes: http://dlang.org/spec/struct.html "A struct is defined to not have an identity; that is, the implementation is free to make bit copies of the struct as convenient." That means it might copy and/or move it without giving you a chance to update the pointer. Updating in postblit can help sometimes but still the compiler and library are allowed to move structs without notice. Practically speaking I've found that if the struct was allocated on the heap, then acquires that pointer and seems not to break anything, e.g. how it's used in the uncopyable struct here https://github.com/pineapplemachine/mach.d/blob/master/mach/collect/linkedlist.d#L165
Re: switch statement with variable branches
On Thursday, 19 January 2017 at 02:00:10 UTC, Ali Çehreli wrote:
On 01/18/2017 05:22 PM, Yuxuan Shui wrote:
Somehow I can't use ubyte variables behind 'case', but ulong
works fine.
Why is that?
case expressions must be constants:
"The case expressions must all evaluate to a constant value or
array, or a runtime initialized const or immutable variable
of
integral type."
https://dlang.org/spec/statement.html#SwitchStatement
The fact that it compiles for ulong looks like a bug to me. It
compiles probably because switch is most likely implemented in
terms of a chained if-else-if statements by the compiler and it
just works because there is no explicit check whether they are
constant or not.
Ali
If you try:
void main() {
alias TestType = ulong; // won't compile if = ubyte
import std.stdio;
TestType a,b,c;
readf("%s %s %s ", , , );
final switch(c){
case a: writeln("a");break;
case b: writeln("b");break;
default: assert(false);
}
}
Then the error message:
test.d(7): Error: case variables not allowed in final switch
statements
test.d(8): Error: case variables not allowed in final switch
statements
Makes it looks like that "case variable" is an intended feature.
Re: alias not valid with ~
On 19/01/2017 3:25 PM, Adam D. Ruppe wrote:
On Thursday, 19 January 2017 at 02:15:04 UTC, rikki cattermole wrote:
On 19/01/2017 3:08 PM, Ignacious wrote:
class Y
{
int y;
alias y this;
}
class X
{
Y[] x;
alias x this;
}
This should not fail:
X x = new X;
x ~= 3;
Yes, it should fail. 3 is not implicitly convertible to Y under any
circumstance. D does not support implicit constructors.
alias this only works if you ALREADY HAVE a Y, then it will implicitly
convert Y to int. It will never go the other way around.
Oh Y, I read it as int, my bad.
Yes should fail.
Re: alias not valid with ~
On Thursday, 19 January 2017 at 02:25:44 UTC, Adam D. Ruppe wrote:
On Thursday, 19 January 2017 at 02:15:04 UTC, rikki cattermole
wrote:
On 19/01/2017 3:08 PM, Ignacious wrote:
class Y
{
int y;
alias y this;
}
class X
{
Y[] x;
alias x this;
}
This should not fail:
X x = new X;
x ~= 3;
Yes, it should fail. 3 is not implicitly convertible to Y under
any circumstance. D does not support implicit constructors.
alias this only works if you ALREADY HAVE a Y, then it will
implicitly convert Y to int. It will never go the other way
around.
Huh?
But this is alias this, the whole point of alias this is to treat
the type as as the alias?
You are saying it basically only works one way, seems to make
alias this quite useless(50% at least). Is there any real reason
why this doesn't work?
X x;
Y y;
y = 3;
x ~= y; works fine
x ~= 3; fails.
Yet, logically, 3 is convertible to Y(3rd line above) and Y is
appendable to X.
Seems to me that D simply hasn't added the logic to handle the
case for implicit construction for alias this, why not add it?
Re: Returning Arrays from Functions
On Wednesday, 18 January 2017 at 23:09:15 UTC, Adam D. Ruppe wrote: On Wednesday, 18 January 2017 at 22:51:17 UTC, Samwise wrote: numbs[] = getInp(help, file, inp, args); This is wrong, try just `numbs = getImp(...);` numbs[] = xxx will copy stuff into the existing array, which is empty right now. You want to jut keep the slice the function passes back. Huh. I thought I tried that. I guess I didn't, since it worked like a charm. Thanks loads. ~Sam
Re: Assigning in constructor.
On Thursday, 19 January 2017 at 00:55:42 UTC, NotSpooky wrote: You already answered on the IRC so thanks X2. So, it's problematic to have pointers to structs in all cases according to spec? Maybe... though in practice (and with C compatibility), pointers to ones where you know the memory management scheme is fine. So if you declare a local, and get a pointer to it, you're OK. Or if you new it, or malloc it, or something like that. The big problem with a pointer to itself in the constructor or as a member is that the struct itself doesn't know where it is going or how it was allocated, just the code outside does.
Re: Returning Arrays from Functions
What code do you have now?
Re: Assigning in constructor.
On Wednesday, 18 January 2017 at 22:57:22 UTC, NotSpooky wrote: Is it undefined behavior to assign to a pointer in the constructor of a struct? Yes: http://dlang.org/spec/struct.html "A struct is defined to not have an identity; that is, the implementation is free to make bit copies of the struct as convenient." That means it might copy and/or move it without giving you a chance to update the pointer. Updating in postblit can help sometimes but still the compiler and library are allowed to move structs without notice.
Re: Function template advice
On Wednesday, 18 January 2017 at 22:39:02 UTC, Ali Çehreli wrote:
On 01/18/2017 02:02 PM, Jordan Wilson wrote:
[...]
Yes, can be better with something similar to the following:
struct Foo {
string bar;
}
string value(U : Foo)(U u) {
return u.bar;
}
string value(U : string)(U u) {
return u;
}
auto sameGroup(T,S) (T a, S b) {
static assert (is(T == string) || is(T == Foo));
static assert (is(S == string) || is(S == Foo));
import std.algorithm;
return equal (value(a), value(b));
}
void main() {
assert(sameGroup("a", "b") == false);
assert(sameGroup("a", Foo("a")) == true);
assert(sameGroup(Foo("x"), "b") == false);
assert(sameGroup(Foo("z"), Foo("z")) == true);
}
Ali
Nice, yes looks better thanks.
Jordan
switch statement with variable branches
Somehow I can't use ubyte variables behind 'case', but ulong
works fine. Why is that?
void main() {
alias TestType = ulong; // won't compile if = ubyte
import std.stdio;
TestType a,b,c;
readf("%s %s %s ", , , );
switch(c){
case a: writeln("a");break;
case b: writeln("b");break;
default: assert(false);
}
}
Re: alias not valid with ~
On Thursday, 19 January 2017 at 02:15:04 UTC, rikki cattermole
wrote:
On 19/01/2017 3:08 PM, Ignacious wrote:
class Y
{
int y;
alias y this;
}
class X
{
Y[] x;
alias x this;
}
This should not fail:
X x = new X;
x ~= 3;
Yes, it should fail. 3 is not implicitly convertible to Y under
any circumstance. D does not support implicit constructors.
alias this only works if you ALREADY HAVE a Y, then it will
implicitly convert Y to int. It will never go the other way
around.
Intelligent enums
I have the need to create an enum flag like structure to specify
certain properties of a type easily.
e.g.,
enum properties
{
Red,
Blue,
Hot,
Sexy,
Active,
...
}
But some properties will be mutually exclusive. I would like to
contain all those rules for in the enum itself for obvious
reasons(encapsulation).
I guess I'm going to be told to use static and structs, but I'm
hoping for a more elegant solution.
Re: alias not valid with ~
On Thursday, 19 January 2017 at 02:51:03 UTC, rikki cattermole wrote: Now, lets say Y was a struct, then yeah it can work. In theory, it can work with either (the compiler could just insert the function call to alloc+construct), but it won't in D since we don't have implicit construction.
Re: alias not valid with ~
On 19/01/2017 3:35 PM, Ignacious wrote:
On Thursday, 19 January 2017 at 02:25:44 UTC, Adam D. Ruppe wrote:
On Thursday, 19 January 2017 at 02:15:04 UTC, rikki cattermole wrote:
On 19/01/2017 3:08 PM, Ignacious wrote:
class Y
{
int y;
alias y this;
}
class X
{
Y[] x;
alias x this;
}
This should not fail:
X x = new X;
x ~= 3;
Yes, it should fail. 3 is not implicitly convertible to Y under any
circumstance. D does not support implicit constructors.
alias this only works if you ALREADY HAVE a Y, then it will implicitly
convert Y to int. It will never go the other way around.
Huh?
But this is alias this, the whole point of alias this is to treat the
type as as the alias?
You are saying it basically only works one way, seems to make alias this
quite useless(50% at least). Is there any real reason why this doesn't
work?
X x;
Y y;
y = 3;
x ~= y; works fine
x ~= 3; fails.
Yet, logically, 3 is convertible to Y(3rd line above) and Y is
appendable to X.
Seems to me that D simply hasn't added the logic to handle the case for
implicit construction for alias this, why not add it?
It is not implicitly convertible in any form.
An integer is just a value, probably stored in a register or directly
encoded into an instruction.
A class instance is always allocated into memory, in pretty much all
cases the heap (stack is explicit in D). So what you're suggesting would
require an allocation + calling of a constructor to make it equal.
Now, lets say Y was a struct, then yeah it can work. Because a struct is
nothing more than a set of values that go together. Which are commonly
allocated on the stack and for smaller ones, be passed around by only
registers.
Re: alias not valid with ~
On Thursday, 19 January 2017 at 02:35:08 UTC, Ignacious wrote:
But this is alias this, the whole point of alias this is to
treat the type as as the alias?
No, alias this is for subtyping. Similar to a child class, a
subtype can be used as its parent type, but must be constructed.
class A {}
class B : A {}
A a = new B(); // legal, B will convert to A
B a = new A(); // illegal, A is not B
alias this is the same concept, just outside of class inheritance.
https://en.wikipedia.org/wiki/Subtyping
Yet, logically, 3 is convertible to Y(3rd line above) and Y is
appendable to X.
Wrong. Implicit construction and implicit conversion are
different concepts in theory and in practice in every language I
know. You often want them separately as construction may need
additional state, may just not be logical, and may have a
different runtime cost than substitution.
D does not support implicit construction under any circumstance
except the typesafe variadic syntax in function calls that take a
single class.
(I'd like to add it, but Walter doesn't agree..)
Re: alias not valid with ~
On Thursday, 19 January 2017 at 02:51:03 UTC, rikki cattermole
wrote:
On 19/01/2017 3:35 PM, Ignacious wrote:
On Thursday, 19 January 2017 at 02:25:44 UTC, Adam D. Ruppe
wrote:
On Thursday, 19 January 2017 at 02:15:04 UTC, rikki
cattermole wrote:
On 19/01/2017 3:08 PM, Ignacious wrote:
class Y
{
int y;
alias y this;
}
class X
{
Y[] x;
alias x this;
}
This should not fail:
X x = new X;
x ~= 3;
Yes, it should fail. 3 is not implicitly convertible to Y
under any
circumstance. D does not support implicit constructors.
alias this only works if you ALREADY HAVE a Y, then it will
implicitly
convert Y to int. It will never go the other way around.
Huh?
But this is alias this, the whole point of alias this is to
treat the
type as as the alias?
You are saying it basically only works one way, seems to make
alias this
quite useless(50% at least). Is there any real reason why this
doesn't
work?
X x;
Y y;
y = 3;
x ~= y; works fine
x ~= 3; fails.
Yet, logically, 3 is convertible to Y(3rd line above) and Y is
appendable to X.
Seems to me that D simply hasn't added the logic to handle the
case for
implicit construction for alias this, why not add it?
It is not implicitly convertible in any form.
An integer is just a value, probably stored in a register or
directly encoded into an instruction.
so? An integer is just a type. Where it is stored or how is
irrelevant.
A class instance is always allocated into memory, in pretty
much all cases the heap (stack is explicit in D). So what
you're suggesting would require an allocation + calling of a
constructor to make it equal.
So.
Now, lets say Y was a struct, then yeah it can work. Because a
struct is nothing more than a set of values that go together.
Which are commonly allocated on the stack and for smaller ones,
be passed around by only registers.
So. If it worked for a struct as you suggest it should for for
any type.
What you are suggesting is that the compiler(or maybe the
compiler programmer) is not able to create a rewrite rule. It
obviously can. So your reasons are flawed.
The reason question you should ask yourself is is there any
reason not to do it, instead of trying to find reasons it can't
be done(sounds more like you are grasping at straws/guessing).
You should realize any time one can program something explicit
the compiler can be made to do it implicit. The question is the
consequences of such actions. In this case, regardless if we use
3 and convert explicitly or not ~ requires an allocation, so
allocations alone are not enough to prevent it.
Re: DMD Refuses to Compile Multiple Source Files
On Wednesday, 18 January 2017 at 04:25:42 UTC, Mike Parker wrote: extern(C), not simply extern. It turns off the name mangling. But really, the proper thing to do is to drop the prototype and import the module with the implementation. It's tge way modules are intended to be used. Unless you're doing something specidic like writing a library that calls an arbitrary user function. Alright, so I misunderstood what ketmar was saying. His solution did work. I'm just not sure I understand what you are trying to say here: But really, the proper thing to do is to drop the prototype and import the module with the implementation. This will still preserve my multiple source files, without worrying about the headers, right? Thanks, ~Sam
Problems with stored procedure using the mysql-native library.
Hi
I am having problems using stored procedures that return results.
Example procedure:
CREATE PROCEDURE GetUsers()
SELECT * FROM users;
When I use this procedure from the MySQL command line everything
works fine. However, when I use it from the mysql-native library
i get into problems.
int main()
{
auto con = new Connection(...); //
auto cmd = Command(con);
cmd.execProcedure("GetUsers");
}
This returns the error:
MySQL error: PROCEDURE db.getusers can't return a result set in
the given context.
Other SQL queries work fine over the connection and procedure
calls that do not return anything also works.
How would i go about solving this problem?
Re: Problems with stored procedure using the mysql-native library.
On Wednesday, 18 January 2017 at 19:40:12 UTC, TheFlyingFiddle wrote: Hi I am having problems using stored procedures that return results. Update: I am using the SvrCapFlags.MULTI_RESULTS flag when initiating the connection and have also tried using the SvrCapFlags.MULTI_STATEMENTS flag. Unfortunately these flags do not solve the problem.
