Re: std.concurrency wrapper over MPI?
On 2011-08-07 21:28, dsimcha wrote:
Yeah, I was trying to wrap my head around the whole "key" concept. I
wasn't very successful. I also tried out Orange and filed a few bug
reports. It may be that Orange isn't the right tool for the job for MPI,
though modulo some bug fixing and polishing it could be extremely useful
in different cases with different sets of tradeoffs.
Every serialized value has a associated key. The key should be unique in
its context but doesn't have to be unique in the whole document. A key
can be explicitly chosen, in that case that key will be used, or the
serialize can create a key (just a number that is incremented). Example:
class Foo
{
int bar;
}
auto foo = new Foo;
When serializing "foo", it will get the key "0", chosen by the
serializer. When "bar" is serialized it will use the explicit key "bar".
This way the serialization process won't depend on the order of instance
variables or struct members.
In addition to keys, all values have a associated id which is unique
across the whole document. This is used for pointers and similar which
reference other variables.
In addition to the bug reports I filed, why is it necessary to write any
serialization code to serialize through the base class? What's wrong
with just doing something like:
class Base {}
class Derived : Base {}
void main() {
auto serializer = new Serializer(new XMLArchive!());
// Introspect Derived and figure out all the details automatically.
serializer.register!(Derived);
}
I haven't thought about that, seems it would work. That will shorten the
code a lot. This is a part that has not gone through the rewrite.
Note that all documentation on the wiki pages are outdated, they only
refer to the first version, 0.0.1. The unit tests can be used as
documentation to see how to use the new version and how it behaves.
--
/Jacob Carlborg
Re: What library functionality would you most like to see in D?
"Mehrdad" wrote in message news:j1lh84$2n2j$1...@digitalmars.com... >A readText() function that would read a text file (**and** autodetect its >encoding from its BOM) would be of great help. > http://www.dsource.org/projects/semitwist/browser/trunk/src/semitwist/util/io.d#L24 I agree a function like that needs to be in Phobos, though.
Re: Post-ctor ctor
On 8/7/11 1:16 PM, Andrej Mitrovic wrote:
Just throwing an idea..
structs are great since you don't have to make a special constructor
just to initialize its fields. E.g.:
struct Foo
{
int a;
int b;
int c;
int d;
}
void main()
{
auto foo = Foo(1, 2, 3, 4);
}
But what if I add an extra couple of fields that have to be
initialized based on only the first 4 fields, and I still want to keep
the same call in the user code?
Just define a mixin and use it:
this(int a, int b, int c, int d) {
mixin(initFromParameters());
...
}
A similar macro could help assignments.
Andrei
Forcing closures to come on the stack
I just made something I thought I'd share.
It's great for those times when the compiler decides to randomly put a
closure on the heap.
The usage is pretty simple:
int x = 5;
auto adder5 = mixin(closure!x(q{(int a) { return a + x; }}));
assert(adder5(10) == 15);
It returns a callable struct whose body is the given string; the
template parameters are the variables under closure (in this case, x).
The generated code looks like (minus a little beautification on my part):
(delegate(ref int x) {
static struct State {
int* px;
@property ref int x() { return *this.px; }
auto opCall(int a) { return a + x; }
}
State tmp;
tmp.px = &x;
return tmp;
})(x)
So when you assign it to something, that something becomes a struct with
opCall overloaded. You can then take the address of opCall on the
struct, and you get a delegate.
Thoughts?
--
// Code:
string closure(States...)(string argsAndBody)
{
string stateArgs = null, stateVars = null, stateProps = null,
setStateVars = null;
alias staticMap!(StringOf, States) VarNames;
string varPtrs;
alias staticMap!(TypeStringOf, States) TypeNames;
foreach (i, varName; VarNames)
{
if (varPtrs != null) { varPtrs ~= ", "; }
if (stateArgs != null) { stateArgs ~= ", "; }
varPtrs ~= varName;
stateArgs ~= "ref " ~ TypeNames[i] ~ " " ~ varName;
stateVars ~= TypeNames[i] ~ "* ___p_" ~ varName ~ "; ";
stateProps ~= "@property ref " ~ TypeNames[i] ~ " " ~ varName ~
"() { return *this.___p_" ~ varName ~ "; } ";
setStateVars ~= "___tmp.___p_" ~ varName ~ " = &" ~ varName ~ "; ";
}
return "("
~ "delegate(" ~ stateArgs ~ ") { "
~ "static struct State { "
~ stateVars ~ ""
~ stateProps ~ ""
~ "auto opCall" ~ argsAndBody
~ ""
~ "} "
~ "State ___tmp; "
~ setStateVars
~ "return ___tmp; "
~"})(" ~ varPtrs ~ ")";
}
Re: From a C++/JS benchmark
On 8/6/2011 8:34 PM, bearophile wrote: Walter: On 8/6/2011 4:46 PM, bearophile wrote: Walter is not a lover of that -ffast-math switch. No, I am not. Few understand the subtleties of IEEE arithmetic, and breaking IEEE conformance is something very, very few should even consider. I have read several papers about FP arithmetic, but I am not an expert yet on them. Both GDC and LDC have compilation switches to perform those unsafe FP optimizations, so even if you don't like them, most D compilers today have them optional, and I don't think those switches will be removed. If you want to simulate a flock of boids (http://en.wikipedia.org/wiki/Boids ) on the screen using D, and you use floating point values to represent their speed vector, introducing unsafe FP optimizations will not harm so much. Video games are a significant purpose for D language, and in them FP errors are often benign (maybe some parts of the game are able to tolerate them and some other part of the game needs to be compiled with strict FP semantics). Bye, bearophile Floating point determinism can be very important when it comes to reducing network traffic. If you can achieve it, then you can make sure all players have the same game state and then only send user input commands over the network. Glenn Fiedler has an interesting writeup on it, but I haven't had a chance to read all of it yet: http://gafferongames.com/networking-for-game-programmers/floating-point-determinism/
Re: path tracing benchmark
Trass3r: > I ported smallpt to D some time ago and now that I've working versions of > LDC2 and GDC2 I did a quick comparison: I have converted to D many of the commonly found benchmarks, this is my version: http://codepad.org/ZbmSfseY If I compile it with with LDC1 with Link Time Optimization + Interning: ldc -O3 -release -inline -output-bc smallpt2_d.d opt -std-compile-opts smallpt2_d.bc > smallpt2_do.bc llvm-ld -native -ltango-base-ldc -ltango-user-ldc -ldl -lm -lpthread -internalize-public-api-list=_Dmain -o=smallpt2_do smallpt2_do.bc I produce a binary that's faster than the C++ version (22.7 seconds instead of 29 seconds). Bye, bearophile
Re: Two bugs found: GC bug as well as scope delegate bug
OK so apparently the GC was working fine, my bad.
I'm not sure about the compiler, though.
When I have this code:
void foo(int a, scope void delegate(int) sink)
{
sink(a);
}
void main()
{
int tmp;
foo(5, delegate(int c) { tmp = c; });
}
I get a heap allocation as soon as main() is entered. It only happens
because of the closure.
Why does this happen? Isn't the whole point of "scope" to prevent this?
(I didn't post this on the bug tracking system since I'm not sure if
it's by design or not.)
Re: Does the 'package' protection attribute not work?
On Sunday 07 August 2011 23:29:26 Robert Clipsham wrote: > On 07/08/2011 22:18, Jonathan M Davis wrote: > > Personally, I don't see much point in using the package specifier when > > you're not actually using a package hierarchy (you're just making it so > > that everything but stuff which actually uses a hierarchy can use the > > function - it would be a really weird distinction to make). So, it > > wouldn't entirely surprise me if this is completely by design. It might > > be a bug though. > Except package is ~100% useless if you use an *actual* package > hierarchy[1][2][3] (not like phobos which just drops everything in a > top-level package). > > > - Jonathan M Davis > > [1] http://d.puremagic.com/issues/show_bug.cgi?id=143 > [2] http://d.puremagic.com/issues/show_bug.cgi?id=2529 > [3] http://d.puremagic.com/issues/buglist.cgi?quicksearch=package Ah. Then package is horribly broken at the moment. Lovely. I guess that that just goes to show that it's not used heavily or there would be a lot more complaints about it. - Jonathan M Davis
Re: Does the 'package' protection attribute not work?
On Monday 08 August 2011 00:19:56 Stijn Herreman wrote:
> On 7/08/2011 23:18, Jonathan M Davis wrote:
> > On Sunday 07 August 2011 18:58:53 Stijn Herreman wrote:
> >> module main;
> >>
> >> import std.stdio;
> >> import my_module;
> >>
> >> int main()
> >> {
> >>
> >>my_method();
> >>return 0;
> >>
> >> }
> >>
> >>
> >> module my_module;
> >>
> >> import std.stdio;
> >>
> >> package void my_method()
> >> {
> >>
> >> writeln("Hello D-World!");
> >>
> >> }
> >>
> >>
> >> Error: function my_module.my_method is not accessible from main
> >
> > Hmmm. My guess would be that either it's a bug or that from D's
> > perspective, neither of your modules are in a package. They have no
> > package in front of their names; they're at the base level of the
> > hierarchy. And that might mean that they don't have a package, so they
> > don't share a package. But I don't know.
> >
> > Personally, I don't see much point in using the package specifier when
> > you're not actually using a package hierarchy (you're just making it so
> > that everything but stuff which actually uses a hierarchy can use the
> > function - it would be a really weird distinction to make). So, it
> > wouldn't entirely surprise me if this is completely by design. It might
> > be a bug though.
> >
> > - Jonathan M Davis
>
> The actual code does make use of a package hierarchy. At least, I'm
> under the impression it does: the files are in a subdirectory.
> Explicitly stating the package and module name in the files make the
> 'package' attribute work.
>
> So either the attribute does not work when the package and module name
> aren't explicitly stated, or a directory does not equal a package.
> From "The D Programming Language": "we refer to [...] a directory
> containing D source files as a package."
TDPL is correct with regards to how packages are _supposed_ to work. Whether
they _actually_ work that way at the moment, I don't know. I've rarely had use
for them, so I'm not sure that I've ever actually tried it. There's every
possibility that package is currently broken. But what you've read in TDPL is
definitely how packages are supposed to work.
- Jonathan M Davis
path tracing benchmark
I ported smallpt to D some time ago and now that I've working versions of LDC2 and GDC2 I did a quick comparison: Original code: http://kevinbeason.com/smallpt/explicit.cpp D version: https://bitbucket.org/trass3r/smallptd/src C++ -- g++ -O3 explicit.cpp: Rendering (4 spp) 100.00% real0m28.477s user0m26.470s sys 0m0.160s D -- dmd -release -O -inline -noboundscheck smallpt.d -ofsmallptDMD: real1m32.687s user1m30.820s sys 0m0.300s D -- gdc -frelease -fno-bounds-check -O3 smallpt.d -o smallptGDC: real0m52.598s user0m48.900s sys 0m0.150s D -- ldc2 -O3 -release -enable-inlining smallpt.d -ofsmallptLDC: real0m39.622s user0m36.100s sys 0m0.240s
Re: std.path review: final version(?)
On Sat, 06 Aug 2011 14:25:40 -0700, Jonathan M Davis wrote: > On Thursday 04 August 2011 10:55:31 Lars T. Kyllingstad wrote: >> Since the voting is supposed to start today (not in this thread; >> dsimcha will annouce it), here is the (hopefully) final version of >> std.path: >> >> https://github.com/kyllingstad/phobos/blob/std-path/std/path.d >> http://www.kyllingen.net/code/std-path/phobos-prerelease/ std_path.html >> >> New commits since the last update (dated 2011-08-03 and 2011-08-04) are >> listed here: >> >> https://github.com/kyllingstad/phobos/commits/std-path >> >> Highlights: >> >> - extension() now returns the dot together with the extension - The >> dot is optional in set-/defaultExtension() - Removed normalize(), >> since it simply called buildNormalizedPath() >> >> I kept the longer names for *Extension and *Separator, because >> >> - I personally like them better; they are clear and consistent - >> Jonathan is the only one who seems to really dislike them - There is >> ample precedent for longish function names in Phobos (see >> std.algorithm, for instance) > > As a reminder, before you create a pull request for the new std.path > (which looks like it'll probably make it in via a unanimous vote in > favor), you need to replace the aliases for the old functions with the > actual old functions (since the behavior has changed for a number of > them) and mark them as scheduled for deprecation in their documentation > instead of deprecating them. Thanks for the reminder. I'll make sure to do this. -Lars
Re: macro keyword taken?
On 07/08/2011 23:59, Andrej Mitrovic wrote:
So I wanted to make myself a template called "macro", but it turns out
it's a keyword:
template macro()
{
}
test.d(7): TemplateIdentifier expected following template
test.d(7): Declaration expected, not 'macro'
Is there something planned with this keyword?
It was originally going to be used in D2 for AST macros, however it was
found that string mixins (an already existing feature) were already as
powerful as the proposed AST macros. As such, the keyword is reserved
for future use, possibly in D3 once the details have been reconsidered.
There's a video lying around somewhere of Walter presenting what would
have been macros somewhere if you're interested.
--
Robert
http://octarineparrot.com/
macro keyword taken?
So I wanted to make myself a template called "macro", but it turns out
it's a keyword:
template macro()
{
}
test.d(7): TemplateIdentifier expected following template
test.d(7): Declaration expected, not 'macro'
Is there something planned with this keyword?
Re: CTFE writeln again (__ctfeWriteln)
KennyTM~: > __ctfeWrite is not complex, but I don't see the need for it. I don't understand your point. Given __ctfeWrite you are able to create a __ctfeWriteln but you can't do the opposite. If I have to print something complex, like something tree-shaped, and I have just __ctfeWriteln, to create the printing I need to first put everything into a huge string, and print it. If I have __ctfeWrite I am able to write it one bit at a time. Not having a compulsive newline was the strongest requirement in my original enhancement request: http://d.puremagic.com/issues/show_bug.cgi?id=3952 The obligatory newline of pragma(msg) has given me several problems, it's much less useful because of this. Bye, bearophile
Re: CTFE writeln again (__ctfeWriteln)
On 08.08.2011 1:38, KennyTM~ wrote: Pull request: https://github.com/D-Programming-Language/dmd/pull/296 Previous discussion: http://www.digitalmars.com/d/archives/digitalmars/D/CTFE_writeln_140241.html This is the 2nd try to add a compile-time printing facility to D. The previous pull request uses std.stdio.writeln which causes some concern, and then left unattended for a few weeks after the last comment. So I go for my 2nd alternative, which is to add a magic function __ctfeWriteln that does the same. In my implementation, __ctfeWriteln will print the interpreted arguments to stdmsg when CTFE-ed, and is a no-op in runtime (it can be configured to throw an exception or actually print the arguments or anything you like). It's indeed a valuable built in, hopefully it'll get pulled, debugging C-T vs R-T inconsistencies is quite a painful exercise ATM. -- Dmitry Olshansky
Re: CTFE writeln again (__ctfeWriteln)
On Aug 8, 11 05:56, bearophile wrote: KennyTM~: So I go for my 2nd alternative, which is to add a magic function __ctfeWriteln that does the same. In my implementation, __ctfeWriteln will print the interpreted arguments to stdmsg when CTFE-ed, and is a no-op in runtime (it can be configured to throw an exception or actually print the arguments or anything you like). Important: if there is a single function then I do *not* want it to print a newline. Adding a newline when you need it is much simpler than removing it if you do not want it. If you really want a newline too, then create two functions, (similar to write and writeln), but the most important is the one without newline. What's the purpose of the two leading underscores? I prefer it without them. This is supposed to be a clean and nice function, not an unsafe ugly thing :-) So I think a "ctfeWrite" name is better. Two leading underscores means it's a reserved identifier which should have no chance of collision. It does not mean unsafe. Also, it's named after the existing identifier '__ctfe'. Generally I'd like this functions to print equally at compile-time and run-time, but I see there are some problems in doing this... If the function"ctfeWrite" becomes too much complex (to print arbitrary things), then for me it's acceptable it to print just strings too (with no newline added). __ctfeWrite is not complex, but I don't see the need for it. Bye and thank you for your work, bearophile
Re: Does the 'package' protection attribute not work?
On 07/08/2011 22:18, Jonathan M Davis wrote: Personally, I don't see much point in using the package specifier when you're not actually using a package hierarchy (you're just making it so that everything but stuff which actually uses a hierarchy can use the function - it would be a really weird distinction to make). So, it wouldn't entirely surprise me if this is completely by design. It might be a bug though. Except package is ~100% useless if you use an *actual* package hierarchy[1][2][3] (not like phobos which just drops everything in a top-level package). - Jonathan M Davis [1] http://d.puremagic.com/issues/show_bug.cgi?id=143 [2] http://d.puremagic.com/issues/show_bug.cgi?id=2529 [3] http://d.puremagic.com/issues/buglist.cgi?quicksearch=package -- Robert http://octarineparrot.com/
Re: Does the 'package' protection attribute not work?
On 7/08/2011 23:18, Jonathan M Davis wrote:
On Sunday 07 August 2011 18:58:53 Stijn Herreman wrote:
module main;
import std.stdio;
import my_module;
int main()
{
my_method();
return 0;
}
module my_module;
import std.stdio;
package void my_method()
{
writeln("Hello D-World!");
}
Error: function my_module.my_method is not accessible from main
Hmmm. My guess would be that either it's a bug or that from D's perspective,
neither of your modules are in a package. They have no package in front of
their names; they're at the base level of the hierarchy. And that might mean
that they don't have a package, so they don't share a package. But I don't
know.
Personally, I don't see much point in using the package specifier when you're
not actually using a package hierarchy (you're just making it so that
everything but stuff which actually uses a hierarchy can use the function - it
would be a really weird distinction to make). So, it wouldn't entirely
surprise me if this is completely by design. It might be a bug though.
- Jonathan M Davis
The actual code does make use of a package hierarchy. At least, I'm
under the impression it does: the files are in a subdirectory.
Explicitly stating the package and module name in the files make the
'package' attribute work.
So either the attribute does not work when the package and module name
aren't explicitly stated, or a directory does not equal a package.
From "The D Programming Language": "we refer to [...] a directory
containing D source files as a package."
Re: Tagging of arguments ref/out, or just out
Max Klyga: > So this feature has to be either mandatory or not. Making it optional > leads to confusion as Jonathan mentioned. On this, what I have suggested it not the same thing that the original proposal says. In the original proposal the "ref" and "out" are optional. In my alternative proposal if you compile with "-w" you are sure that the compiler will ask you "out" at the calling point too. > But it's kinda late to change the language now, with all the code outthere. It will take some more years to have enough D2 code out there to make a breaking but incremental change like this too much costly for people. (In Bugzilla I have few more little breaking changes that are more important than this "out" thing. And other things will need to be fixed, in "const" etc. Several of them will break D code in ways more costly than requiring to add a "out" in code here and there). Bye, bearophile
Re: CTFE writeln again (__ctfeWriteln)
KennyTM~: > So I go for my 2nd alternative, which is to add a magic function > __ctfeWriteln > that does the same. > > In my implementation, __ctfeWriteln will print the interpreted arguments > to stdmsg when CTFE-ed, and is a no-op in runtime (it can be configured > to throw an exception or actually print the arguments or anything you like). Important: if there is a single function then I do *not* want it to print a newline. Adding a newline when you need it is much simpler than removing it if you do not want it. If you really want a newline too, then create two functions, (similar to write and writeln), but the most important is the one without newline. What's the purpose of the two leading underscores? I prefer it without them. This is supposed to be a clean and nice function, not an unsafe ugly thing :-) So I think a "ctfeWrite" name is better. Generally I'd like this functions to print equally at compile-time and run-time, but I see there are some problems in doing this... If the function"ctfeWrite" becomes too much complex (to print arbitrary things), then for me it's acceptable it to print just strings too (with no newline added). Bye and thank you for your work, bearophile
CTFE writeln again (__ctfeWriteln)
Pull request: https://github.com/D-Programming-Language/dmd/pull/296 Previous discussion: http://www.digitalmars.com/d/archives/digitalmars/D/CTFE_writeln_140241.html This is the 2nd try to add a compile-time printing facility to D. The previous pull request uses std.stdio.writeln which causes some concern, and then left unattended for a few weeks after the last comment. So I go for my 2nd alternative, which is to add a magic function __ctfeWriteln that does the same. In my implementation, __ctfeWriteln will print the interpreted arguments to stdmsg when CTFE-ed, and is a no-op in runtime (it can be configured to throw an exception or actually print the arguments or anything you like).
Re: std.concurrency wrapper over MPI?
This would probably work with the protobuf format.
Sent from my iPhone
On Aug 7, 2011, at 12:28 PM, dsimcha wrote:
> On 8/7/2011 2:27 PM, Jacob Carlborg wrote:
>> On 2011-08-07 17:45, dsimcha wrote:
>>> On 8/7/2011 11:36 AM, Jacob Carlborg wrote:
Currently, the only available format is XML.
>>>
>>> Ok, I'll look into writing a binary archiver that assumes that the CPU
>>> architecture on the deserializing end is the same as that on the
>>> serializing end. If it works, maybe Orange is a good choice.
>>
>> Sounds good. I just hope that the current design allows for a binary
>> archive. Currently the serializer in Orange assumes that an archive can
>> deserialize a value based on a key which could be basically anywhere in
>> the serialized data. This allows at least to implement archives which
>> store the serialized data in a structured format, e.g. XML, JSON, YAML.
>> I don't know if that's possible with a binary format, I'm not familiar
>> with how to implement a binary format.
>>
>
> Yeah, I was trying to wrap my head around the whole "key" concept. I wasn't
> very successful. I also tried out Orange and filed a few bug reports. It
> may be that Orange isn't the right tool for the job for MPI, though modulo
> some bug fixing and polishing it could be extremely useful in different cases
> with different sets of tradeoffs.
>
> In addition to the bug reports I filed, why is it necessary to write any
> serialization code to serialize through the base class? What's wrong with
> just doing something like:
>
> class Base {}
> class Derived : Base {}
>
> void main() {
>auto serializer = new Serializer(new XMLArchive!());
>
>// Introspect Derived and figure out all the details automatically.
>serializer.register!(Derived);
> }
>
Re: Does the 'package' protection attribute not work?
On Sunday 07 August 2011 18:58:53 Stijn Herreman wrote:
> module main;
>
> import std.stdio;
> import my_module;
>
> int main()
> {
> my_method();
> return 0;
> }
>
>
> module my_module;
>
> import std.stdio;
>
> package void my_method()
> {
>writeln("Hello D-World!");
> }
>
>
> Error: function my_module.my_method is not accessible from main
Hmmm. My guess would be that either it's a bug or that from D's perspective,
neither of your modules are in a package. They have no package in front of
their names; they're at the base level of the hierarchy. And that might mean
that they don't have a package, so they don't share a package. But I don't
know.
Personally, I don't see much point in using the package specifier when you're
not actually using a package hierarchy (you're just making it so that
everything but stuff which actually uses a hierarchy can use the function - it
would be a really weird distinction to make). So, it wouldn't entirely
surprise me if this is completely by design. It might be a bug though.
- Jonathan M Davis
Re: Tagging of arguments ref/out, or just out
One the main reasons c# has mandatory out and ref at call site is code
versioning. If some function took an argument by value but was changed
to take if by reference, without annotations compiler would treat this
as an error, preventing a potential bug.
So this feature has to be either mandatory or not. Making it optional
leads to confusion as Jonathan mentioned.
But it's kinda late to change the language now, with all the code outthere.
On 2011-08-07 23:42:30 +0300, bearophile said:
This is a recently opened (not by me) enhancement request thread:
http://d.puremagic.com/issues/show_bug.cgi?id=6442
It proposes something that I remember was discussed and refused two
times in past: to require (but only optionally!) "ref" and "out" at the
calling point, as C#4 instead always requires (optionally for COM):
void foo(ref int bar) { ... }
int i = 0;
foo(ref i); // <--- here
void foo(out int bar) { ... }
int i = 0;
foo(out i); // <--- here
Jonathan M Davis has then argued that they clutter the code, and that
making them optional makes them kind of useless. See the thread for
more details.
-
After thinking some about it, I have suggested a related but
alternative proposal: to ask only for the "out" at the calling point,
make it obligatory if you compile with -warning and optional otherwise
(for a long time "override" was like this). I think having "out" at the
calling point is more useful than "ref".
Currently D 2.054 gives no warnings/errors on a program like this (I
think the C# compiler gives something here):
void foo(out int x) {
x = 5;
}
void main() {
int y = 10;
foo(y);
}
The problem here is the initialization of y to 10 always gets ignored.
Assigning something to y, *not using y in any way*, and then using it
in a "out" function argument call, is in my opinion a code smell. It's
wasted code at best, and sometimes it's related to possible semantic
bugs.
Using "out" at the calling point doesn't fix that code, but helps the
programmer to see that the assign of 10 to y is useless, and it's
better to remove it:
void foo(out int x) {
x = 5;
}
void main() {
int y = 10;
foo(out y);
}
In my opinion "ref" arguments don't have the same need of being tagged
at the calling point because a function that uses "ref" often reads and
writes the argument (otherwise you use "in" or "out"), so in a ref
argument assigning something to y before the call is more often
meaningful:
void foo(ref int x) {
x++;
}
int main() {
int y = 10;
return foo(y);
}
Bye,
bearophile
Tagging of arguments ref/out, or just out
This is a recently opened (not by me) enhancement request thread:
http://d.puremagic.com/issues/show_bug.cgi?id=6442
It proposes something that I remember was discussed and refused two times in
past: to require (but only optionally!) "ref" and "out" at the calling point,
as C#4 instead always requires (optionally for COM):
void foo(ref int bar) { ... }
int i = 0;
foo(ref i); // <--- here
void foo(out int bar) { ... }
int i = 0;
foo(out i); // <--- here
Jonathan M Davis has then argued that they clutter the code, and that making
them optional makes them kind of useless. See the thread for more details.
-
After thinking some about it, I have suggested a related but alternative
proposal: to ask only for the "out" at the calling point, make it obligatory if
you compile with -warning and optional otherwise (for a long time "override"
was like this). I think having "out" at the calling point is more useful than
"ref".
Currently D 2.054 gives no warnings/errors on a program like this (I think the
C# compiler gives something here):
void foo(out int x) {
x = 5;
}
void main() {
int y = 10;
foo(y);
}
The problem here is the initialization of y to 10 always gets ignored.
Assigning something to y, *not using y in any way*, and then using it in a
"out" function argument call, is in my opinion a code smell. It's wasted code
at best, and sometimes it's related to possible semantic bugs.
Using "out" at the calling point doesn't fix that code, but helps the
programmer to see that the assign of 10 to y is useless, and it's better to
remove it:
void foo(out int x) {
x = 5;
}
void main() {
int y = 10;
foo(out y);
}
In my opinion "ref" arguments don't have the same need of being tagged at the
calling point because a function that uses "ref" often reads and writes the
argument (otherwise you use "in" or "out"), so in a ref argument assigning
something to y before the call is more often meaningful:
void foo(ref int x) {
x++;
}
int main() {
int y = 10;
return foo(y);
}
Bye,
bearophile
Re: Run Microsoft Analyzer over dmd source code
Vladimir Panteleev: > Done: > http://dump.thecybershadow.net/b1e4cb6ef0a8d3c5f54d5cb09ddd1a9e/DMD.log There are only 10 NULL deference warnings left: s2ir.c(1043): warning C6011: Dereferencing NULL pointer 'pu++' s2ir.c(980): warning C6011: Dereferencing NULL pointer 'cases' statement.c(3666): warning C6011: Dereferencing NULL pointer 'tbret' template.c(5353): warning C6011: Dereferencing NULL pointer 'sds' todt.c(536): warning C6011: Dereferencing NULL pointer 'type' todt.c(746): warning C6011: Dereferencing NULL pointer 'var' module.c(793): warning C6011: Dereferencing NULL pointer 'sc' mtype.c(4887): warning C6011: Dereferencing NULL pointer 'fparam->type' mtype.c(8130): warning C6011: Dereferencing NULL pointer 'arg->type' root\root.c(1498): warning C6011: Dereferencing NULL pointer 'f->touchtime' Bye, bearophile
Re: Run Microsoft Analyzer over dmd source code
On Sun, 07 Aug 2011 22:11:35 +0300, Vladimir Panteleev wrote: On Sun, 07 Aug 2011 21:45:45 +0300, bearophile wrote: Vladimir Panteleev: http://thecybershadow.net/d/vcanalysis/ As with (first report of) Clang I see that assert(p); p->foo... are marked as "Dereferencing NULL pointer". Ah, that would probably be in files that #include instead of "tassert.h". (Odd that Microsoft's code analyzer doesn't understand the standard assert facility.) I'll try fixing that. Done: http://dump.thecybershadow.net/b1e4cb6ef0a8d3c5f54d5cb09ddd1a9e/DMD.log HTML files updated in place. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: std.concurrency wrapper over MPI?
On 8/7/2011 2:27 PM, Jacob Carlborg wrote:
On 2011-08-07 17:45, dsimcha wrote:
On 8/7/2011 11:36 AM, Jacob Carlborg wrote:
Currently, the only available format is XML.
Ok, I'll look into writing a binary archiver that assumes that the CPU
architecture on the deserializing end is the same as that on the
serializing end. If it works, maybe Orange is a good choice.
Sounds good. I just hope that the current design allows for a binary
archive. Currently the serializer in Orange assumes that an archive can
deserialize a value based on a key which could be basically anywhere in
the serialized data. This allows at least to implement archives which
store the serialized data in a structured format, e.g. XML, JSON, YAML.
I don't know if that's possible with a binary format, I'm not familiar
with how to implement a binary format.
Yeah, I was trying to wrap my head around the whole "key" concept. I
wasn't very successful. I also tried out Orange and filed a few bug
reports. It may be that Orange isn't the right tool for the job for
MPI, though modulo some bug fixing and polishing it could be extremely
useful in different cases with different sets of tradeoffs.
In addition to the bug reports I filed, why is it necessary to write any
serialization code to serialize through the base class? What's wrong
with just doing something like:
class Base {}
class Derived : Base {}
void main() {
auto serializer = new Serializer(new XMLArchive!());
// Introspect Derived and figure out all the details automatically.
serializer.register!(Derived);
}
Re: Post-ctor ctor
Trass3r:
> > this(int this.a, int this.b, int this.c, int this.d) {
> > sum = a + b + c + d;
> > average = (a + b + c + d) / 4;
> > }
>
> Can't express how awkward this is.
Why don't you try to express how awkward it is?
Well, code like this is shorter than what the OP has suggested, it's DRY, it's
probably easy to understand (I think you don't need to go look into D docs
every time you see something like this), it's easy to type, it avoids a common
bug in my code (caused by mixing fields and arguments in the constructor):
this(this.a, this.b, this.c, this.d) {
sum = a + b + c + d;
average = (a + b + c + d) / 4;
}
Bye,
bearophile
Re: Run Microsoft Analyzer over dmd source code
On Aug 8, 11 03:08, KennyTM~ wrote: On Aug 8, 11 02:45, bearophile wrote: Vladimir Panteleev: http://thecybershadow.net/d/vcanalysis/ As with (first report of) Clang I see that assert(p); p->foo... are marked as "Dereferencing NULL pointer". Do you know the purpose of this? os->name = strdup(name); warning C4996: 'strdup': The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _strdup. See online help for details. c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\string.h(238) : see declaration of 'strdup' http://stackoverflow.com/questions/14386/fopen-deprecated-warning Oops sorry that link is for those silly _s versions. _strdup is actually worse, it's only because Microsoft has chosen to add a '_' to all POSIX functions with no good reason (maybe just §17.6.4.3.2=[global.names]/1). http://msdn.microsoft.com/en-us/library/y471khhc%28v=VS.100%29.aspx I recommend ignoring all C4996 since the DMD source code shouldn't just accommodate for MSVC. And do you know what kind of troubles this warning helps to avoid? c:\projects\extern\d\dmd\src\root\dchar.h(164): warning C6328: 'char' passed as parameter '1' when 'unsigned char' is required in call to 'isalpha' You could search the error code in Google to get the info in MSDN. http://msdn.microsoft.com/en-us/library/ms245348%28v=VS.100%29.aspx: "For routines starting with is*, passing an argument of type char might yield unpredictable results. For example, an SBCS or MBCS single-byte character of type char with a value greater than 0x7F is negative. If a char is passed, the compiler might convert the value to a signed int or a signed long. This value could be sign-extended by the compiler, with unexpected results." Bye, bearophile
Re: Run Microsoft Analyzer over dmd source code
On Sun, 07 Aug 2011 21:45:45 +0300, bearophile wrote: Vladimir Panteleev: http://thecybershadow.net/d/vcanalysis/ As with (first report of) Clang I see that assert(p); p->foo... are marked as "Dereferencing NULL pointer". Ah, that would probably be in files that #include instead of "tassert.h". (Odd that Microsoft's code analyzer doesn't understand the standard assert facility.) I'll try fixing that. Do you know the purpose of this? os->name = strdup(name); warning C4996: 'strdup': The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _strdup. See online help for details. c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\string.h(238) : see declaration of 'strdup' I don't think there's more to it than what the message says - a recommendation to use the ISO C++ conformant name instead of the deprecated POSIX name. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: Run Microsoft Analyzer over dmd source code
On Aug 8, 11 02:45, bearophile wrote: Vladimir Panteleev: http://thecybershadow.net/d/vcanalysis/ As with (first report of) Clang I see that assert(p); p->foo... are marked as "Dereferencing NULL pointer". Do you know the purpose of this? os->name = strdup(name); warning C4996: 'strdup': The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _strdup. See online help for details. c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\string.h(238) : see declaration of 'strdup' http://stackoverflow.com/questions/14386/fopen-deprecated-warning And do you know what kind of troubles this warning helps to avoid? c:\projects\extern\d\dmd\src\root\dchar.h(164): warning C6328: 'char' passed as parameter '1' when 'unsigned char' is required in call to 'isalpha' You could search the error code in Google to get the info in MSDN. http://msdn.microsoft.com/en-us/library/ms245348%28v=VS.100%29.aspx: "For routines starting with is*, passing an argument of type char might yield unpredictable results. For example, an SBCS or MBCS single-byte character of type char with a value greater than 0x7F is negative. If a char is passed, the compiler might convert the value to a signed int or a signed long. This value could be sign-extended by the compiler, with unexpected results." Bye, bearophile
Re: Post-ctor ctor
this(int this.a, int this.b, int this.c, int this.d) {
sum = a + b + c + d;
average = (a + b + c + d) / 4;
}
Can't express how awkward this is.
Re: Run Microsoft Analyzer over dmd source code
On Aug 7, 11 22:23, Vladimir Panteleev wrote:
On Sun, 07 Aug 2011 13:29:20 +0300, Walter Bright
wrote:
It's less complex (!) if you are not trying to make a working dmd. It
just needs to compile.
OK, that wasn't actually too bad.
https://github.com/CyberShadow/dmd/tree/compile-on-vs10
2979 warnings with code analysis with the "Microsoft Minimum Recommended
Rules" ruleset.
http://dump.thecybershadow.net/2e0571641194d945869a1b12b29aacdc/DMD.log
I'll see if I can get it in a more readable format (something like the
HTML files clang's scan-build outputs).
Just at a glance, half of them are false positive, or is arguably safe:
1. 382 (13%) of them are C4996 (use those Microsoft _s functions)
2. 401 (13%) of them are C4068 (unknown pragma)
3. 505 (17%) of them are C6328 (passing 'signed char' to the ctype
functions)
4. 67 (2%) of them are C6239 (true && something) or C6240 (something &&
true) - many of them are of them (!I16 && stuff), so that's legacy code
for 16-bit platform??
5. 37 (1%) of them are C6255 (using alloca) or C6263 (using alloca in a
loop).
6. 56 (2%) of them are C4305 or C4309 (double -> float)
And 37% of them can be caught trivially with some -Wall flag.
4. 262 (9%) of them are C4244 (stuff like int64 -> int32)
5. 415 (14%) of them are C4018 (signed/unsigned comparison)
6. 157 (5%) of them are C4101 (unused locals)
7. 50 (2%) of them are C4102 (unused labels)
8. 212 (7%) of them are C6246 or C6244 or C4258 (local variable name
hiding outer scope)
9. 8 (0.3%) of them are C4390 ('if(stuff);')
The really interesting things:
8. 117 (4%) of them are C6211 (leak on exception) - but a bigger problem
is DMD is using too much memory even without leaking.
9. 34 (1%) of them are C6001 (using uninitialized memory)
10. 125 (4%) of them are C6011 (NULL dereferencing)
11. 6 (0.2%) of them are C6386 and 17 (0.6%) of them are C6385 (buffer
overrun)
Re: Run Microsoft Analyzer over dmd source code
On Sun, 07 Aug 2011 21:47:07 +0300, bearophile wrote: Vladimir Panteleev: Could you please elaborate? The list of links is sorted alphabetically, so files under "root" are lower down the list. What do you see if you click on a link like "root\root.c"? Ah! I didn't reproduce the problem, but I know what it is - I didn't bother replacing Windows' backslashes with forward slashes. Will fix. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: Run Microsoft Analyzer over dmd source code
Vladimir Panteleev: > http://thecybershadow.net/d/vcanalysis/ As with (first report of) Clang I see that assert(p); p->foo... are marked as "Dereferencing NULL pointer". Do you know the purpose of this? os->name = strdup(name); warning C4996: 'strdup': The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _strdup. See online help for details. c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\string.h(238) : see declaration of 'strdup' And do you know what kind of troubles this warning helps to avoid? c:\projects\extern\d\dmd\src\root\dchar.h(164): warning C6328: 'char' passed as parameter '1' when 'unsigned char' is required in call to 'isalpha' Bye, bearophile
Re: Run Microsoft Analyzer over dmd source code
Vladimir Panteleev: > Could you please elaborate? The list of links is sorted alphabetically, so > files under "root" are lower down the list. What do you see if you click on a link like "root\root.c"? Bye, bearophile
Re: Post-ctor ctor
> With that idea your struct becomes:
Or just:
struct Foo {
int a, b, c, d, sum, average;
this(this.a, this.b, this.c, this.d) {
sum = a + b + c + d;
average = (a + b + c + d) / 4;
}
}
Bye,
bearophile
Re: std.concurrency wrapper over MPI?
On 2011-08-07 18:01, Lutger Blijdestijn wrote: dsimcha wrote: On 8/7/2011 11:36 AM, Jacob Carlborg wrote: Currently, the only available format is XML. Ok, I'll look into writing a binary archiver that assumes that the CPU architecture on the deserializing end is the same as that on the serializing end. If it works, maybe Orange is a good choice. Just in case you missed it, the messagepack protocol has a D implementation which seems to be what you're looking for: http://msgpack.org/ The last commit on bitbucket reveals it should be compatible with 2.054. Perhaps it can be adapted as an archiver for Orange. I think it should be possible. -- /Jacob Carlborg
Re: std.concurrency wrapper over MPI?
On 2011-08-07 17:58, dsimcha wrote: On 8/7/2011 11:36 AM, Jacob Carlborg wrote: Good to know, but what flavor? As I see it there is a three-way tradeoff in serialization. In order of importance for distributed parallelism, the qualities are: I can answer these tradeoff for the Orange serialization library, http://dsource.org/projects/orange/. BTW, I know this has been discussed in the past, but I'll bring it up again. Since serialization is pretty fundamental to a lot of things and I want to avoid dependency hell, what are the prospects for getting Orange into Phobos? To get Orange into Phobos, at least this most be done: * Actually finishing the rewrite (I'm almost done, the basic stuff works) * Add more unit tests * Add documentation * Rip out all D1 and Tango related code * Some minor changes to follow the Phobos style guide, I have not followed the 80-120 column limit * The XML module in Phobos needs some minor updates * I've used my own kind of mini unit test framework, don't know if people like that, should be easy to remove I think that's all. -- /Jacob Carlborg
Re: Post-ctor ctor
Andrej Mitrovic:
> Good idea / bad idea?
I prefer a solution that to me looks simpler, discussed a bit here:
http://d.puremagic.com/issues/show_bug.cgi?id=3878
With that idea your struct becomes:
struct Foo {
int a, b, c, d, sum, average;
this(int this.a, int this.b, int this.c, int this.d) {
sum = a + b + c + d;
average = (a + b + c + d) / 4;
}
}
Bye,
bearophile
Re: What library functionality would you most like to see in D?
On 8/7/2011 3:21 AM, Jonathan M Davis wrote:
On Sunday 07 August 2011 14:08:06 Dmitry Olshansky wrote:
On 07.08.2011 12:09, Mehrdad wrote:
A readText() function that would read a text file (**and** autodetect
its encoding from its BOM) would be of great help.
Well the name is here, dunno if it meets your expectations:
http://d-programming-language.org/phobos/std_file.html#readText
...
What Mehrdad wants is a way to read in a file with an encoding other than
UTF-8, UTF-16, or UTF-32, have it autodetect the encoding by reading the file's
BOM, and then convert it it to whatever encoding is that the character type
that readText is using uses.
Yeah, although I don't mean anything /other/ than those -- I only care
about Unicode, but I think it should be auto-detected, not based on the
template parameter.
On 8/7/2011 6:21 AM, Andrei Alexandrescu wrote:
I think we could and should change readText to do the BOM trick. It's
been on my mind forever.
I /do/ have an implementation, but it's (1) only for Windows, (2)
hastily written (no error checking or whatever), and (3) doesn't work
for UTF-16 BE (although it works for LE), and (4) only returns the
result in UTF-8.
It's a starting point, though. An added bonus is the fact that it
actually looks at the file data as well, so the heuristic is rather nice.
pragma(lib, "advapi32.lib");
extern(Windows) BOOL IsTextUnicode(in void* pBuffer, int cb, int* lpi);
string readText(const(char)[] name)
{
auto data = cast(char[])file.read(name);
int test = 0x;
if (IsTextUnicode(data.ptr, data.length, &test))
{ return (cast(wchar[])(test & 0x00088 ? data[2 .. $] :
data)).toUTF8(); }
else
{ return (data.startsWith([0xEF, 0xBB, 0xBF]) ? data[3 .. $] :
data).toUTF8(); }
}
Re: Run Microsoft Analyzer over dmd source code
On Sun, 07 Aug 2011 21:28:18 +0300, bearophile wrote: Vladimir Panteleev: http://thecybershadow.net/d/vcanalysis/ I don't see the pages in inner directories like "root\root.c". Could you please elaborate? The list of links is sorted alphabetically, so files under "root" are lower down the list. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: Run Microsoft Analyzer over dmd source code
On Sun, 07 Aug 2011 21:17:30 +0300, Walter Bright wrote: Try the All Rules. Ah, my mistake. The rulesets only apply to managed (.NET) code. It looks like C/C++ code analysis is just an on/off switch. http://msdn.microsoft.com/en-us/library/d3bbz7tz(v=vs.80).aspx -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: Run Microsoft Analyzer over dmd source code
Vladimir Panteleev: > http://thecybershadow.net/d/vcanalysis/ I don't see the pages in inner directories like "root\root.c". Bye, bearophile
Re: Two bugs found: GC bug as well as scope delegate bug
On 8/7/2011 1:15 AM, KennyTM~ wrote: On Aug 7, 11 14:47, Mehrdad wrote: Everyone, apologies for this in hindsight, it's quite ridiculous. x_x In trying to reproduce a similar bug I saw in my code, I made a completely stupid example which made no sense. I'll proofread better next time, hopefully I can isolate it then. Next time you should file the bug directly to bugzilla (http://d.puremagic.com/issues/). OK sure.
Re: std.concurrency wrapper over MPI?
On 2011-08-07 17:45, dsimcha wrote: On 8/7/2011 11:36 AM, Jacob Carlborg wrote: Currently, the only available format is XML. Ok, I'll look into writing a binary archiver that assumes that the CPU architecture on the deserializing end is the same as that on the serializing end. If it works, maybe Orange is a good choice. Sounds good. I just hope that the current design allows for a binary archive. Currently the serializer in Orange assumes that an archive can deserialize a value based on a key which could be basically anywhere in the serialized data. This allows at least to implement archives which store the serialized data in a structured format, e.g. XML, JSON, YAML. I don't know if that's possible with a binary format, I'm not familiar with how to implement a binary format. -- /Jacob Carlborg
Re: std.concurrency wrapper over MPI?
On 2011-08-07 18:15, Sean Kelly wrote: I was mostly wondering if the serialized was all template code or if the archived portion used some form of polymorphism. Sounds like its the latter. The serializer uses template methods, the archive uses interfaces and virtual methods. Sent from my iPhone On Aug 7, 2011, at 8:19 AM, Jacob Carlborg wrote: On 2011-08-07 02:24, Sean Kelly wrote: Is the archive formatter dynamically pluggable? I'm not exactly sure what you mean but you can create new archive types and use them with the existing serializer. When creating a new serializer it takes an archive (as an interface) as a parameter. Sent from my iPhone On Aug 6, 2011, at 11:51 AM, Jacob Carlborg wrote: On 2011-08-06 18:32, Sean Kelly wrote: I'd love to be able to send classes between processes, but first we need a good serialization/deserialization mechanism. Have a look at Orange, I don't know if it's considered good but it works for almost all types available in D, the only available archive is currently XML. http://dsource.org/projects/orange/ -- /Jacob Carlborg -- /Jacob Carlborg -- /Jacob Carlborg
Re: Run Microsoft Analyzer over dmd source code
On 8/7/2011 10:43 AM, bearophile wrote: and there's that cast to float he overlooked, sabotaging his upgrade. Even worse, suppose the type of f or d or both is changed to some user defined type, like BigFloat? That cast is just going to *cause* a bug, not fix it. Requiring the programmer to load up on casts is not necessarily making the code less "bug-prone". Thank you for your good explanation. I presume this doesn't improve the situation a lot: float f; double d; ... f = cast(f.typeof)d; That can improve things for the case where f is available, but that isn't always the case (such as when passing d to a function that takes a float parameter).
Re: Run Microsoft Analyzer over dmd source code
On 8/7/2011 11:06 AM, Vladimir Panteleev wrote: I'll see if I can get it in a more readable format (something like the HTML files clang's scan-build outputs). http://thecybershadow.net/d/vcanalysis/ Very nice!
Re: Run Microsoft Analyzer over dmd source code
On 8/7/2011 11:13 AM, Vladimir Panteleev wrote: On Sun, 07 Aug 2011 20:11:49 +0300, bearophile wrote: Later a higher level will show other warnings. I have the following levels to choose from: Microsoft All Rules Microsoft Basic Correctness Rules Microsoft Basic Design Guideline Rules Microsoft Extended Correctness Rules Microsoft Extended Design Guideline Rules Microsoft Globalization Rules Microsoft Minimum Recommended Rules Microsoft Security Rules I imagine that higher settings will have higher signal-to-noise ratios, but I can re-run it on another ruleset if anyone's interested. Try the All Rules.
Post-ctor ctor
Just throwing an idea..
structs are great since you don't have to make a special constructor
just to initialize its fields. E.g.:
struct Foo
{
int a;
int b;
int c;
int d;
}
void main()
{
auto foo = Foo(1, 2, 3, 4);
}
But what if I add an extra couple of fields that have to be
initialized based on only the first 4 fields, and I still want to keep
the same call in the user code? Here's a hypothetical case:
struct Foo
{
int a;
int b;
int c;
int d;
int sum;
int average;
post this() // post-ctor ctor
{
sum = a + b + c + d;
average = (a + b + c + d) / 4;
}
}
void main()
{
auto foo = Foo(1, 2, 3, 4);
}
A post-construction ctor would do any final initializations after
field initialization, or after a call to a custom ctor. Otherwise I
would have to write:
struct Foo
{
int a;
int b;
int c;
int d;
int sum;
int average;
this(int a, int b, int c, int d)
{
this.a = a;
this.b = b;
this.c = c;
this.d = d;
postCtor();
}
private void postCtor()
{
sum = a + b + c + d;
average = (a + b + c + d) / 4;
}
}
void main()
{
auto foo = Foo(1, 2, 3, 4);
}
I see that as needlessly implementing in user-code what the compiler
can already do on its own. If we had a post-ctor ctor, partial
initialization could be done via field initialization instead of using
a hand-written ctor, and then a post-ctor would initialize the rest of
the fields.
Good idea / bad idea?
I have a feeling this would clash with that "can't have a default ctor
on a struct" rule. I just hate having to manually write ctors for
cases where the first N fields are initialized in order while the rest
need special initialization.
Re: Run Microsoft Analyzer over dmd source code
On Sun, 07 Aug 2011 20:11:49 +0300, bearophile wrote: Later a higher level will show other warnings. I have the following levels to choose from: Microsoft All Rules Microsoft Basic Correctness Rules Microsoft Basic Design Guideline Rules Microsoft Extended Correctness Rules Microsoft Extended Design Guideline Rules Microsoft Globalization Rules Microsoft Minimum Recommended Rules Microsoft Security Rules I imagine that higher settings will have higher signal-to-noise ratios, but I can re-run it on another ruleset if anyone's interested. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: Run Microsoft Analyzer over dmd source code
On Sun, 07 Aug 2011 17:23:48 +0300, Vladimir Panteleev wrote: I'll see if I can get it in a more readable format (something like the HTML files clang's scan-build outputs). http://thecybershadow.net/d/vcanalysis/ Created with: https://github.com/CyberShadow/ColorerVCLog -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: From a C++/JS benchmark
Anyways, I've tweaked the GDC codegen, and program speed meets that of C++ now (on my system). Implementation: http://ideone.com/0j0L1 Command-line: gdc -O3 -mfpmath=sse -ffast-math -march=native -frelease g++ bench.cc -O3 -mfpmath=sse -ffast-math -march=native Best times: G++-32bit: 1140 vps GDC-32bit: 1135 vps Regards Iain 64Bit: C++: 4501 4427 4274 4390 4468 4349 4239 GDC: 4290 4401 4400 4401 4401 4400 GDC with -fno-bounds-check: 4328 4442 4434 4445
Re: Run Microsoft Analyzer over dmd source code
On 07/08/2011 18:34, Walter Bright wrote: On 8/7/2011 7:23 AM, Vladimir Panteleev wrote: 2979 warnings with code analysis with the "Microsoft Minimum Recommended Rules" ruleset. http://dump.thecybershadow.net/2e0571641194d945869a1b12b29aacdc/DMD.log Thanks, this is what I was looking for! I'll see if I can get it in a more readable format (something like the HTML files clang's scan-build outputs). clang's format is more readable, but it's actually rather agonizing to go through because it takes upwards of a minute for each report to load. When there are hundreds to look at, you're looking at hours of waiting. It's actually instant[1], the only reason it seemed so slow for you is because the html is on my (wireless) home server, and you were connecting to my web server which was proxying all the content with no caching (yay quick hacks) - so you had to put up with my slow upload speeds and slow wireless as well as the proxying. [1] This is based on me accessing it locally or across my home network. -- Robert http://octarineparrot.com/
Re: Run Microsoft Analyzer over dmd source code
Walter: > and there's that cast to float he overlooked, sabotaging his upgrade. Even > worse, suppose the type of f or d or both is changed to some user defined > type, > like BigFloat? That cast is just going to *cause* a bug, not fix it. > > Requiring the programmer to load up on casts is not necessarily making the > code > less "bug-prone". Thank you for your good explanation. I presume this doesn't improve the situation a lot: float f; double d; ... f = cast(f.typeof)d; Bye, bearophile
Re: Run Microsoft Analyzer over dmd source code
On 8/7/2011 7:23 AM, Vladimir Panteleev wrote: 2979 warnings with code analysis with the "Microsoft Minimum Recommended Rules" ruleset. http://dump.thecybershadow.net/2e0571641194d945869a1b12b29aacdc/DMD.log Thanks, this is what I was looking for! I'll see if I can get it in a more readable format (something like the HTML files clang's scan-build outputs). clang's format is more readable, but it's actually rather agonizing to go through because it takes upwards of a minute for each report to load. When there are hundreds to look at, you're looking at hours of waiting.
Re: Run Microsoft Analyzer over dmd source code
On 8/7/2011 10:11 AM, bearophile wrote: It contains FP warnings like the one I have asked for D too. DMD doesn't perform certain unsafe FP operations because they and break IEEE conformance, but casting a double to float is accepted and regarded "safe" (I am not sure of this): lexer.c(2500): warning C4244: 'initializing' : conversion from 'double' to 'float', possible loss of data You mean implicit casting of double to float. Yes, it is accepted without complaint by dmd. The problem with requiring a cast is a cast is a blunt instrument: float f; double d; ... f = (float) d; Now, suppose the maintenance guy decides to upgrade f to being a double to get more precision: double f; double d; ... f = (float) d; and there's that cast to float he overlooked, sabotaging his upgrade. Even worse, suppose the type of f or d or both is changed to some user defined type, like BigFloat? That cast is just going to *cause* a bug, not fix it. Requiring the programmer to load up on casts is not necessarily making the code less "bug-prone".
Re: Run Microsoft Analyzer over dmd source code
Vladimir Panteleev: > 2979 warnings with code analysis with the "Microsoft Minimum Recommended > Rules" ruleset. Thank you. Info about this minimum level: http://msdn.microsoft.com/en-us/library/dd264893.aspx Later a higher level will show other warnings. > http://dump.thecybershadow.net/2e0571641194d945869a1b12b29aacdc/DMD.log It contains FP warnings like the one I have asked for D too. DMD doesn't perform certain unsafe FP operations because they and break IEEE conformance, but casting a double to float is accepted and regarded "safe" (I am not sure of this): lexer.c(2500): warning C4244: 'initializing' : conversion from 'double' to 'float', possible loss of data There are 21 warnings like: C:\Projects\Extern\D\dmd\src\tk\vec.c(493): warning C4102: 'Lret' : unreferenced label Hours ago I have asked for this warning in D: http://d.puremagic.com/issues/show_bug.cgi?id=6449 A bit of statistics. There are 114 warnings like: backend\cgcs.c(656): warning C4018: '<' : signed/unsigned mismatch And there are 134 warnings like (this is the most common): c:\projects\extern\d\dmd\src\root\dchar.h(164): warning C6328: 'char' passed as parameter '1' when 'unsigned char' is required in call to 'isalpha' Bye, bearophile
Does the 'package' protection attribute not work?
module main;
import std.stdio;
import my_module;
int main()
{
my_method();
return 0;
}
module my_module;
import std.stdio;
package void my_method()
{
writeln("Hello D-World!");
}
Error: function my_module.my_method is not accessible from main
Re: std.concurrency wrapper over MPI?
On 8/6/2011 12:32 PM, Sean Kelly wrote: I'd love to be able to send classes between processes, but first we need a good serialization/deserialization mechanism. The more I think about it, the more I think that std.concurrency isn't quite the right interface for cluster parallelism. I'm thinking instead of doing something loosely based on, but not a translation of, boost::mpi. The following differences between std.concurrency and what makes sense for MPI bother me: 1. shared/immutable isn't needed when you're copying the data anyhow. 2. spawn() is taken care of by the MPI runtime. 3. std.concurrency doesn't support broadcasting.
Re: std.concurrency wrapper over MPI?
I was mostly wondering if the serialized was all template code or if the archived portion used some form of polymorphism. Sounds like its the latter. Sent from my iPhone On Aug 7, 2011, at 8:19 AM, Jacob Carlborg wrote: > On 2011-08-07 02:24, Sean Kelly wrote: >> Is the archive formatter dynamically pluggable? > > I'm not exactly sure what you mean but you can create new archive types and > use them with the existing serializer. When creating a new serializer it > takes an archive (as an interface) as a parameter. > >> Sent from my iPhone >> >> On Aug 6, 2011, at 11:51 AM, Jacob Carlborg wrote: >> >>> On 2011-08-06 18:32, Sean Kelly wrote: I'd love to be able to send classes between processes, but first we need a good serialization/deserialization mechanism. >>> >>> Have a look at Orange, I don't know if it's considered good but it works >>> for almost all types available in D, the only available archive is >>> currently XML. http://dsource.org/projects/orange/ >>> >>> -- >>> /Jacob Carlborg > > > -- > /Jacob Carlborg
Re: std.concurrency wrapper over MPI?
Nope. It would represent an external destination and defines the protocol. Sent from my iPhone On Aug 6, 2011, at 6:57 PM, dsimcha wrote: > On 8/6/2011 8:26 PM, Sean Kelly wrote: >> I'm hoping to simply extend the existing API. The crucial portion will be >> the addition of a Node (base) type. > > So Node would be the equivalent of Tid in the current API?
Re: std.concurrency wrapper over MPI?
On 8/7/2011 12:01 PM, Lutger Blijdestijn wrote: dsimcha wrote: On 8/7/2011 11:36 AM, Jacob Carlborg wrote: Currently, the only available format is XML. Ok, I'll look into writing a binary archiver that assumes that the CPU architecture on the deserializing end is the same as that on the serializing end. If it works, maybe Orange is a good choice. Just in case you missed it, the messagepack protocol has a D implementation which seems to be what you're looking for: http://msgpack.org/ The last commit on bitbucket reveals it should be compatible with 2.054. Perhaps it can be adapted as an archiver for Orange. Ok, this sounds great. Again, though, it would be great to get serialization into Phobos. (I don't know whether messagepack is suitable in its current form, because I haven't looked in detail.) I was vaguely aware of a messagepack implementation for D, but I didn't realize it was still maintained and didn't know where it was hosted.
Re: std.concurrency wrapper over MPI?
dsimcha wrote: > On 8/7/2011 11:36 AM, Jacob Carlborg wrote: >> Currently, the only available format is XML. > > Ok, I'll look into writing a binary archiver that assumes that the CPU > architecture on the deserializing end is the same as that on the > serializing end. If it works, maybe Orange is a good choice. Just in case you missed it, the messagepack protocol has a D implementation which seems to be what you're looking for: http://msgpack.org/ The last commit on bitbucket reveals it should be compatible with 2.054. Perhaps it can be adapted as an archiver for Orange.
Re: std.concurrency wrapper over MPI?
link for the D implementation: https://bitbucket.org/repeatedly/msgpack4d/
Re: std.concurrency wrapper over MPI?
On 8/7/2011 11:36 AM, Jacob Carlborg wrote: Good to know, but what flavor? As I see it there is a three-way tradeoff in serialization. In order of importance for distributed parallelism, the qualities are: I can answer these tradeoff for the Orange serialization library, http://dsource.org/projects/orange/. BTW, I know this has been discussed in the past, but I'll bring it up again. Since serialization is pretty fundamental to a lot of things and I want to avoid dependency hell, what are the prospects for getting Orange into Phobos?
Re: std.concurrency wrapper over MPI?
On 8/7/2011 11:36 AM, Jacob Carlborg wrote: Currently, the only available format is XML. Ok, I'll look into writing a binary archiver that assumes that the CPU architecture on the deserializing end is the same as that on the serializing end. If it works, maybe Orange is a good choice.
Re: std.concurrency wrapper over MPI?
On 2011-08-07 00:09, dsimcha wrote: On 8/6/2011 5:38 PM, jdrewsen wrote: AFAIK David Nadlinger is handling serialization in his GSOC Thrift project that he is working on currently. /Jonas Good to know, but what flavor? As I see it there is a three-way tradeoff in serialization. In order of importance for distributed parallelism, the qualities are: I can answer these tradeoff for the Orange serialization library, http://dsource.org/projects/orange/. 1. Efficiency. How much does it cost to serialize/unserialize something and how much space overhead is there? I haven't done any measurements but I would guess it depends on which archive type is used. The actual serializer tries to do quite a lot, where possible, at compile time. But it also stores a reference for every serialized value, in the case a pointer points to the value. 2. Flexibility w.r.t. types: How many types can be serialized? How faithfully are they reproduced on the other end w.r.t. things like pointer/reference/slice aliasing? If I haven't missed something Orange can serialize almost all types, except unions, function pointers, void pointers and delegates. 3. Standardization: How universally understood is the format? Can it be used to send data across different CPU architectures? Across languages? Is it human readable? Is it based on some meta-format like XML? Currently, the only available format is XML. -- /Jacob Carlborg
Re: const assignments problem again
On 2011-08-07 03:19, bearophile wrote: I have discussed about this topic once in past, but in the meantime I have seen this is a quite common problem, so I think it doesn't harm to touch this topic again. This is a direct D translation of the original C or C++ code: // version #1 double foo; if (abs(e.x - v.x)> double.min) foo = (v.y - e.y) / (v.x - e.x); else foo = double.max; If D's statements were expressions instead, this could work: const foo = if (abs(e.x - v.x)> double.min) (v.y - e.y) / (v.x - e.x); else double.max; -- /Jacob Carlborg
Re: std.concurrency wrapper over MPI?
On 2011-08-07 02:24, Sean Kelly wrote: Is the archive formatter dynamically pluggable? I'm not exactly sure what you mean but you can create new archive types and use them with the existing serializer. When creating a new serializer it takes an archive (as an interface) as a parameter. Sent from my iPhone On Aug 6, 2011, at 11:51 AM, Jacob Carlborg wrote: On 2011-08-06 18:32, Sean Kelly wrote: I'd love to be able to send classes between processes, but first we need a good serialization/deserialization mechanism. Have a look at Orange, I don't know if it's considered good but it works for almost all types available in D, the only available archive is currently XML. http://dsource.org/projects/orange/ -- /Jacob Carlborg -- /Jacob Carlborg
Re: Template struct literals should infer template parameters
On Sat, 06 Aug 2011 20:19:06 +, Sean Eskapp wrote:
> If I have something like
>
> struct S(T)
> {
> T data;
> }
>
>
> I can't make a struct literal with
>
> int mystuff;
> someFunc(S(mystuff));
It has been the same in C++. The reason is that the syntax above would
conflict with and is reserved for a templated constructor.
> I have to use
>
> int mystuff;
> someFunc(S!(int)(mystuff));
>
> Why is this?
To allow flexibility by not tieing the struct's template parameters to
its constructor's template parameters. Deduction actually works for the
constructor:
struct S(T)
{
T data;
this(U)(U)
{}
}
void someFunc(T)(T)
{}
void main()
{
double d;
someFunc(S!int(d));
}
The constructor's template parameter is being deduced as 'double' on the
last line.
Ali
Re: Run Microsoft Analyzer over dmd source code
Am 07.08.2011, 16:23 Uhr, schrieb Vladimir Panteleev : On Sun, 07 Aug 2011 13:29:20 +0300, Walter Bright wrote: It's less complex (!) if you are not trying to make a working dmd. It just needs to compile. OK, that wasn't actually too bad. https://github.com/CyberShadow/dmd/tree/compile-on-vs10 2979 warnings with code analysis with the "Microsoft Minimum Recommended Rules" ruleset. http://dump.thecybershadow.net/2e0571641194d945869a1b12b29aacdc/DMD.log I'll see if I can get it in a more readable format (something like the HTML files clang's scan-build outputs). I start to think, the closer a code analysis tool is to '0 warnings' the better it is :p
Re: Run Microsoft Analyzer over dmd source code
On Sun, 07 Aug 2011 13:29:20 +0300, Walter Bright wrote: It's less complex (!) if you are not trying to make a working dmd. It just needs to compile. OK, that wasn't actually too bad. https://github.com/CyberShadow/dmd/tree/compile-on-vs10 2979 warnings with code analysis with the "Microsoft Minimum Recommended Rules" ruleset. http://dump.thecybershadow.net/2e0571641194d945869a1b12b29aacdc/DMD.log I'll see if I can get it in a more readable format (something like the HTML files clang's scan-build outputs). -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: like types
bearophile: > Is this the same thing you are saying? Yeah, though in D you'd have to use objects and interfaces rather than primitives. Casting to the interface would return null if it doesn't match, so it compiles but then errors at runtime.
Re: What library functionality would you most like to see in D?
On 8/7/11 5:08 AM, Dmitry Olshansky wrote: On 07.08.2011 12:09, Mehrdad wrote: A readText() function that would read a text file (**and** autodetect its encoding from its BOM) would be of great help. Well the name is here, dunno if it meets your expectations: http://d-programming-language.org/phobos/std_file.html#readText I think we could and should change readText to do the BOM trick. It's been on my mind forever. Andrei
Re: const assignments problem again
Timon Gehr wrote: > Lutger Blijdestin wrote: >> I like the ternary operator the best for this, as it is the simplest. I >> always write them like this though, liberally include parenthesis and >> never nest: >> (condition) >> ? (truth value) >> : (false value) > > What is the benefit of this, compared to leaving parentheses away > entirely? Oh, I didn't mean to *always* include parenthesis. Just that when a more complicated expression is involved, I find it often faster to understand if there are some redundant parenthesis.
Re: like types
Adam D. Ruppe Wrote:
> This seems to be to be nothing more than applying the same
> idea behind objects and interfaces to other types... if all
> variables were typed Object and you had:
>
> interface Int {}
> interface String {}
>
> void whatever(Int lineno, String rawdata) {}
>
> it'd be the same thing, would it not?
In their language (here adapted to D syntax) this compiles with no errors, and
it gives an error at runtime in the first line of foo, because the dynamic type
of x is string, and it's not like an int:
int foo(like int y) { return y + 1; }
void main() {
dyn x = "bar";
foo(x);
}
Is this the same thing you are saying?
Bye,
bearophile
Re: const assignments problem again
Lutger Blijdestin wrote: > I like the ternary operator the best for this, as it is the simplest. I > always write them like this though, liberally include parenthesis and never > nest: > (condition) > ? (truth value) > : (false value) What is the benefit of this, compared to leaving parentheses away entirely?
Re: const assignments problem again
bearophile wrote: ... > In my precedent post about this topic I have discussed "nested constness" > and another partially silly idea. Recently I have seen a language that > suggests me this: > > // version #6 > const foo; > if (abs(e.x - v.x) > double.min) > foo = (v.y - e.y) / (v.x - e.x); > else > foo = double.max; > > > The compiler makes sure all paths assign values with the same type to foo > (as in the case of the two returns inside the delegate, that must be of > the same type). But if you introduce goto instructions version #6 looks > fragile. If the assign is far away from the definition the code looks not > so nice any more, so this feature is meant for short-range initializations > only. > > Bye, > bearophile I like the ternary operator the best for this, as it is the simplest. I always write them like this though, liberally include parenthesis and never nest: (condition) ? (truth value) : (false value) When it gets more complicated, you can always rewrite either the whole expression (to if/else or a function) or refactor parts of the expression to small functions. I never find this to be much of a burden. Python has if/else expressions, but due to it's (messy) scoping rules I almost never find them an improvement to if/else statements. I like the single assignment feature, but not for this reason. I think it would be more useful for creating immutable data in general.
Re: Run Microsoft Analyzer over dmd source code
On 8/7/2011 3:24 AM, Vladimir Panteleev wrote: Before that, someone first needs to get dmd to even compile with Visual C++. It's not a trivial task - there is no complex number support, lots of compiler-dependent defines are outdated, and there seem to be tons of regular compiler warnings (mostly signed/unsigned comparisons and long to int/etc. assignments). It's less complex (!) if you are not trying to make a working dmd. It just needs to compile.
Re: Run Microsoft Analyzer over dmd source code
On Sat, 06 Aug 2011 22:38:15 +0300, Walter Bright wrote: http://www.reddit.com/r/programming/comments/jar93/john_carmack_gives_his_thoughts_on_static/c2akmf8 If someone has this on their system, I think it'd be great if you could run the dmd source code through it and see if it finds any bugs. Before that, someone first needs to get dmd to even compile with Visual C++. It's not a trivial task - there is no complex number support, lots of compiler-dependent defines are outdated, and there seem to be tons of regular compiler warnings (mostly signed/unsigned comparisons and long to int/etc. assignments). -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: What library functionality would you most like to see in D?
On Sunday 07 August 2011 14:08:06 Dmitry Olshansky wrote: > On 07.08.2011 12:09, Mehrdad wrote: > > A readText() function that would read a text file (**and** autodetect > > its encoding from its BOM) would be of great help. > > Well the name is here, dunno if it meets your expectations: > http://d-programming-language.org/phobos/std_file.html#readText D (and Phobos in general) assumes that char in UTF-8, wchar is UTF-16, and dchar is UTF-32. You're going to get an exception thrown pretty quickly if you're trying to use those types with values that don't match those encodings. As such, readText assumes that the file is in whatever encoding the character type is that it's instantiated with. So, if you try and read in a file which doesn't match the character encoding of the character type that you're using (which is char by default), you're going to get a UtfException. What Mehrdad wants is a way to read in a file with an encoding other than UTF-8, UTF-16, or UTF-32, have it autodetect the encoding by reading the file's BOM, and then convert it it to whatever encoding is that the character type that readText is using uses. readText doesn't currently do anything of the sort. At this point, dealing with anything which has an encoding other than UTF-8, UTF-16, or UTF-32 is problematic in D. std.encoding helps, but it's not necessarily all that good (Andrei considers it a failed experiment which either needs to be redesigned or removed). So, one of the things that still needs to be figured out for Phobos is how to better handle encodings other than UTF-8, UTF-16, and UTF-32. For the most part, other encodings are likely to be dealt with only when reading or writing I/O while UTF-8, UTF-16, and UTF-32 are dealt with inside of D programs, but we still need to fix things so that we can readily deal with I/O that isn't UTF-8, UTF-16, or UTF-32. - Jonathan M Davis
Re: const assignments problem again
On Sunday 07 August 2011 06:02:36 Kagamin wrote: > Jonathan M Davis Wrote: > > Being able to use const can be very valuable. For instance, what if you > > were using std.algorithm.copy and got the arguments backwards? If the > > source is const, then the compiler will complain, and you'll quickly > > find the bug. If the source isn't const, then you could accidentally > > end up copying the target to the source, and it may or may not be an > > easy bug to catch. > > I've seen a bug. I fixed two methods: begin and end and sent the patch to a > man. They were calling other methods (sort of begin1 and end1). The man > slightly fixed my patch and copied the fixed body of the first method to > both of them (they look very similar). The compiler was happy, the > application even worked. The bug was catched only because I checked whether > the man did it right. ??? I don't understand what you're trying to say. I don't know if your English is just poor or if you're trying to make fun of me. const has value. It obviously doesn't solve everything or catch every bug, but it can help a lot in ensuring that variables that are not supposed to be mutated aren't mutated. You can choose not to use it, and that's fine, but it's part of the language, and many other people value it highly. - Jonathan M Davis
Re: What library functionality would you most like to see in D?
On 07.08.2011 12:09, Mehrdad wrote: A readText() function that would read a text file (**and** autodetect its encoding from its BOM) would be of great help. Well the name is here, dunno if it meets your expectations: http://d-programming-language.org/phobos/std_file.html#readText -- Dmitry Olshansky
Re: const assignments problem again
Jonathan M Davis Wrote: > Being able to use const can be very valuable. For instance, what if you were > using std.algorithm.copy and got the arguments backwards? If the source is > const, then the compiler will complain, and you'll quickly find the bug. If > the > source isn't const, then you could accidentally end up copying the target to > the source, and it may or may not be an easy bug to catch. I've seen a bug. I fixed two methods: begin and end and sent the patch to a man. They were calling other methods (sort of begin1 and end1). The man slightly fixed my patch and copied the fixed body of the first method to both of them (they look very similar). The compiler was happy, the application even worked. The bug was catched only because I checked whether the man did it right.
Re: const assignments problem again
bearophile Wrote: > - You can't use "auto" there, so if the type of e.x changes, you have to > change the foo type manually (double.min is replaceable with typeof(e.x).min). This is a bad idea too. The code assumes the values are double. If this assumption is not true, the code is broken.
Re: const assignments problem again
On Sunday 07 August 2011 04:40:52 Kagamin wrote: > bearophile Wrote: > > - And foo can't be const or immutable, I don't like this. > > I suppose accidental overwrite bugs are overrated. I have never seen them > even from evil programmers. If you write random code, overwrite is not your > only problem, you can as well read wrong variable or call wrong function. > No language will help you if your code is junk. You should fix this in a > different way. Being able to use const can be very valuable. For instance, what if you were using std.algorithm.copy and got the arguments backwards? If the source is const, then the compiler will complain, and you'll quickly find the bug. If the source isn't const, then you could accidentally end up copying the target to the source, and it may or may not be an easy bug to catch. I made that exact mistake in C++ with its copy function just the other day. const saved me a lot of headaches. Now, I think that D gives us enough ways to deal with the problem that Bearophile illustrates here (and Bearophile actually showed us a number of ways that D allows us to do what he's trying to do), so I don't think that we really need to do anything to the language to better deal with this situation. But accidental overwrites _can_ be a problem, and that's one of the things that const catches. So, not being able to use const when you should logically be able to due to syntax problems in the language would definitely be a problem - not the biggest problem ever perhaps, but it _would_ be a problem. Fortunately however, D gives us plenty of ways to get around the problem. - Jonathan M Davis
Re: like types
Walter Bright Wrote: > On 8/6/2011 7:24 PM, bearophile wrote: > > C#4 has "dynamic" type, it allows to perform dynamic typing style code in > > C#: > > http://en.wikipedia.org/wiki/C_sharp_4#Dynamic_member_lookup > > D has opDispatch which fills that role nicely. opDispatch doesn't work with interfaces and you can't call it on an Object.
Re: const assignments problem again
bearophile Wrote: > - And foo can't be const or immutable, I don't like this. I suppose accidental overwrite bugs are overrated. I have never seen them even from evil programmers. If you write random code, overwrite is not your only problem, you can as well read wrong variable or call wrong function. No language will help you if your code is junk. You should fix this in a different way.
Re: const assignments problem again
P.S. you would make a better point if it were a const instance of a class.
Re: Two bugs found: GC bug as well as scope delegate bug
On Aug 7, 11 14:47, Mehrdad wrote: Everyone, apologies for this in hindsight, it's quite ridiculous. x_x In trying to reproduce a similar bug I saw in my code, I made a completely stupid example which made no sense. I'll proofread better next time, hopefully I can isolate it then. Next time you should file the bug directly to bugzilla (http://d.puremagic.com/issues/).
Re: What library functionality would you most like to see in D?
A readText() function that would read a text file (**and** autodetect its encoding from its BOM) would be of great help.
Re: Template struct literals should infer template parameters
On Sat, Aug 6, 2011 at 22:19, Sean Eskapp wrote:
> If I have something like
>
> struct S(T)
> {
> T data;
> }
>
> I can't make a struct literal with
>
> int mystuff;
> someFunc(S(mystuff));
>
> I have to use
>
> int mystuff;
> someFunc(S!(int)(mystuff));
>
> Why is this?
Yeah, function templates have a way to automatically determine their
template parameters (IFTI : Implicit Function Template
Instantiation?), but that doesn't work with struct and class
constructors. Too bad.
You can use a factory function to do just that, it's a one-liner:
auto s(T)(T t) { return S!(T)(t); }
and then:
someFunc(s(mystuff));
Re: const assignments problem again
Am 07.08.2011, 06:31 Uhr, schrieb Adam D. Ruppe : bearophile: I agree, that's why I have added two more points The precedence of the ternary is pretty easy to handle - if there's more than one thing in there, just use parenthesis. That's the only thing I can think of that would make it any more bug prone than other branches. Perhaps it'd be worth thinking if parens should be required in any non-trivial cases. auto a = something ? "one" : "two"; // ok auto b = a ~ something ? "one" : "two"; // error, please add parens for clarity - It is less maintainable I don't agree that changing to an if is any burden at all. This is like saying "if(x) y;" is unacceptable because you might have to add braces later. Real maintenance headaches are things like duplicated code or unnecessary complexity. This is just a very simple case of syntax translation. The anonymous function solution looks good to me. You have full flexibility while keeping the variable const and the initialization code is at the declaration site.
