== Quote from Ellery Newcomer (ellery-newco...@utulsa.edu)'s article
> On 07/21/2010 09:09 PM, strtr wrote:
> > Could somebody please explain this error to me.
> evidently ctfe can't eat
> foreach(i, dchar d; s){
> }
> Bleach. Make sure it's in bugzilla.
Than
Could somebody please explain this error to me.
import std.uni : toUniUpper;
import std.string : capitalize;
void main()
{
const char[] name = `test`;
// C:\dmd\src\phobos\std\string.d(983): Error: _aApplycd2 cannot be
interpreted at compile time, because it has no available
== Quote from Jonathan M Davis (jmdavisp...@gmail.com)'s article
> On Sunday 18 July 2010 19:14:11 strtr wrote:
> > I'm not sure whether you missed my point or are simple thinking out loud
> > about unreachable code being a warning.
> > My point was that the unreach
== Quote from Jonathan M Davis (jmdavisp...@gmail.com)'s article
> On Sunday 18 July 2010 17:36:58 strtr wrote:
> >
> > I don't agree with this bug report because of two reasons.
> > 1. Warnings are supposed to be warnings, not errors. If you want to see
> > t
== Quote from Jonathan M Davis (jmdavisp...@gmail.com)'s article
> On Sunday 18 July 2010 00:46:36 Jonathan M Davis wrote:
> > I'll file a bug report
> >
> > - Jonathan M Davis
> Wait. That's not the problem. Or at least, that's not the problem that needs
> to
> be reported. The problem is that we
== Quote from Jonathan M Davis (jmdavisp...@gmail.com)'s article
> On Sunday 18 July 2010 10:59:21 strtr wrote:
> > I totally agree that putting a cast there is probably not really a solution
> > (or legal).
> > Warnings for all non-dchar types.
> > Is the
== Quote from Jonathan M Davis (jmdavisp...@gmail.com)'s article
> On Sunday 18 July 2010 06:16:09 strtr wrote:
> > I agree with the warning. A good warning would get people to read up on
> > UTF. And if you really want to have char you'll need to cast:
> > foreach
== Quote from Jonathan M Davis (jmdavisp...@gmail.com)'s article
> On Saturday 17 July 2010 23:01:28 strtr wrote:
> > >
> > > Cheated? I thought that you were trying to figure out why the code wasn't
> > > d oing
> > > what you expected it to be
== Quote from Jonathan M Davis (jmdavisp...@gmail.com)'s article
> On Sunday 18 July 2010 00:46:36 Jonathan M Davis wrote:
> > I'll file a bug report
> >
> > - Jonathan M Davis
> Wait. That's not the problem. Or at least, that's not the problem that needs
> to
> be reported. The problem is that we
== Quote from Jonathan M Davis (jmdavisp...@gmail.com)'s article
> On Sunday 18 July 2010 04:13:03 bearophile wrote:
> > Jonathan M Davis:
> > > You should pretty much never deal with each individual char or wchar in a
> > > string or wstring. Do the conversion to dchar or dstring if you want to
>
== Quote from Jonathan M Davis (jmdavisp...@gmail.com)'s article
> On Saturday 17 July 2010 22:10:07 strtr wrote:
> > == Quote from Jonathan M Davis (jmdavisp...@gmail.com)'s article
> >
> > > On Saturday 17 July 2010 18:59:18 strtr wrote:
>
== Quote from Jonathan M Davis (jmdavisp...@gmail.com)'s article
> On Saturday 17 July 2010 21:48:30 strtr wrote:
> > == Quote from Jonathan M Davis (jmdavisp...@gmail.com)'s article
> >
> > > On Saturday 17 July 2010 18:59:18 strtr wrote:
>
== Quote from Jonathan M Davis (jmdavisp...@gmail.com)'s article
> On Saturday 17 July 2010 18:59:18 strtr wrote:
> > That is [dollar sign, euro sign]
> >
> > The reason I post it is because I expected the stash to be 3 lower.
> Well, if I replace writef with writ
== Quote from Jonathan M Davis (jmdavisp...@gmail.com)'s article
> On Saturday 17 July 2010 18:59:18 strtr wrote:
> > That is [dollar sign, euro sign]
> >
> > The reason I post it is because I expected the stash to be 3 lower.
> As to why it's not working rig
That is [dollar sign, euro sign]
The reason I post it is because I expected the stash to be 3 lower.
What does this program print?
const char[] coins = `$�`;
void main()
{
writef(`I made `);
int stash = 0;
scope(exit) writefln(stash,`.`);
scope(failure) stash--;
foreach(coin;coins)
{
scope(exit) stash++;
scop
== Quote from torhu (n...@spam.invalid)'s article
> On 15.07.2010 02:29, strtr wrote:
> > Not that the memory is really significant compared to the rest of my
> > program,
> > but I have a few fairly large arrays I use only in compile time and I was
> > wondering
== Quote from Daniel Murphy (yebbl...@nospamgmail.com)'s article
> I think if you use enum instead of const/immutable the compiler is not meant
> to put them in the executable (it might anyway in some/all cases).
> eg.
> module main;
> enum CT_STRING = "int i=0;";
> void main(){
> mixin( CT_STRING
== Quote from strtr (st...@sp.am)'s article
> == Quote from bearophile (bearophileh...@lycos.com)'s article
> > strtr:
> > > Not that the memory is really significant compared to the rest of my
> > > program,
> > > but I have a few fairly lar
== Quote from bearophile (bearophileh...@lycos.com)'s article
> strtr:
> > Not that the memory is really significant compared to the rest of my
> > program,
> > but I have a few fairly large arrays I use only in compile time and I was
> > wondering why dmd still
Not that the memory is really significant compared to the rest of my program,
but I have a few fairly large arrays I use only in compile time and I was
wondering why dmd still includes those in the executable (simple text search
dug them up).
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
> On Tue, 29 Jun 2010 17:59:37 -0400, strtr wrote:
> > What is the pretty way to do something like this?
> >
> > Class C
> > {
> > void makeNew()
> > {
> > new typeof(thi
What is the pretty way to do something like this?
Class C
{
private const char[] _name = "C";// demangling this.mangleof didn't work
void makeNew()
{
mixin(`new `~_name~`();`); // the not so pretty part
}
}
== Quote from Simen kjaeraas (simen.kja...@gmail.com)'s article
> strtr wrote:
> >
> > void externalFunc(){}
> >
> > class C
> > {
> > ..
> > int index_;
> > int yay;
> > void removeMe()
> > {
> >
void externalFunc(){}
class C
{
..
int index_;
int yay;
void removeMe()
{
//remove last reference to this object
objects[_index] = null;
//other critical code
memberFunc();
externalFunc();
}
void memberFunc(){yay++}
}
Is there anything unsafe about his code? Li
== Quote from bearophile (bearophileh...@lycos.com)'s article
> Larry Luther:
> > For those writing documentation, I would recommend:
> >
> > http://docs.eiffel.com/book/method/et-dynamic-structure-execution-model
> >
> > If I had had something like that for D it would have saved
> > me a lot of gu
== Quote from Ellery Newcomer (ellery-newco...@utulsa.edu)'s article
> On 05/23/2010 07:35 AM, strtr wrote:
> > Did I miss it or should I add a bug report?
> http://www.digitalmars.com/d/2.0/hijack.html
That's not really the D1 spec.. a bug report it is :D
> >
> &
module e2_def;
import std.string;
static enum ENUM_2 { D, E, F };
char[] toString(ENUM_2)
{
return "ENUM_2";
}
--
module main;
import std.string : toString;
import std.stdio;
import e2_def : ENUM_2, toString;
enum ENUM { A,B }
char[] toString(ENUM e_){return "ENUM";}
void main ()
== Quote from Ellery Newcomer (ellery-newco...@utulsa.edu)'s article
> That would work except
> a) walter's hijacking fetish; if you want to overload a function with
> one imported from an external module, you'd have to do something like
> import std.string: toString;
Nice, that seems to work.
So
== Quote from Ellery Newcomer (ellery-newco...@utulsa.edu)'s article
> On 05/22/2010 08:20 PM, Ellery Newcomer wrote:
> >
> > From a discussion with walter a while back, I gathered not possible.
> Strike this line, not sure what I was thinking of here
Saves me a bit of parsing allocation ;)
== Quote from Ary Borenszweig (a...@esperanto.org.ar)'s article
> Ary Borenszweig wrote:
> > strtr wrote:
> >> Sorry, should have included this :)
> >>
> >>
> >> module main;
> >> import std.string;
> >> import std.stdio;
&
Sorry, should have included this :)
module main;
import std.string;
import std.stdio;
enum ENUM { A,B }
char[] toString(ENUM e_){return "enum";}
void main (){
writefln( toString(3) );
writefln( toString(ENUM.A) );
}
--
main.d(10): Error: function main.toString (ENUM) does n
I wanted to overload toString for my enums.
test.d(189): Error: toString (ENUM) does not match parameter types (int)
not possible?
== Quote from div0 (d...@users.sourceforge.net)'s article
> strtr wrote:
> > Is that different from making all functions within the template final?
>
> Well it delegates the choice of virtual versus non virtual to the class
> using the mixin. No idea if that's a goo
== Quote from div0 (d...@users.sourceforge.net)'s article
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> strtr wrote:
> > Or more to the point:
> >
> > Can (Class) template mixin functions be devirtualized by the compiler or do
> > I (as
> > o
Or more to the point:
Can (Class) template mixin functions be devirtualized by the compiler or do I
(as
optimization) need to manually copy paste the boiler plate code?
Will template-mixin-functions always be virtual in classes?
"Mixins can add virtual functions to a class"
http://www.digitalmars.com/d/1.0/template-mixin.html
related:
http://odefu.blogspot.com/2008/12/composite-oriented-programming.html
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
> On Sat, 15 May 2010 16:15:23 -0400, strtr wrote:
> > Should I report these bugs?
> > (and how should I call this first one?)
> >
> > module main;
> > //const S S1 = S(); //
== Quote from bearophile (bearophileh...@lycos.com)'s article
> strtr Wrote:
> > Should I report these bugs?
> Yes, add them to bugzilla. The third one is especially cute.
Was kind of expecting you to correct me or point me to the corresponding
bugzillas ;D
> > (and how s
== Quote from Don (nos...@nospam.com)'s article
> strtr wrote:
> > == Quote from bearophile (bearophileh...@lycos.com)'s article
> >> But the bigger problem in your code is that you are performing operations
> >> on
> > NaNs (that's the default
Should I report these bugs?
(and how should I call this first one?)
module main;
//const S S1 = S(); // uncomment this to compile
struct S
{
float value;
static S opCall()
{
S s;
return s;
}
const S S2 = S();
}
void main(){}
--
main.d(4): Error: struct main.S no size yet for
== Quote from bearophile (bearophileh...@lycos.com)'s article
> But the bigger problem in your code is that you are performing operations on
NaNs (that's the default initalization of FP values in D), and operations on
NaNs
are usually quite slower.
I didn't know that. Is it the same for inf?
I us
or :
module main;
//const S s = S(.5f); // Uncomment to make it compile
struct S
{
float a;
static S opCall( float a_ )
{
S s = { a_ };
return s;
}
const S _s = S( 1f );
}
void main(){}
== Quote from bearophile (bearophileh...@lycos.com)'s article
> This produces the same errors:
> struct Foo {
> int bar;
> static Foo baz() {
> return Foo();
> }
> const Foo one = Foo.baz();
> }
> void main() {}
> Bye,
> bearophile
And this is why in my program compiled any
Don Wrote:
> strtr wrote:
> > Killed it again :(
> >
>
> Are you using the latest DMD?
I was/am using 1.060
> If so, please try to create a test case,
> as this bug has never been reported before. Thanks!
Had to put some time into actual coding..
but I just tried to
Not feeding a float to ToString! seems to bring it back to life.
What is up with that anyway?
How do I output a float in compile time?
Killed it again :(
Robert Clipsham Wrote:
> On 05/05/10 23:20, strtr wrote:
> > I keep on expecting .ptr to work on all types. What keeps this from being
> > the case?
> > And how about having a .value(.deref) property for known pointers?
> >
> > I feel a lot less comfortabl
I keep on expecting .ptr to work on all types. What keeps this from being the
case?
And how about having a .value(.deref) property for known pointers?
I feel a lot less comfortable with using stars and ampersands, because I keep
on forgetting which one does what.
FeepingCreature Wrote:
> On 20.04.2010 01:49, Ellery Newcomer wrote:
> > Are there any good libraries for ctfe/code generation?
> >
> > I don't know, things like parsing support for compile time strings,
> > string formatting, type <-> string
> >
> > My project seems to be growing ctfe, and it's
Are D's operator precedence rules the same as C's?
http://www.difranco.net/cop2220/op-prec.htm
Couldn't find such a table on the D website.
Ellery Newcomer Wrote:
>
> s/interface I{}/interface I{ char[] toString(); }/
> s/writefln(two_i)/writefln("%s",two_i)/
>
> ?
no :(
>
> or see bug 535
voted ++
Is it possible to have this output [null,"1"] in stead of Error: std.format
formatArg?
interface I{}
class C:I{
int index;
char[] toString(){ return toString(index) }
}
I[2] two_i;
I[1] = new C();
writefln(two_i);
Would be handy for debugging ;)
Justin Spahr-Summers Wrote:
>
> Hmm, that is pretty weird. Are you doing any casts anywhere, or any
> pointer arithmetic/tricks?
A search for cast didn't show any related casts.
Do you maybe know another thing to check?
I do throw references around and there are a lot of implicit casts to extend
Justin Spahr-Summers Wrote:
>
> I think he said that he has two distinct object references, but the
> value stored in the object(s) changes by changing either one.
>
> In other words, we'd need to see the code.
I've added this exact sequence:
if( c1 !is null )
{
bearophile Wrote:
> Time ago I have told Walter that adding images with pointers and boxes to the
> D docs, that represent the main data structures used in D, can help a lot the
> understanding and usage of D.
>
> When you *see* the data structure in an image, understanding what happens and
>
bearophile Wrote:
> strtr:
> > Is it possible to have different vpointers/monitors pointing to the same
> > object?
>
> I think this questions is meaningless. Those pointers don't point to objects.
>
> And the "is" operator compared class re
== Quote from Justin Spahr-Summers (justin.spahrsumm...@gmail.com)'s article
> Again, without seeing the *actual* code that you are using, it's hard to
> say. The first thing that comes to mind is maybe a syntactical mistake,
> such as "i1.value = i2.value" when a comparison was intended, but ther
Ali Ãehreli Wrote:
>
> The code works as expected with 2.042
>
> I had to modify the toString() functions to return string, and say
> "override" in C's toString definition; and had to modify the writefln()
> calls:
>
>writefln("%s : %s %s", i2.toString(), i2.__vptr, i2.__monitor);
>
> Th
Jacob Carlborg Wrote:
> On 4/3/10 07:03, strtr wrote:
> > What I probably mean to ask is :
> > In the code below, for what kind of i1 and i2 would the output be like this
> > :
> > -
> > Same Value.
> > 3 : 5B536C 59D020
> > 3 : 59CE0C 59CEF
What I probably mean to ask is :
In the code below, for what kind of i1 and i2 would the output be like this :
-
Same Value.
3 : 5B536C 59D020
3 : 59CE0C 59CEF0
5 : 5B536C 59D020
5 : 59CE0C 59CEF0
-
if( i1 !is null && i2 !is null && i2.value == i1.value ) {
writefln("Same Va
Justin Spahr-Summers Wrote:
> On Fri, 02 Apr 2010 22:36:40 -0400, strtr wrote:
>
> You may want to try reducing the code within your "larger project" to
> the smallest use case where the problem still occurs, because, I agree,
> the code as written will always result
The program below outputs, as I would expect :
Same Value.
Same Object.
3 : 44E15C
3 : 44E15C
5 : 44E15C
5 : 44E15C
Now what would it mean if it were to output :
Same Value.
3 : 5B536C 59D020
3 : 59CE0C 59CEF0
5 : 5B536C 59D020
5 : 59CE0C 59CEF0
(Output from essentially the sam
Ellery Newcomer Wrote:
> I just noticed that dup does not dup deep.
>
> In a two second search I couldn't find any reason for or against, but
> I'd kinda like it if
>
> auto r2 = r.dup;
> r2[i][j] = 0;
> r[i][j] = 1;
> assert(r2[i][j] != r[i][j]);
>
> held.
There have been discussions about t
BCS Wrote:
> IIRC zero filling a block is likely cheaper that zero filling holes in it.
> I'd avoid "=void" unless you know you will be copying structs into the space
> (that will copy the holes as well).
And unless you will never compare the struct, as the garbage bits will also be
compared.
I
bearophile Wrote:
> strtr:
>
> > I suspect this isn't the case for void initialization; if my struct has
> > some alignment hole I better not void initialize it if ever I want to
> > compare it with something.
> > Is this correct?
>
> That has to be
BCS Wrote:
> Hello Strtr,
>
> > Would you ever have an alignment hole if all the struct contains are
> > basic types(excluding bool)?
>
> real, char[n], byte[n] and short[m] (for n%4 != 0 and m%2 != 0) might be
> an issue.
>
Sounds logical, thanks!
This is probably going a bit above my head, but
"the existence of alignment holes in the objects is accounted for, usually by
setting them all to 0 upon initialization"
I suspect this isn't the case for void initialization; if my struct has some
alignment hole I better not void initialize it if
Don Wrote:
> Because expressions of the form a.b[i]= c aren't yet supported in CTFE.
> It will work in a couple of compiler releases from now.
Only D2, or D1 as well?
> Workaround:
> int[2] x;
> x[0]=i1_;
> x[1]=i2_;
> res.arr=x;
>
:)
struct S{
int[2] arr = 0;
static S opCall( int i1_, int i2_) {
S res = void;
res.arr[0] = i1_;
res.arr[1] = i2_;
return res;
}
}
const S CS= S(0,0);
Why can't this be evaluated at compile time?
(And how do I
Steven Schveighoffer Wrote:
>
> But still, what does it matter? Just don't use D1 if you want a compiler
> error, or don't try and trick the system into modifying ROM! There are
> plenty of projects using D1 that just don't do this, and they are fine.
> Implementing features to help peop
grauzone Wrote:
>
> Windows can protect memory as read-only too. Why dmd doesn't do that is
> a mystery. Even if .exe doesn't support read-only data segments, the
> runtime could have done so in early start-up code.
>
If that is the case, then I'd suggest a(n enhancement?) bug-report :)
Steven Schveighoffer Wrote:
> On Mon, 22 Feb 2010 08:32:20 -0500, strtr wrote:
>
> > Daniel Keep Wrote:
> >
> >>
> >> strtr wrote:
> >> > On winXP (D1) I can compile/run this code without a problem.
> >> > Not even a warning.
>
Daniel Keep Wrote:
>
> strtr wrote:
> > On winXP (D1) I can compile/run this code without a problem.
> > Not even a warning.
> >
> > void main() {
> > char[] s= "immutable literal?";
> > s[$-1] = '!';
> > writ
On winXP (D1) I can compile/run this code without a problem.
Not even a warning.
void main() {
char[] s= "immutable literal?";
s[$-1] = '!';
writefln(s);
}
Codepad runs into a segmentation fault.
http://codepad.org/NQfsRoR5
Why doesn't it result in a compiler error or warning?
If it did I
daoryn Wrote:
>
> size_t is the default type to use as index on arrays, since the "length"
> property of arrays is of size_t. Since you are overloading the Index
> operator, its only logical the type of the index to be size_t.
>
Ah, luckily this code is not really used as it should be an opcall
or: Why does dmd keep on crashing on my code :)
(I blame it on the average D programming; they don't write enough crappy code )
After reading the -w post I tried using the -w switch again and it also
prevents me from seeing all my warning, but for a different reason : it crashes
dmd :(
Before
Don Wrote:
> Wow, seems like you and the compiler are at war...
>
I had an even more horrid dmd crash some time ago, removing a circular
selective import seemed to fix it. But I'm not sure and can't replicate it any
more :(
>
> Please put this into bugzilla. Title "ICE(interpret.c): mixin non
strtr Wrote:
> strtr Wrote:
>
> > enum { E };
> > void _mixin() {
> > writefln( E.stringof );
> > }
> > void func() {
> > mixin(_mixin);
> > }
> > Assertion failure: '!dim || (parameters && (parameters->dim == dim))&
strtr Wrote:
> enum { E };
> void _mixin() {
> writefln( E.stringof );
> }
> void func() {
> mixin(_mixin);
> }
> Assertion failure: '!dim || (parameters && (parameters->dim == dim))' on line
> 140 in file 'interpret.c'
>
enum { E };
void _mixin() {
writefln( E.stringof );
}
void func() {
mixin(_mixin);
}
Assertion failure: '!dim || (parameters && (parameters->dim == dim))' on line
140 in file 'interpret.c'
At least I got a line number this time :)
Recently I started moving all functionality within my larger classes to (10+)
templates.
abstract class AC : I
{
mixin abstractConstructors!();
mixin abstractNamedInterfaceFunctionallity_1!(); //e.g. abstractEvents!()
mixin abstractNamedInterfaceFunctionallity_2!();
..
mixin abstractNamedInterf
Trass3r Wrote:
> > Building is straightforward. Just run make -f*youros*.mak.
> Should I be offended ? ;)
>
> > Nope. I just mentioned it cause I experience it very seldom that something
> > compiles that painlessly out of the box.
Sorry, it was a lame joke. At first glance it looked like self-
Trass3r Wrote:
>
> Building is straightforward. Just run make -f*youros*.mak.
Should I be offended ?
> Works flawlessly out of the box for me with dmc on windows.
Took me only a few minutes, thanks.
But I had to install a compiler to a different language ;)
Don Wrote:
> Excellent! I can reproduce it.
> The D2 version of this code (char[] text = `Hi`.dup;) segfaults in
> Expression::arraySyntaxCopy() in expression.c, with evidence of memory
> > corruption. The D1 version does *not* segfault there. In fact the code
> compiles with the debug version o
strtr Wrote:
> dmd(1.048/55/56) crashed on me:
> AppName: dmd.exe AppVer: 0.0.0.0 ModName: unknown
> ModVer: 0.0.0.0Offset: 0002
> There is a lot of crash data but I do not know where to start looking.
> I've also tried finding which part of the code
strtr Wrote:
> dmd(1.048/55/56) crashed on me:
> I've also tried finding which part of the code is responsible, but I haven't
> found it yet.
I keep forgetting my best method yet : compiling module by module until
something strange comes up, or in this case, the compiler ch
BCS Wrote:
> Hello Strtr,
>
>
> If you can try it on linux it's not to hard to build a debug version of dmd
> and run it under the debugger. That will at least give you a filename/line
> number for the bug report and with a little thinking and a stack trace you
>
Don Wrote:
> strtr wrote:
> > dmd(1.048/55/56) crashed on me:
> > AppName: dmd.exe AppVer: 0.0.0.0 ModName: unknown
> > ModVer: 0.0.0.0 Offset: 0002
> > There is a lot of crash data but I do not know where to start looking.
> > I've als
dmd(1.048/55/56) crashed on me:
AppName: dmd.exe AppVer: 0.0.0.0 ModName: unknown
ModVer: 0.0.0.0 Offset: 0002
There is a lot of crash data but I do not know where to start looking.
I've also tried finding which part of the code is responsible, but I haven't
found it yet.
Thanks, now it looks obviously messy to me as well :)
Personally, I use (D1)std2.conv a lot to get values from strings and thus would
love the following default behaviour for all types:
int i = "0"; // i = 0
i = cast( int ) "0"; // i = 48 ( If I read the utf8 table correctly )
What keeps this from being the case?
Lars T. Kyllingstad Wrote:
> It's not undocumented, it's just badly linked-to. :)
>
> http://www.digitalmars.com/d/2.0/phobos/std_perf.html
>
> -Lars
http://www.digitalmars.com/d/1.0/phobos/std_perf.html
Stanislav Blinov Wrote:
> Pelle Månsson wrote:
> > I'm in need for a timer library that measures the acutal time. I have
> > tried std.c.time's clock(), but it only measures time spent inside the
> > program, not actual time elapsed.
> >
> > I need at least millisecond resolution, so std.c.time
g Wrote:
> g Wrote:
>
> > strtr Wrote:
> >
> > > strtr Wrote:
> > >
> > > > This error also points to the enum which is probably incorrectly used
> > > > somewhere
> > > > s_def(32) Error: cannot implicitly convert expre
Simen kjaeraas Wrote:
> On Mon, 25 Jan 2010 09:59:42 +0100, Pelle MÃ¥nsson
> wrote:
>
> > On 01/23/2010 12:29 AM, strtr wrote:
> >> Simen kjaeraas Wrote:
> >>
> >>>
> >>> Not tested, but they should work:
> >>>
> >>
strtr Wrote:
> This error also points to the enum which is probably incorrectly used
> somewhere
> s_def(32) Error: cannot implicitly convert expression (5) of type int to S
>
> Still searching for the original bug btw :(
Found it, also a return type mismatch problem; returnin
strtr Wrote:
> enum { A = 0, B, C }
>
> void func(){ return A; }
>
> void main()
> {
> }
>
> main.d(1): Error: long has no effect in expression (0)
>
> Is this a bug?
This error also points to the enum which is probably incorrectly used somewhere
s_def(32)
enum { A = 0, B, C }
void func(){ return A; }
void main()
{
}
main.d(1): Error: long has no effect in expression (0)
Is this a bug?
Simen kjaeraas Wrote:
>
> Not tested, but they should work:
>
> if ( anySame( var, a, b, c, d ) ) {
> }
>
> if ( allSame( var, a, b, c, d ) ) {
> }
>
A lot prettier.
I thought there would be a generic (basic) solution to this which I just didn't
know about but maybe I actually do know the ba
1 - 100 of 103 matches
Mail list logo
