Walter Bright wrote:
Nick Sabalausky wrote:
To put it simply, I agree with this even on mere principle. I'm
convinced that the current D behavior is a blatant violation of
strong-typing and smacks way too much of C's so-called type system.
You're certainly not the first to feel this way
Don wrote:
In D some people have proposed to change the semantics of the is
operator, to make it more useful and tidy, so if you want to know if x
is a NaN you can then write if(x is nan).
That won't work in this case, unless you make nan a keyword. There are
2^^62 different NaNs, so a bitwise
Steven Schveighoffer wrote:
A while back, you identified one of the best interfaces for input ranges:
E* getNext();
Which allows for null returns when no data is left. The drawback is
that E must be either referenced or allocated on the heap (providing
storage to the function is an option).
Robert Clipsham wrote:
On 19/03/10 00:34, Bernard Helyer wrote:
http://omploader.org/iM3ZudA
There you go. D2, run build.debug.sh to build. Modify the script to add
options and the like. Built with `-gc` list _Dmain or break _Dmain
doesn't work, if you force a segfault (remove the comments
bearophile wrote:
Andrew Marlow:
Well, thanks for that, at least I know now. But I am a bit peeved. What is the
point in calling something 'std' if it is not standard. I am used to 'std'
meaning 'it comes with the compiler environment'.
Please, ask questions like those ones on the learn
Walter Bright wrote:
Currently, given an array:
alias T[3] A;
A a;
the default initializer for A, A.init, is T.init. It is done this way
for memory efficiency, as:
a = A.init;
doesn't need to create an array for the rvalue. But it does cause
generic programming problems,
Robert Clipsham wrote:
On 12/03/10 16:34, Vladimir Panteleev wrote:
Hi all,
I'm trying to debug some random crashes of some D services running on a
Linux headless server.
I have compiled/linked my programs and Phobos with -g and without -O
(using DMD), and applied the gdb patches from
Steven Schveighoffer wrote:
If a good debugger existed for dmd, you could determine the location,
but I don't know of any good ones. gdb doesn't do a very good job with D.
dmd has produced debugging information that makes gdb choke up for ages.
This makes gdb (and some other utilities that
Walter Bright wrote:
The fact is, people *do* have major problems with concurrent
programming. Sharing of mutable state is a large generator of these
problems, and I don't think we can wish it away or blame the programmer.
I didn't advocate sharing of mutable state.
Ellery Newcomer wrote:
I hate the restriction on modules with static constructors and cyclic
dependencies. IMO it's the most patronizing 'feature' D has. A year or
so ago I ran into this issue during my first (and last) big project in
D. Just last week I started working on it again and
Andrei Alexandrescu wrote:
On 03/10/2010 05:01 PM, grauzone wrote:
Andrei Alexandrescu wrote:
There's one final nail in the coffin. In wake of concurrency, de jure
immutability becomes a necessity, not a useful and desirable de facto
convention. Adopting the window dressing but not the essence
Andrei Alexandrescu wrote:
The kick-off meeting for Thunderbird 3:
Thunderbird 2 is quite sluggish, has poor asynchronous execution of
tasks, poor focus control, and annoying modal dialogs on error. What do
we do for version 3?
...
The main reason why I went back to Thunderbird 2 is that
Andrei Alexandrescu wrote:
On 03/10/2010 06:06 PM, grauzone wrote:
Andrei Alexandrescu wrote:
On 03/10/2010 05:01 PM, grauzone wrote:
Andrei Alexandrescu wrote:
There's one final nail in the coffin. In wake of concurrency, de jure
immutability becomes a necessity, not a useful and desirable
Andrei Alexandrescu wrote:
On 03/10/2010 06:47 PM, grauzone wrote:
Andrei Alexandrescu wrote:
On 03/10/2010 06:06 PM, grauzone wrote:
Andrei Alexandrescu wrote:
On 03/10/2010 05:01 PM, grauzone wrote:
Andrei Alexandrescu wrote:
There's one final nail in the coffin. In wake of concurrency
Andrei Alexandrescu wrote:
On 03/10/2010 07:07 PM, grauzone wrote:
Andrei Alexandrescu wrote:
On 03/10/2010 06:47 PM, grauzone wrote:
Andrei Alexandrescu wrote:
On 03/10/2010 06:06 PM, grauzone wrote:
Andrei Alexandrescu wrote:
On 03/10/2010 05:01 PM, grauzone wrote:
Andrei Alexandrescu
Walter Bright wrote:
grauzone wrote:
Data this small you would simply copy. Because it's so small, copying
won't have negative performance impact. The OS approach can be used
for large data (at least in the order of hundreds of KB) and immutable
parts of the data segment.
You'd also have
Robert Jacques wrote:
On Mon, 08 Mar 2010 16:42:54 -0500, Philippe Sigaud
philippe.sig...@gmail.com wrote:
On Mon, Mar 8, 2010 at 14:22, Steven Schveighoffer
schvei...@yahoo.comwrote:
The shrinkToFit name is not my favorite, anyone care to submit a better
name? minimize is out because it
Walter Bright wrote:
Trass3r wrote:
obj2asm tells the tale. (obj2asm is an incredibly useful tool, I
don't know why nobody uses it.)
Maybe because it's not free (and not much advertised). obconv also
supports disassembling various object file formats + conversion
between them and it's open
Trass3r wrote:
The linux version comes in the zip right along side dmd.
Indeed. Even the OSX folder contains obj2asm. The windows version is missing.
The best thing is, on Linux you can use binutils objdump just fine. I'm
sure OSX has tools to inspect object files as well. Only on Windows,
Walter Bright wrote:
bearophile wrote:
Walter Bright:
There are significant technical problems with having functions return
tuples.
A possibly stupid question: isn't it enough to return a custom struct?
No, because of the alignment mismatches with other uses of tuples.
I don't
Lutger wrote:
Michael Rynn wrote:
That IS what Walter thinks, actually. It's being moved to libraries
(which is why there have been some nasty AA regressions in the past few
compiler releases :-( ).
Sounds good. So the source is in druntime?
Does that mean I can find out how to implement
Walter Bright wrote:
grauzone wrote:
Walter Bright wrote:
bearophile wrote:
Walter Bright:
There are significant technical problems with having functions
return tuples.
A possibly stupid question: isn't it enough to return a custom struct?
No, because of the alignment mismatches
bearophile wrote:
grauzone:
That aside, I'm also glad that you acknowledge that current tuples are
not perfect and need improvement.
I agree.
It's probably already too late to fix them,
It isn't.
D2 is pretty much finalized now. The discussion (i.e. bikeshedding)
alone to determine
Walter Bright wrote:
grauzone wrote:
Again, I can't understand. Does the compiler rely that tuples have the
same byte layout as structs or function arguments? I thought the
compiler could just copy all fields. And the backend can already
return multiple values, since it can return structs
Steven Schveighoffer wrote:
On Thu, 04 Mar 2010 04:02:46 -0500, KF kfles...@gmail.com wrote:
I hope this is the right place to post it.
In my work, I often need to add elements at the end of dynamic arrays
and remove them from the end. This incremental changes would most
conveniently be
Steven Schveighoffer wrote:
On Thu, 04 Mar 2010 11:43:27 -0500, grauzone n...@example.net wrote:
Some sort of resetAndReuse function to clear an array, but enabling
to reuse the old memory would be nice:
int[] a = data;
a = null;
a ~= 1; //reallocates (of course)
a.length = 0;
a ~= 1
Steven Schveighoffer wrote:
On Thu, 04 Mar 2010 12:43:32 -0500, grauzone n...@example.net wrote:
Steven Schveighoffer wrote:
On Thu, 04 Mar 2010 11:43:27 -0500, grauzone n...@example.net wrote:
Some sort of resetAndReuse function to clear an array, but
enabling to reuse the old memory would
Walter Bright wrote:
bearophile wrote:
Walter Bright:
Yeah, I wrote a C++ compiler back in 1987. It compiled itself, too!
The hard work of implementing C++ correctly was just beginning,
though.
C'mon Walter, give them some credit, wish them some luck, I think
they will be able to compile a
Don wrote:
We'll need compile-time reflection for all attributes. This can lead us
to a rationale for which attributes are keywords, and which are
@attributes.
Apparently, this attribute syntax makes no sense at all. I suggest we
simply remove it and use normal keywords instead.
bearophile wrote:
grauzone:
Apparently, this attribute syntax makes no sense at all. I suggest we
simply remove it and use normal keywords instead.
Currently D2 attributes are not necessary, they can be replaced by keywords,
but keywords don't scale if you want to define many new attribute
BCS wrote:
I need a function that works like the following:
T* New(T)() { return new T; }
But that also works with static arrays:
auto i = New!(int)();
auto a = New!(int[27])();
The cleanest solution I can think of is:
T* New(T)() { return (new T[1]).ptr; }
but that seems ugly. Any
Ellery Newcomer wrote:
On 02/24/2010 12:37 PM, Robert Clipsham wrote:
On 24/02/10 17:51, Ellery Newcomer wrote:
import tango.core.tools.TraceExceptions;
If you want to use gdb then type 'b _d_throw_exception' (or 'b
_d_throw'
for dmd) before you run your app. This will break on
Steven Schveighoffer wrote:
On Mon, 22 Feb 2010 09:27:57 -0500, strtr st...@spam.com wrote:
Thanks, I understand.
But, how about a runtime error?
Isn't a literal placed in easy to identify should-only-read memory?
A segfault is a runtime error. The problem with Windows is it doesn't
throw
Steven Schveighoffer wrote:
On Thu, 18 Feb 2010 20:47:16 -0500, Denis Koroskin 2kor...@gmail.com
wrote:
On Fri, 19 Feb 2010 00:46:05 +0300, Steven Schveighoffer
schvei...@yahoo.com wrote:
That would be bad, T[] is implicitly casted from T[N]. Consider
that you could easily escape stack
IMHO array literals should be static arrays, which are value types. No
issues with heap allocation or immutability requirements.
Also, even immutable values can change at runtime:
void foo(immutable int x) {
auto array = [x];
}
array would have needed to be heap allocated even if they
Don wrote:
grauzone wrote:
IMHO array literals should be static arrays, which are value types. No
issues with heap allocation or immutability requirements.
That still wouldn't solve the performance problems.
You mean even for a static array on the stack, the time to construct it
would
Nick Sabalausky wrote:
grauzone n...@example.net wrote in message
news:hlbg22$6f...@digitalmars.com...
Nick Sabalausky wrote:
BCS n...@anon.com wrote in message
news:a6268ff103d38cc7ba48d6fa...@news.digitalmars.com...
Hello Nick,
I *definitely* want that for string mixins of both
retard wrote:
Granted, even if logging is disabled, the compiler will push the
arguments on the stack and call logInfo().
This is a case where a JIT compiler wins. The code runs equally fast
without the call at all and with logging turned off (dynamically). In
languages like D, the like has
retard wrote:
Tue, 16 Feb 2010 21:11:32 +0100, grauzone wrote:
retard wrote:
Granted, even if logging is disabled, the compiler will push the
arguments on the stack and call logInfo().
This is a case where a JIT compiler wins. The code runs equally fast
without the call at all
Nick Sabalausky wrote:
BCS n...@anon.com wrote in message
news:a6268ff103d38cc7ba48d6fa...@news.digitalmars.com...
Hello Nick,
I *definitely* want that for string mixins of both the
template-generated and ctfe-generated varieties.
Why? I don't see any reason aside from documentation to do
dsimcha wrote:
2. Pointer offset information for each type is determined at compile time using
template metaprogramming.
Why don't you just ask Walter to make dmd generate the necessary
information?
Steven Schveighoffer wrote:
On Sun, 14 Feb 2010 18:28:38 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Denis Koroskin wrote:
On Mon, 15 Feb 2010 00:31:29 +0300, Walter Bright
newshou...@digitalmars.com wrote:
Right now, mixins are defined and used as:
template foo(T)
bearophile wrote:
I have shown this little program to some of my friends that program in Java/C#:
class Foo {
private int x;
}
void main() {
Foo f = new Foo;
f.x = 5;
}
When I say them this code compiles with D2 they usually tell me that the
compiler has a bug.
So I suggest
Lars T. Kyllingstad wrote:
Andrei Alexandrescu wrote:
Gone, that is. Walter agreed to remove it.
To achieve the functionality of
foreach_reverse (r) { ... }
use
foreach (retro(r)) { ... }
using retro in std.range.
Now all what's left to do is to make it as efficient as the builtin
Don wrote:
Trass3r wrote:
Why isn't == used to compare the struct members in the code above? I
mean, if I compare the structs with == it could also use == to
compare the members. If I use is to compare the structs it could
use is to compare them members.
Structs are compared *bitwise*!
Andrei Alexandrescu wrote:
Traits indeed offer more than interfaces. We're looking at sensible
things to do within the time constraints we're having; traits would be a
major effort, whereas methods in interfaces are just eliminating an
artificial limitation. Traits are a possible addition to
BLS wrote:
On 30/01/2010 08:13, Walter Bright wrote:
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.056.zip
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.040.zip
Thanks to the many people who contributed to this update!
Walter Bright wrote:
retard wrote:
I can easily come up with 100 other such features.
Please do so, and submit them to bugzilla.
You know, the problem with Bugzilla is, that most entries simply remain
unreplied. Especially when they inquire about strange language features
or dark corner
Andrei Alexandrescu wrote:
Rainer Deyke wrote:
Don wrote:
I suspect that string, wstring should have been the primary types and
had a .codepoints property, which returned a ubyte[] resp. ushort[]
reference to the data. It's too late, of course. The extra value you get
by having a specific type
Andrei Alexandrescu wrote:
What can be done about that? I see a number of solutions:
(a) Do not operate the change at all.
(b) Operate the change and mention that in range algorithms you should
check hasLength and only then use length under the assumption that it
really means elements count.
Andrei Alexandrescu wrote:
Steve Teale wrote:
Walter Bright Wrote:
Steve Teale wrote:
Are we still just talking just AMD 64 here? Last time I tried to
install the .deb package, the system told m that my Intel core2 64
bit machine was the wrong architecture.
Yes, I have an AMD64. How that
Don wrote:
grauzone wrote:
Jason House wrote:
Andrei's finishing his last TDPL chapter, Sean is updating
std.thread(?), and Walter's been fixing forward reference and CTFE
bugs. What's left?
Documentation. The Phobos docs are rather bad, and don't even include
the core modules. Also
Andrei Alexandrescu wrote:
grauzone wrote:
Adam D. Ruppe wrote:
On Sat, Jan 23, 2010 at 12:00:04PM -0500, Steve Teale wrote:
I see that Go has now usurped D's former place at #13 in Tiobe -
which I realize of course does not mean anything. But I'd be
interested to hear what the D aficionados
Eldar Insafutdinov wrote:
grauzone Wrote:
Eldar Insafutdinov wrote:
Andrei Alexandrescu Wrote:
Eldar Insafutdinov wrote:
Jesse Phillips Wrote:
Jason House wrote:
Andrei's finishing his last TDPL chapter, Sean is updating std.thread(?), and Walter's been fixing forward reference and CTFE
Jason House wrote:
Andrei's finishing his last TDPL chapter, Sean is updating std.thread(?), and Walter's been fixing forward reference and CTFE bugs. What's left?
Documentation. The Phobos docs are rather bad, and don't even include
the core modules. Also there's std.thread, shouldn't it be
Simen kjaeraas wrote:
On Sun, 24 Jan 2010 15:12:47 +0100, grauzone n...@example.net wrote:
Eldar Insafutdinov wrote:
grauzone Wrote:
Eldar Insafutdinov wrote:
Andrei Alexandrescu Wrote:
Eldar Insafutdinov wrote:
Jesse Phillips Wrote:
Jason House wrote:
Andrei's finishing his last
Nick Sabalausky wrote:
Nick Sabalausky a...@a.a wrote in message
news:hjff0j$27i...@digitalmars.com...
- Does nothing to change my opinion that Google has done nothing
noteworthy outside of search engines and maybe their ad service.
And their maps, of course. But then again, how google, of
Adam D. Ruppe wrote:
On Sat, Jan 23, 2010 at 12:00:04PM -0500, Steve Teale wrote:
I see that Go has now usurped D's former place at #13 in Tiobe - which I
realize of course does not mean anything. But I'd be interested to hear what
the D aficionados think of Go.
There's been a couple
Steven Schveighoffer wrote:
On Wed, 13 Jan 2010 06:28:33 -0500, Jacob Carlborg d...@me.com wrote:
On 1/12/10 23:40, Walter Bright wrote:
It's true that nobody has spent the effort to do this. Anyone is welcome
to step up and work on it.
Hasn't that already been solved with ddl:
Brad Roberts wrote:
On 1/11/2010 11:20 PM, grauzone wrote:
g wrote:
Hi
Is there a way to demangle .mangleof strings at CTFE
or at least know the fully qualified name of a class or template
instance.
If you have to use such dirty tricks, you probably should consider to
turn back NOW for your
Andrei Alexandrescu wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
The idea is that the API offers a means to define and use temporary
buffers without compromising memory safety. Even if you escape data
allocated via getBuffer that persists after releaseBuffer, that will
not cause
Andrei Alexandrescu wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
The idea is that the API offers a means to define and use temporary
buffers without compromising memory safety. Even if you escape data
allocated via getBuffer that persists
Andrei Alexandrescu wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
The idea is that the API offers a means to define and use
temporary buffers without compromising memory safety. Even if you
escape
Sean Kelly wrote:
Don Wrote:
I once had a customer make a request for a very small DOS utility
program, and specifically said that they didn't have much disk space
left on their computer, could I please make sure the executable wasn't
too big?
I wrote it in asm. It was 15 bytes. g
Hah.
bearophile wrote:
void bar(int n) {
scope int[] a = new int[n]; // stack-allocated
foo(a);
}
Why are you making such proposals, when one of the core developers even
thought about removing normal scope? It's almost 100% guaranteed that
nobody will listen.
I personally find it a good
Walter Bright wrote:
If you want to know where the size in your exe file is coming from, the
map file will tell you - broken down by each name and its associated size.
Can you tell me how many bytes all TypeInfos use up in libphobos?
(Without disabling codegen for TypeInfos and comparing the
Andrei Alexandrescu wrote:
grauzone wrote:
bearophile wrote:
void bar(int n) {
scope int[] a = new int[n]; // stack-allocated
foo(a);
}
Why are you making such proposals, when one of the core developers
even thought about removing normal scope? It's almost 100%
guaranteed that nobody
Andrei Alexandrescu wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
grauzone wrote:
bearophile wrote:
void bar(int n) {
scope int[] a = new int[n]; // stack-allocated
foo(a);
}
Why are you making such proposals, when one of the core developers
even thought about removing normal
bearophile wrote:
grauzone:
Why are you making such proposals, when one of the core developers even
thought about removing normal scope?
And by the way, in the Python community one of the purposes of PEPs is to act
as an archive of refused proposals, so people can avoid wasting brain energy
Andrei Alexandrescu wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
grauzone wrote:
bearophile wrote:
void bar(int n) {
scope int[] a = new int[n]; // stack-allocated
foo(a);
}
Why are you making such proposals, when one of the core
g wrote:
Hi
Is there a way to demangle .mangleof strings at CTFE
or at least know the fully qualified name of a class or template instance.
If you have to use such dirty tricks, you probably should consider to
turn back NOW for your own good. D always lures you into doing tricky
template and
bearophile wrote:
dsimcha:
Struct constructors are D2 only. That said, you can fake them in D1 by
overloading static opCall:
Struct constructors are probably the D2 feature I miss more in D1 :-)
Why?
Bye,
bearophile
Andrei Alexandrescu wrote:
The idea is that the API offers a means to define and use temporary
buffers without compromising memory safety. Even if you escape data
allocated via getBuffer that persists after releaseBuffer, that will not
cause undefined behavior. (It may, however, cause data to
Walter Bright wrote:
grauzone wrote:
Walter Bright wrote:
grauzone wrote:
(The final executable is almost twice the size as the D2 one too,
although it's questionable how much of the additional size is due to
templates.)
Finding out why an executable is large is as easy as compiling
Nick Sabalausky wrote:
I'd rather use an app that did a bunch of compile-time reflection than one
that did a bunch of run-time reflection. And I think that 50..100 MB figure
The question is: what will cause more overhead? Compile time or runtime
reflection? For some use cases, you'll have
Nick Sabalausky wrote:
Ph roma...@gmail.com wrote in message
news:hia7qc$b5...@digitalmars.com...
Why a generated file is so huge?
Empty program such as:
int main(char[][] args)
{
return 0;
}
compiled with dmd2 into file with size of 266268 bytes.
Even after UPX, it's size is 87552 bytes.
Walter Bright wrote:
grauzone wrote:
(The final executable is almost twice the size as the D2 one too,
although it's questionable how much of the additional size is due to
templates.)
Finding out why an executable is large is as easy as compiling with
-L/map on Windows and -L-map -Lfoo.map
Walter Bright wrote:
Walter Bright wrote:
grauzone wrote:
Why are you creating these as mailing lists and not as
news.digitalmars.com groups?
Because I expect it to be very low traffic, and I wouldn't expect
people to constantly have to check the n.g. to see if the beta is
available
Walter Bright wrote:
grauzone wrote:
Walter Bright wrote:
retard wrote:
Fri, 01 Jan 2010 12:19:25 -0800, Walter Bright wrote:
When I then picked up K+R C, I never wrote another line of Pascal.
It so
soured me on Pascal that I never got on the later bandwagons of Modula
II, Delphi
Walter Bright wrote:
retard wrote:
Fri, 01 Jan 2010 12:19:25 -0800, Walter Bright wrote:
When I then picked up K+R C, I never wrote another line of Pascal. It so
soured me on Pascal that I never got on the later bandwagons of Modula
II, Delphi, TurboPascal, etc. Never even looked at them.
Trass3r wrote:
grauzone schrieb:
Second, the bug: casting arrays at compiletime seems to behave
differently from casting at runtime. Casting at compiletime doesn't
reinterpret cast, it does conversion! Demonstration here:
http://codepad.org/OGjXADdu
Feel free to file some bug reports
Walter Bright wrote:
Happy New Year!
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.054.zip
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.038.zip
Many thanks to the numerous people who contributed to this update.
Tons of
bearophile wrote:
grauzone:
But I have a problem: the compiler is either extremely slow for me, or
is stuck in an endless loop. All it does is to slowly allocate memory. I
aborted the compilation after ~ 20 minutes and 2 GB RAM allocation. This
wasn't the case with dmd 1.053, where it only
justme wrote:
grauzone Wrote:
bearophile wrote:
BCS:
A though on the comma operator: if the comma operator were
defined to give a tuple type and be implicitly castable to any
suffix of it's self, then you could get both the comma
expression usage that Walter wants as well as all the fun
Andrei Alexandrescu wrote:
bearophile wrote:
I don't know C++ much, and I have to confess that I have to fully
understand the const business still. I hope your book will teach me
this topic very well :-)
One thing about const that is slowly downing on this community is that
it will _not_ be
The Anh Tran wrote:
This is just a small D exercise. I port c++ knucleotide from
shootout.alioth.debian.org
Issue 1:
If i manually listing hashtable contents, the key does exist in that ht.
But (key in hash_table) always yield null.
Worse, if i use: auto val = ht[key], an exception is thrown.
justme wrote:
bearophile Wrote:
C# will probably not follow the route of stagnation of Java for some more time,
thanks to Mono too. I don't like that string interpolation syntax because it
looks unsafe, and that design of tuples can be improved, but they are listening
to programmes (even if
revcompgeek wrote:
So I tried building Tango trunk a while ago, and it actually built
surprisingly well, with only one small error I was able to fix. So I
installed the tango library and proceeded to test if tango was really
working. So in hello.d:
import tango.io.Stdout;
void main(){
justme wrote:
grauzone Wrote:
justme wrote:
bearophile Wrote:
C# will probably not follow the route of stagnation of Java for some more time,
thanks to Mono too. I don't like that string interpolation syntax because it
looks unsafe, and that design of tuples can be improved
BCS wrote:
Hello justme,
bearophile Wrote:
C# will probably not follow the route of stagnation of Java for some
more time, thanks to Mono too. I don't like that string interpolation
syntax because it looks unsafe, and that design of tuples can be
improved, but they are listening to
bearophile wrote:
BCS:
A though on the comma operator: if the comma operator were defined to give
a tuple type and be implicitly castable to any suffix of it's self, then
you could get both the comma expression usage that Walter wants as well as
all the fun things that tuple expressions give.
Trass3r wrote:
I got some RGB palette in a byte array which I'd like to convert or
map to an RGB struct array, isn't this easily possible without using
dozens of struct constructors?
RGB[256] PALETTE = cast(RGB[256]) [
0x00, 0x00, 0x00, 0xE3, 0x53, 0x00,
0xCF, 0x4B, 0x07, 0xBF, 0x43,
teo wrote:
There was a way to define new types within templates and I think that I
have seen that demonstrated here in the newsgroups, but cannot find it
now. Can someone help me please?
I would like to do something like this:
template MyTemplate(T)
{
struct T ~ Struct // define FooStruct
Walter Bright wrote:
grauzone wrote:
What will you do?
Because of casting, there cannot be a thread-local only gc.
I think this is a very bad idea. I thought TLS by default was just the
beginning of separating threads better. While it will work in the
initial stages of D2, I don't think
Steven Schveighoffer wrote:
Also, if you use GC.malloc directly, and the user tries to append to
slices to it, your code may break. GC.malloc doesn't seem to pad the
memory block with a length field.
Yes, this is a possible problem. However, using GC.malloc directly and
then treating the
Walter Bright wrote:
grauzone wrote:
Also, it's bad how inter-thread communication will trigger GC runs,
No, it won't. Allocation may trigger a GC run.
which will stop all threads in the process for a while. Because you
have no choice but to allocate your immutable messages from the shared
Walter Bright wrote:
grauzone wrote:
It matters because Java is used a lot in multithreaded applications,
and it is gc based. The gc is not a disastrous problem with it.
For one, Java has an infinitely better GC implementation than D. Yeah,
this isn't a problem with the concept
Steven Schveighoffer wrote:
grauzone Wrote:
Steven Schveighoffer wrote:
The problem is that adding a capacity field only works if the object is a
reference type. A value type will make either choose to make copies of the
capacity field, resulting in the same stomping problem (and maybe
Walter Bright wrote:
But you need to allocate this data from a shared garbage collection,
You do anyway.
Consider you allocate normal data from a thread local heap, and shared
data from a shared GC. We will need this anyway to get decent memory
allocation and GC performance. Especially
Steven Schveighoffer wrote:
I see no problem with adding an additional field to usual slices.
There's also some benefit: clearer semantics (if you make guaranteed
performance part of the semantics) and a much simpler runtime.
Simpler runtime is not any benefit IMO. Nobody cares how array
1 - 100 of 542 matches
Mail list logo
