[Issue 5056] New: Warning against virtual method call from constructor
http://d.puremagic.com/issues/show_bug.cgi?id=5056 Summary: Warning against virtual method call from constructor Product: D Version: D1 D2 Platform: Other OS/Version: Windows Status: NEW Keywords: diagnostic Severity: minor Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: bearophile_h...@eml.cc --- Comment #0 from bearophile_h...@eml.cc 2010-10-15 05:02:51 PDT --- I suggest to add a compiler suggestion/tip (a kind of warning) against (transitively) calling virtual methods inside its constructors, because doing so causes the most-derived override to be called, regardless of whether the constructor for the type that defines the most-derived override has been called. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5057] std.variant.Algebraic-aware GC
http://d.puremagic.com/issues/show_bug.cgi?id=5057
nfx...@gmail.com changed:
What|Removed |Added
CC||nfx...@gmail.com
--- Comment #1 from nfx...@gmail.com 2010-10-15 09:04:26 PDT ---
The simplest way to implement this is not using that union trick and store all
data in a templated class like this:
class VariantStorage(T) {
T data;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5057] std.variant.Algebraic-aware GC
http://d.puremagic.com/issues/show_bug.cgi?id=5057
--- Comment #2 from bearophile_h...@eml.cc 2010-10-15 09:35:53 PDT ---
(In reply to comment #1)
The simplest way to implement this is not using that union trick and store all
data in a templated class like this:
class VariantStorage(T) {
T data;
}
I don't see how a class may replace an union.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5056] Warning against virtual method call from constructor
http://d.puremagic.com/issues/show_bug.cgi?id=5056 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2010-10-15 09:47:59 PDT --- It should be noted that unlike C++ this isn't necessarily a problem in D. In C++, each class in the class's hierarchy is constructed one by one until the most derived class constructor is called. So, if you call a virtual function in a constructor, the object is not in a safe state and won't even correctly know what type it is. In D, however, the object is in a safe state. All of the classes in its hierarchy are properly put together with the default values for all their variables already initialiazed, _then_ the constructors are called. So, virtual functions will work correctly. It is perfectly safe to call them. Now, it's quite possible that you write your class poorly and a virtual function that you call in your constructor assumes that the super classes' constructors have already been called, and it doesn't do what you expect, but it's nowhere near the same problem as it is in C++. And since, unlike C++, nearly all member functions in D are virtual, you have somewhat less control over whether a function is or isn't virtual, and it will be that much harder to guarantee that a function isn't virtual. You'd be restricted to private functions and public final functions which don't override base class functions. In many cases, that is unnecessarily restrictive. So, while this is definitely a concern in C++, I'm not sure that there's much pont in worrying about it in D. D has specifically been designed to avoid the worst problems associated with calling virtual functions in a constructor. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5058] New: invariant() should not be called before opAssign()
http://d.puremagic.com/issues/show_bug.cgi?id=5058 Summary: invariant() should not be called before opAssign() Product: D Version: unspecified Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: jmdavisp...@gmx.com --- Comment #0 from Jonathan M Davis jmdavisp...@gmx.com 2010-10-15 10:03:11 PDT --- As it stands, the invariant is called before every public function is called and after every public function is called. On the whole, this is correct behavior. However, there is at least one case where this is undesirable: opAssign(). Because it is quite possible to have struct which violates its invariants (thanks to the whole init vs default constructor fiasco), it's quite easy to have a struct which was default-initialized which you're trying to assign to and which violates the invariant. So, the invariant fails and an AssertError is thrown. Since, opAssign() is theoretically supposed to completely replace the state of the object, there's no need for the object to be in a correct state prior to opAssign() being called. It obviously needs to be in a correct state afterwards, and if the invariant is run afterwards, it will catch if opAssign() did not correctly replace the state of the object such that it no longer violates its invariant. However, there's no need to call the invariant before opAssign() is called. The state prior to opAssign() is irrelevant, and calling the invariant just makes it really hard to have invariants in a struct where you can't make it so that the init value for that struct doesn't violate its invariant. So, _please_ make it so that the invariant is _not_ called prior to opAssign() being called. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4572] std.file.read return type
http://d.puremagic.com/issues/show_bug.cgi?id=4572 --- Comment #12 from Sobirari Muhomori dfj1es...@sneakemail.com 2010-10-15 10:39:39 PDT --- To me void[] stinks a lot and it's not a big deal to avoid it completely. It's an abomination from trying to evolve C concepts for D. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3570] mkdirRecurse throws exception on trailing empty directory
http://d.puremagic.com/issues/show_bug.cgi?id=3570 Shin Fujishiro rsi...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Shin Fujishiro rsi...@gmail.com 2010-10-15 10:55:24 PDT --- Fixed in the svn trunk r2104. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4775] No substitution on writef(%%%s, hi)
http://d.puremagic.com/issues/show_bug.cgi?id=4775 Shin Fujishiro rsi...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Shin Fujishiro rsi...@gmail.com 2010-10-15 10:56:15 PDT --- Fixed in the svn trunk r2105. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5049] std.algortihm.bringToFront() returns wrong value
http://d.puremagic.com/issues/show_bug.cgi?id=5049 Shin Fujishiro rsi...@gmail.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Shin Fujishiro rsi...@gmail.com 2010-10-15 10:58:08 PDT --- Fixed in the svn trunk r2103. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5059] New: String assignment in foreach loop breaks immutability
http://d.puremagic.com/issues/show_bug.cgi?id=5059
Summary: String assignment in foreach loop breaks immutability
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com
--- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2010-10-15
12:04:00 PDT ---
Since this example uses the Registry, you need Windows to compile it:
module mymodule;
import std.stdio : writeln, write;
import std.windows.registry;
void main()
{
Key HKLM = Registry.localMachine;
Key SFW = HKLM.getKey(software);
string[] names;
foreach (Key key; SFW.keys())
{
string name = key.name();
// string name = key.name().idup; // workaround for the issue
names ~= name;
}
writeln(results:);
foreach (name; names)
{
write(name, , );
}
}
The resulting string array has strings that are overwritten with each other,
and in my case the results are similar to this:
Sun Microsystems, Sun Micros, Sun , Sun Micr, Sun, Sun Mic,...
And it goes like that for a hundred or so values, then switches to the next
registry key name and writes more overwwritten strings like that.
The commented out code is the workaround, however string to string assignment
should be safe without a need for .idup.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5060] New: Order of interface implementations affects code
http://d.puremagic.com/issues/show_bug.cgi?id=5060
Summary: Order of interface implementations affects code
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com
--- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2010-10-15
12:10:27 PDT ---
Code:
interface Foo
{
final void run() { writeln(foo); }
}
interface Bar
{
final void run() { writeln(bar); }
}
class One : Foo, Bar
{
}
class Two : Bar, Foo
{
}
void main()
{
with (new One)
{
run(); // writes foo
}
with (new Two)
{
run(); // writes bar
}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3878] Arguments and members with the same name
http://d.puremagic.com/issues/show_bug.cgi?id=3878 --- Comment #8 from Sobirari Muhomori dfj1es...@sneakemail.com 2010-10-15 12:41:15 PDT --- Here we could benefit from const parameters by default. Though this won't help in a case when local variable shadows member. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4854] writefln Segmentation fault if no globals
http://d.puremagic.com/issues/show_bug.cgi?id=4854
wresch wre...@drgang.net changed:
What|Removed |Added
CC||wre...@drgang.net
--- Comment #1 from wresch wre...@drgang.net 2010-10-15 16:51:44 PDT ---
I have the exact same issue. In the code below the segfault happens in
writefln.
Setup:
Digital Mars D Compiler v2.049
OS X 10.5.3
2.26 MHz Core2 duo (macbook pro)
[510]dmd2 cat hello.d
import std.stdio;
//int x;
void main() {
writeln(hello world!);
writefln(foo = %d, 10);
}
[511]dmd2 ./hello
Segmentation fault
[515]dmd2 cat hello2.d
import std.stdio;
int x;
void main() {
writeln(hello world!);
writefln(foo = %d, 10);
}
[
[514]dmd2 ./hello2
hello world!
foo = 10
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4854] writefln Segmentation fault if no globals
http://d.puremagic.com/issues/show_bug.cgi?id=4854 Kyle Kilpatrick garfieldru...@sbcglobal.net changed: What|Removed |Added CC||garfieldru...@sbcglobal.net --- Comment #2 from Kyle Kilpatrick garfieldru...@sbcglobal.net 2010-10-15 17:04:55 PDT --- I have the same problem. In my OS X 10.5.8 installation, any program in my with a writef or writefln statement in DMD = 2.047 segfaults. Oddly, this problem is NOT present in DMD 2.046. Readf in = 2.047 also causes trouble. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4854] writefln Segmentation fault if no globals
http://d.puremagic.com/issues/show_bug.cgi?id=4854 --- Comment #3 from Kyle Kilpatrick garfieldru...@sbcglobal.net 2010-10-15 17:08:27 PDT --- My setup: Digital Mars D 2.049 OS X 10.5.8 MacBook Black early 2008 Core 2 Duo 2.4ghz -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5061] New: std.traits.arrayTarget
http://d.puremagic.com/issues/show_bug.cgi?id=5061
Summary: std.traits.arrayTarget
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: mcha...@gmail.com
--- Comment #0 from Mike Chaten mcha...@gmail.com 2010-10-15 21:44:45 PDT ---
I've been in need of getting the type of the contents of an array. Phobos
includes a function to get the type of the pointer target.
I propose a simple template, arrayTarget to std.traits to implement this
functionality.
The following works under DMD 2.049, Linux/x86
template arrayTarget(T:T[]) {
alias T arrayTarget;
}
unittest {
assert(is(arrayTarget!(int[5][]) == int[5]));
assert(is(arrayTarget!(int[5]) == int));
assert(is(arrayTarget!(int[]) == int));
assert(is(arrayTarget!(int[][]) == int[]));
assert(__traits(compiles,arrayTarget!(int)) == false);
assert(__traits(compiles,arrayTarget!(int *)) == false);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
