[Issue 4420] New: insertBack() for SList
http://d.puremagic.com/issues/show_bug.cgi?id=4420 Summary: insertBack() for SList Product: D Version: D2 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: jmdavisp...@gmail.com --- Comment #0 from Jonathan M Davis jmdavisp...@gmail.com 2010-07-03 22:57:31 PDT --- SList has an insertFront() but not an insertBack(). I assume that this is because SList is a singly linked list and the last element does not have a link to the element before it (in fact, looking at the implementation, you don't even keep track of the last element). However, if you keep track of just a bit more than the head node, you can implement insertBack() as well better optimize some of its functions (like findLastNode()). If you kept track of the last node in addition to the first one, then you have the last node for functions like findLastNode() and you can have back() and insertBack(). For that matter, if you made it the last two nodes, then you could have popBack() as well. Now, that may complicate the other list operations too much to be worthwhile, but it would expand SList's capabilities without unduly increasing how much memory it takes like you would with a doubly linked list. So, it may be a bad idea when you really get down to it, but I thought that I should at least suggest it since it would make SList more versatile. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4420] insertBack() for SList
http://d.puremagic.com/issues/show_bug.cgi?id=4420 Jonathan M Davis jmdavisp...@gmail.com changed: What|Removed |Added Severity|normal |enhancement -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4420] insertBack() for SList
http://d.puremagic.com/issues/show_bug.cgi?id=4420 Andrei Alexandrescu and...@metalanguage.com changed: What|Removed |Added CC||and...@metalanguage.com --- Comment #1 from Andrei Alexandrescu and...@metalanguage.com 2010-07-04 02:01:26 PDT --- SList can't implement insertBack due to complexity requirements. To append to a list, use lst.insertAfter(lst[], stuff). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4420] insertBack() for SList
http://d.puremagic.com/issues/show_bug.cgi?id=4420 --- Comment #2 from Jonathan M Davis jmdavisp...@gmail.com 2010-07-04 02:40:40 PDT --- Which complexity requirements? I understand that it can't do it as is because that would be O(n). I was pointing out that it kept track of the last element in addition to the first one, it could implement insertBack() in O(1) without needing the extra space per node that a doubly linked list requires. And if it keeps track of the next-to-last node as well, then it can implement popBack() in O(1) as well. Is it that other operations no longer fit the appropriate complexity requirements if it keeps track of the last element in addition to the first? I would think that the other operations would have the same complexity but with (in some cases) a slightly higher constant - as in xO(1) would have a greater value of x rather than becoming O(n) or O(log n) or anything worse than O(1). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4421] New: Union propagates copy constructors and destructors over all members
http://d.puremagic.com/issues/show_bug.cgi?id=4421
Summary: Union propagates copy constructors and destructors
over all members
Product: D
Version: 2.041
Platform: All
OS/Version: All
Status: NEW
Keywords: accepts-invalid, spec
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: rsi...@gmail.com
--- Comment #0 from Shin Fujishiro rsi...@gmail.com 2010-07-04 02:59:50 PDT
---
Copy constructor and destructor are invoked on every field of a union. It must
be compile error to define a union containing any object which has a
copy-constructor and/or a destructor -- since calling cpctor or dtor on
'non-active members' leads to undefined behavior.
This program compiles:
import std.stdio;
void main()
{
U u, v;
v = u;
}
union U
{
R r;
S s;
}
struct R
{
this(this) { writeln(R : this(this)); }
~this(){ writeln(R : ~this()); }
}
struct S
{
this(this) { writeln(S : this(this)); }
~this(){ writeln(S : ~this()); }
}
And prints this lines:
R : this(this)
S : this(this)
S : ~this()
R : ~this()
S : ~this()
R : ~this()
S : ~this()
R : ~this()
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4422] New: std.c.osx.socket and std.c.linux.socket cause symbol conflict
http://d.puremagic.com/issues/show_bug.cgi?id=4422 Summary: std.c.osx.socket and std.c.linux.socket cause symbol conflict Product: D Version: D2 Platform: Other OS/Version: Mac OS X Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: repeate...@gmail.com --- Comment #0 from Masahiro Nakagawa repeate...@gmail.com 2010-07-04 03:15:29 PDT --- Currently, I am trying to improve std.socket(Source is here http://bitbucket.org/repeatedly/scrap/src/tip/socket.d). In this process, I get the compilation error. test.d(5): Error: core.sys.posix.arpa.inet.INET_ADDRSTRLEN at /path/to/src/druntime/import/core/sys/posix/arpa/inet.di(45) conflicts with core.sys.posix.netinet.in_.INET_ADDRSTRLEN at /path/to/src/druntime/import/core/sys/posix/netinet/in_.di(70) Following code is a part of std.c.osx.socket(std.c.linux.socket too). - private import core.stdc.stdint; public import core.sys.posix.arpa.inet; public import core.sys.posix.netinet.tcp; public import core.sys.posix.netinet.in_; public import core.sys.posix.sys.select; public import core.sys.posix.sys.socket; - core.sys.posix.netinet.in_ already imports core.sys.posix.arpa.inet as public. I think public import core.sys.posix.arpa.inet should be removed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4423] New: enums of struct types
http://d.puremagic.com/issues/show_bug.cgi?id=4423
Summary: enums of struct types
Product: D
Version: D2
Platform: Other
OS/Version: Linux
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: jmdavisp...@gmail.com
--- Comment #0 from Jonathan M Davis jmdavisp...@gmail.com 2010-07-04
03:23:53 PDT ---
I would like to be able to create enums of struct types, but it doesn't seem
possible at the moment. You can create manifest constants of a struct using
enum, but not an enum with an actual list of values. So, if I were to create a
struct that looks like this
struct S
{
this(string phrase, int num)
{
this.phrase = phrase;
this.num = num;
}
int opCmp(const ref S rhs)
{
if(phrase rhs.phrase)
return -1;
else if(phrase rhs.phrase)
return 1;
if(num rhs.num)
return -1;
else if(num rhs.num)
return 1;
return 0;
}
string phrase;
intnum;
}
I could create enums like this
enum a = S(hello, 1);
enum b = S(goodbye, 45);
and the compiler is fine with it. However, if I try and create a bona fide enum
enum E : S {a = S(hello, 1),
b = S(goodbye, 45),
c = S(world, 22)};
the compiler complains like so
t.d(28): Error: variable __ctmp1 cannot be read at compile time
t.d(28): Error: cannot evaluate __ctmp1.this(hello,1) at compile time
t.d(28): Error: cannot evaluate __ctmp1.this(hello,1) at compile time
t.d(29): Error: cannot evaluate __ctmp2.this(goodbye,45) at compile time
t.d(29): Error: cannot evaluate __ctmp2.this(goodbye,45) at compile time
t.d(28): Error: cast(const(S))__ctmp1.this(hello,1) is not an lvalue
t.d(29): Error: cannot evaluate __ctmp2.this(goodbye,45) at compile time
t.d(29): Error: cannot evaluate
__ctmp2.this(goodbye,45).opCmp(cast(const(S))__ctmp1.this(hello,1)) at
compile time
t.d(29): Error: Integer constant expression expected instead of
__ctmp2.this(goodbye,45).opCmp(cast(const(S))__ctmp1.this(hello,1)) 0
t.d(28): Error: cast(const(S))__ctmp1.this(hello,1) is not an lvalue
t.d(29): Error: cannot evaluate __ctmp2.this(goodbye,45) at compile time
t.d(29): Error: cannot evaluate
__ctmp2.this(goodbye,45).opCmp(cast(const(S))__ctmp1.this(hello,1)) at
compile time
t.d(29): Error: Integer constant expression expected instead of
__ctmp2.this(goodbye,45).opCmp(cast(const(S))__ctmp1.this(hello,1)) 0
t.d(30): Error: cannot evaluate __ctmp3.this(world,22) at compile time
t.d(30): Error: cannot evaluate __ctmp3.this(world,22) at compile time
t.d(28): Error: cast(const(S))__ctmp1.this(hello,1) is not an lvalue
t.d(30): Error: cannot evaluate __ctmp3.this(world,22) at compile time
t.d(30): Error: cannot evaluate
__ctmp3.this(world,22).opCmp(cast(const(S))__ctmp1.this(hello,1)) at
compile time
t.d(30): Error: Integer constant expression expected instead of
__ctmp3.this(world,22).opCmp(cast(const(S))__ctmp1.this(hello,1)) 0
t.d(28): Error: cast(const(S))__ctmp1.this(hello,1) is not an lvalue
t.d(30): Error: cannot evaluate __ctmp3.this(world,22) at compile time
t.d(30): Error: cannot evaluate
__ctmp3.this(world,22).opCmp(cast(const(S))__ctmp1.this(hello,1)) at
compile time
t.d(30): Error: Integer constant expression expected instead of
__ctmp3.this(world,22).opCmp(cast(const(S))__ctmp1.this(hello,1)) 0
It doesn't look like the CTFE stuff can handle this for some reason. Granted,
what CTFE can do is a definite work in progress, but I think that the lack of
ability to create an enum of structs is seriously limiting and rather odd given
that you can create a manifest constant of a struct using an enum. So, I'd love
it if it were possible to create actual enums of a struct type.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4420] insertBack() for SList
http://d.puremagic.com/issues/show_bug.cgi?id=4420 Simen Kjaeraas simen.kja...@gmail.com changed: What|Removed |Added CC||simen.kja...@gmail.com --- Comment #3 from Simen Kjaeraas simen.kja...@gmail.com 2010-07-04 03:24:31 PDT --- (In reply to comment #2) And if it keeps track of the next-to-last node as well, then it can implement popBack() in O(1) as well. How could it? It could popBack once, then you'd need to recalculate next-to-last. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4420] insertBack() for SList
http://d.puremagic.com/issues/show_bug.cgi?id=4420 --- Comment #4 from Jonathan M Davis jmdavisp...@gmail.com 2010-07-04 03:38:29 PDT --- Ah. Good point. I obviously didn't think that one through thoroughly enough. You could popBack() once, but that would be it. Scratch that idea. However, you could still have insertBack() and back() if you kept track of the last element. back() would return that last element and insertBack() would insert after it, adjusting the last element's pointer to its next element to point to the new last element and adjusting the container's pointer to the last element to point to the new last element. So, that should work in O(1), but no popBack() wouldn't work. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4424] New: Copy constructor and templated opAssign cannot coexist
http://d.puremagic.com/issues/show_bug.cgi?id=4424
Summary: Copy constructor and templated opAssign cannot coexist
Product: D
Version: 2.041
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: rsi...@gmail.com
--- Comment #0 from Shin Fujishiro rsi...@gmail.com 2010-07-04 04:25:29 PDT
---
Templated opAssign cannot be declared in a struct with copy constructor.
test.d
struct S
{
this(this) {}
void opAssign(T)(T rhs) if (! is(T == S))
{}
}
% dmd -o- -c test
test.d: Error: function test.S.opAssign conflicts with template
test.S.opAssign(T) if (!is(T == S)) at test.d(4)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3463] Integrate Precise Heap Scanning Into the GC
http://d.puremagic.com/issues/show_bug.cgi?id=3463 --- Comment #25 from Leandro Lucarella llu...@gmail.com 2010-07-04 08:05:15 PDT --- (In reply to comment #23) I just voted for it. It would be great if you could define some benchmarks by which you assess the improvements your approach is bringing. I will try to do a couple of benchmarks when I have the time, but I think the DMD-part of the patch should be merged, even if the current GC is slower with the precise scanning, because having info on the pointers locations open a lot of new possibilities GC-wise, like moving collectors. This can be explored in the feature, once the compiler provide the necessary information about types to the GC. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4425] New: More bells whistles for bitfields
http://d.puremagic.com/issues/show_bug.cgi?id=4425 Summary: More bells whistles for bitfields Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: bearophile_h...@eml.cc --- Comment #0 from bearophile_h...@eml.cc 2010-07-04 12:39:29 PDT --- When bit fields are used to define bit protocols etc., they sometimes have constant fields, or already initialized variable fields. So It can be positive for std.bitmanip.bitfields to support that too, this is an example: field1 : 1; field2 : 2 = 0b01; immutable field3 : 3; immutable field4 : 4 = 0b1110; As with normal immutable fields in structs, the language has to forbid the write on immutable fields. Probably in many cases the compiler can't enforce this at compile time on bit fields (because of the type system granularity; something similar happens with pointers to single bits in bit-arrays), so probably the bit field immutability needs to be enforced at run-time (maybe even in release mode too, because it's a hard constraint). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4420] insertBack() for SList
http://d.puremagic.com/issues/show_bug.cgi?id=4420 Andrei Alexandrescu and...@metalanguage.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #5 from Andrei Alexandrescu and...@metalanguage.com 2010-07-04 12:42:42 PDT --- The main selling point of SList is simplicity. Adding all sorts of storage aides is possible but would work against SList's charter. Feel free to propose a new type based on SList in an enhancement proposal. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4426] New: assert(condition, string) fails in std.array.back
http://d.puremagic.com/issues/show_bug.cgi?id=4426 Summary: assert(condition, string) fails in std.array.back Product: D Version: D2 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: and...@metalanguage.com --- Comment #0 from Andrei Alexandrescu and...@metalanguage.com 2010-07-04 13:57:23 PDT --- This test inside std.array.back causes a segfault: assert(a.length, Attempting to fetch the back of an empty array); This doesn't: assert(a.length); The bug seems to manifest itself only on Linux and only in release mode. To reproduce, build Phobos on Linux like this: make -f linux.mak unittest BUILD=release DMDEXTRAFLAGS=-version=bug where is the number of this bug report. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4424] Copy constructor and templated opAssign cannot coexist
http://d.puremagic.com/issues/show_bug.cgi?id=4424 Andrei Alexandrescu and...@metalanguage.com changed: What|Removed |Added CC||and...@metalanguage.com --- Comment #1 from Andrei Alexandrescu and...@metalanguage.com 2010-07-04 15:19:12 PDT --- That's an important issue. I just committed a fix to Tuple that replaces opAssign with assign, but that should only be considered a workaround. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4420] insertBack() for SList
http://d.puremagic.com/issues/show_bug.cgi?id=4420 --- Comment #6 from Jonathan M Davis jmdavisp...@gmail.com 2010-07-04 16:44:47 PDT --- Well, like I said, the addition might not be worthwhile. It would complicate some of the other functions somewhat. It's just that it would be a fairly simple addition to get some extra functionality in comparison to say, a doubly-linked list. I have no problem if you don't think that it's appropriate to add that extra functionality to SList. I just thought that I'd point it out in case such a change would be desirable and the idea hadn't occurred to you. Personally, in my code, I'd generally just as soon use a doubly-linked list in most cases if I'm going to use a list. But SList as-is definitely has its uses, and a doubly-linked list is overkill for some situations. It probably isn't worth creating a separate SList class with just the additions to support back() and insertBack() though. In any case, this was just a suggestion, and if you don't want to use it, that's fine by me. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
