Hi guys,
I've been following the forums for a while. I'm interested in
looking into D, but I understand that currently it changes often,
and is not very reliable.
I've also read that there's a new release model planned, where a
stable version of the language is released every year or two. Is
On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote:
Hi guys,
I've been following the forums for a while. I'm interested in
looking into D, but I understand that currently it changes
often, and is not very reliable.
I've also read that there's a new release model planned, where
a stable v
On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote:
What's holding you from releasing a version now and declaring
it stable for e.g. a year?
What would be the benefit of just declaring one release stable?
This is not a trick question.
David
On Monday, 22 April 2013 at 14:25:21 UTC, David Nadlinger wrote:
On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote:
What's holding you from releasing a version now and declaring
it stable for e.g. a year?
What would be the benefit of just declaring one release stable?
This is not a tric
I started a project a month ago, and for the moment my feeling is
just: D can already be used as it. It's not "finished" but the
state is stable enough I think.
The compiler is not perfect (not always really explicit messages,
not able to compile for all architecture like ARM,...), but a lot
On Monday, 22 April 2013 at 23:35:56 UTC, Flamaros wrote:
The problem is not that D is usable or not as it is. The problem
is that, until officially "handled to the user", it won't be
taken too serious by the industry.
In other words, you won't find jobs as a D programmer.
C++ will improve m
On Tuesday, 23 April 2013 at 01:06:49 UTC, eles wrote:
On Monday, 22 April 2013 at 23:35:56 UTC, Flamaros wrote:
The problem is not that D is usable or not as it is. The
problem is that, until officially "handled to the user", it
won't be taken too serious by the industry.
In other words, yo
On Monday, 22 April 2013 at 23:35:56 UTC, Flamaros wrote:
I started a project a month ago, and for the moment my feeling
is just:
D can already be used as it.
Input:
import std.stdio;
struct S { string a; }
pragma(msg, S("x") == S("x".idup));
void main
On Tuesday, 23 April 2013 at 03:46:30 UTC, Mehrdad wrote:
...
Nope, still broken.
The behavior isn't too surprising to me. Your code is buggy.
Defining opEquals gets you the behavior you might want:
import std.stdio, std.algorithm;
struct S {
string a;
bool opEquals(S rhs) { return
On Tuesday, 23 April 2013 at 04:26:59 UTC, Chris Cain wrote:
On Tuesday, 23 April 2013 at 03:46:30 UTC, Mehrdad wrote:
...
Nope, still broken.
The behavior isn't too surprising to me. Your code is buggy.
?!??!
On Tuesday, 23 April 2013 at 04:27:45 UTC, Mehrdad wrote:
?!??!
I'm confused by why you might be confused by this. opEquals by
default is simply a bit-level value check.
"x" and "x".idup are two different things.
"x" might be:
ptr = 0xDEADBEEF
length = 1
and "x".idup might be:
ptr =
On Tuesday, 23 April 2013 at 04:33:24 UTC, Chris Cain wrote:
On Tuesday, 23 April 2013 at 04:27:45 UTC, Mehrdad wrote:
?!??!
I'm confused by why you might be confused by this. opEquals by
default is simply a bit-level value check.
Yeah, hence it's broken.
On Tuesday, 23 April 2013 at 04:33:24 UTC, Chris Cain wrote:
On Tuesday, 23 April 2013 at 04:27:45 UTC, Mehrdad wrote:
?!??!
opEquals by default is simply a bit-level value check.
In fact, it's _doubly_ broken...
import std.stdio;
struct S { float d; }
void main()
On Tuesday, 23 April 2013 at 04:33:50 UTC, Mehrdad wrote:
Yeah, hence it's broken.
Um... I don't see the problem. Do you expect the compiler to
treat strings/arrays special and look up the equal method in the
standard library? Wouldn't that confuse you when it doesn't apply
to your structure
2013/4/23 Mehrdad
> On Monday, 22 April 2013 at 23:35:56 UTC, Flamaros wrote:
>
>> I started a project a month ago, and for the moment my feeling is just:
>> D can already be used as it.
>>
>
> Input:
> import std.stdio;
> struct S { string a; }
> pragma(msg, S("
On Tuesday, 23 April 2013 at 04:37:12 UTC, Chris Cain wrote:
On Tuesday, 23 April 2013 at 04:33:50 UTC, Mehrdad wrote:
Yeah, hence it's broken.
Um... I don't see the problem. Do you expect the compiler to
treat strings/arrays special and look up the equal method in
the standard library? Woul
On Tuesday, 23 April 2013 at 04:44:52 UTC, kenji hara wrote:
2013/4/23 Mehrdad
On Monday, 22 April 2013 at 23:35:56 UTC, Flamaros wrote:
I started a project a month ago, and for the moment my
feeling is just:
D can already be used as it.
Input:
import std.stdio;
struct S
On Tuesday, 23 April 2013 at 04:43:04 UTC, Mehrdad wrote:
It has nothing to do with the standard library.
It should do whatever operator == does.
Sounds slow. We really need a way for you to choose to have it
your way and the way it is now.
Oh, there's opEquals. Now we can both be happy. :)
In floating point value comparison, +0.0 is equal to -0.0.
auto x = +0.0;
auto y = -0.0;
assert(x == y);
Kenji Hara
2013/4/23 Mehrdad
> On Tuesday, 23 April 2013 at 04:33:24 UTC, Chris Cain wrote:
>
>> On Tuesday, 23 April 2013 at 04:27:45 UTC, Mehrdad wrote:
>>
>>> ?!??!
>>>
>>
>
2013/4/23 Mehrdad
> On Tuesday, 23 April 2013 at 04:44:52 UTC, kenji hara wrote:
>
>>
>> This is mostly expected behavior. During compilation value identities are
>> not guaranteed.
>> Because compile time evaluation is always done after constant folding, and
>> constant folding would fold "x".id
On Tuesday, 23 April 2013 at 04:48:05 UTC, Chris Cain wrote:
On Tuesday, 23 April 2013 at 04:43:04 UTC, Mehrdad wrote:
It has nothing to do with the standard library.
It should do whatever operator == does.
Sounds slow. We really need a way for you to choose to have it
your way and the way it
On Tuesday, 23 April 2013 at 04:56:13 UTC, kenji hara wrote:
2013/4/23 Mehrdad
On Tuesday, 23 April 2013 at 04:44:52 UTC, kenji hara wrote:
This is mostly expected behavior. During compilation value
identities are
not guaranteed.
Because compile time evaluation is always done after consta
On Tuesday, 23 April 2013 at 04:58:30 UTC, anonymous wrote:
For fast bitwise comparison there's the "is" operator.
The "==" operator should be "slow".
See also http://d.puremagic.com/issues/show_bug.cgi?id=3789
Well okay. The docs will have to be updated for this issue if
it's "fixed".
For i
On Tuesday, 23 April 2013 at 05:05:29 UTC, Chris Cain wrote:
In any case, I stand by that if you have a particular
definition of behavior, you should provide it instead of
expecting it to "just work." But I suppose using "is" is more
appropriate for this type of behavior. But calling it "broken
On Tuesday, 23 April 2013 at 05:05:29 UTC, Chris Cain wrote:
I suppose using "is" is more appropriate for this type of
behavior.
If when you see a == b you think,
Hey, that's equivalent to (a.d is b.d)
I suppose that when you see (a is b) you think,
Hey, that's equivalent to a.
On Tuesday, 23 April 2013 at 05:16:35 UTC, Chris Cain wrote:
Actually, I'm going to strengthen this a bit more. I'd _still_
think it's a good idea to keep structs the way they are. I
expect (as I think many would) structs to be very bare metal.
Very little auto-magic should touch them because t
On Tuesday, 23 April 2013 at 05:28:54 UTC, Mehrdad wrote:
If when you see a == b you think,
Hey, that's equivalent to (a.d is b.d)
I suppose that when you see (a is b) you think,
Hey, that's equivalent to a.d == b.d
?
Incorrect. When I see a == b, I don't think anything. Thanks
On Tuesday, 23 April 2013 at 05:48:08 UTC, Chris Cain wrote:
Incorrect. When I see a == b, I don't think anything.
I stand corrected I guess. I'll stop thinking as well.
It doesn't make sense to _you_.
Okay sure, have fun watching people use languages that make more
sense to them than D
On Tuesday, 23 April 2013 at 04:26:59 UTC, Chris Cain wrote:
On Tuesday, 23 April 2013 at 03:46:30 UTC, Mehrdad wrote:
...
Nope, still broken.
The behavior isn't too surprising to me. Your code is buggy.
You want to explain why the code is bugguy.
On Tuesday, 23 April 2013 at 05:57:16 UTC, Mehrdad wrote:
I stand corrected I guess. I'll stop thinking as well.
...
Okay sure, have fun watching people use languages that make
more sense to them than D I guess.
*sigh*
I really wish you'd be more cooperative in this conversation. I
certainly
On Tuesday, 23 April 2013 at 06:10:00 UTC, deadalnix wrote:
You want to explain why the code is bugguy.
Sure. He didn't know the behavior of "==" on structs and didn't
realize it tests for identity by default. Structs require an
opEquals defined to differ from this behavior.
On Tuesday, 23 April 2013 at 06:07:55 UTC, Chris Cain wrote:
On Tuesday, 23 April 2013 at 05:57:16 UTC, Mehrdad wrote:
I stand corrected I guess. I'll stop thinking as well.
...
Okay sure, have fun watching people use languages that make
more sense to them than D I guess.
*sigh*
I really wis
On Tuesday, 23 April 2013 at 06:24:24 UTC, Mehrdad wrote:
There's a reason why no other popular language (that I know of)
translates "==" into a bitwise comparison of structs. What do
you think the reason might be?
I'm intrigued. Mind listing the languages? As far as popular
languages are c
On Tuesday, 23 April 2013 at 06:26:55 UTC, Chris Cain wrote:
On Tuesday, 23 April 2013 at 06:24:24 UTC, Mehrdad wrote:
There's a reason why no other popular language (that I know
of) translates "==" into a bitwise comparison of structs. What
do you think the reason might be?
I'm intrigued.
On Tuesday, 23 April 2013 at 05:05:29 UTC, Chris Cain wrote:
On Tuesday, 23 April 2013 at 04:58:30 UTC, anonymous wrote:
For fast bitwise comparison there's the "is" operator.
The "==" operator should be "slow".
See also http://d.puremagic.com/issues/show_bug.cgi?id=3789
Well okay. The docs wi
On Tuesday, 23 April 2013 at 06:26:55 UTC, Chris Cain wrote:
On Tuesday, 23 April 2013 at 06:24:24 UTC, Mehrdad wrote:
There's a reason why no other popular language (that I know
of) translates "==" into a bitwise comparison of structs. What
do you think the reason might be?
I'm intrigued.
On Tuesday, 23 April 2013 at 06:23:56 UTC, Chris Cain wrote:
On Tuesday, 23 April 2013 at 06:10:00 UTC, deadalnix wrote:
You want to explain why the code is bugguy.
Sure. He didn't know the behavior of "==" on structs and didn't
realize it tests for identity by default. Structs require an
op
On Tuesday, 23 April 2013 at 06:24:24 UTC, Mehrdad wrote:
The trouble is that you've already failed before you started.
Also, I'm assuming that this means that you had no intention of
learning. That's kind of a poor position to be in, IMO. That
means that I can't help you because you don't w
On Tuesday, 23 April 2013 at 06:41:36 UTC, Chris Cain wrote:
So many solutions to your problem, yet you've already decided
that changing the language is the only "right" way.
I'm just telling you that if no other language has done it,
there's a reason behind it.
On Tuesday, 23 April 2013 at 06:41:36 UTC, Chris Cain wrote:
On Tuesday, 23 April 2013 at 06:24:24 UTC, Mehrdad wrote:
The trouble is that you've already failed before you started.
Also, I'm assuming that this means that you had no intention of
learning.
I could tell you the same thing, bu
On Tuesday, 23 April 2013 at 06:31:44 UTC, Mehrdad wrote:
I guess C and C++ aren't even considered languages anymore.
?
main.c:13:10: error: invalid operands to binary == (have ‘struct
S’ and ‘struct S’)
if(a == b)
You can't use == in C on structs ... ?
On Tuesday, 23 April 2013 at 06:50:08 UTC, Chris Cain wrote:
On Tuesday, 23 April 2013 at 06:31:44 UTC, Mehrdad wrote:
I guess C and C++ aren't even considered languages anymore.
?
main.c:13:10: error: invalid operands to binary == (have
‘struct S’ and ‘struct S’)
if(a == b)
You can't
On Tuesday, 23 April 2013 at 06:46:49 UTC, Mehrdad wrote:
I could tell you the same thing, but it wouldn't get me
anywhere.
Alrighty, that's my sign to leave. Good luck Mehrdad.
On Tuesday, 23 April 2013 at 06:52:03 UTC, Chris Cain wrote:
On Tuesday, 23 April 2013 at 06:46:49 UTC, Mehrdad wrote:
I could tell you the same thing, but it wouldn't get me
anywhere.
Good luck Mehrdad.
Same to you.
On Tuesday, 23 April 2013 at 06:54:07 UTC, Mehrdad wrote:
Same to you.
I'm going to just be a little frank with you here.
I've _never_ had even a slightly productive conversation with
you. You're hostile to work with. I know you have some valuable
things to say and contribute to the communit
On Tuesday, 23 April 2013 at 07:09:41 UTC, Chris Cain wrote:
On Tuesday, 23 April 2013 at 06:54:07 UTC, Mehrdad wrote:
Same to you.
I'm going to just be a little frank with you here.
I've _never_ had even a slightly productive conversation with
you. You're hostile to work with. I know you ha
On Tuesday, 23 April 2013 at 07:19:47 UTC, Mehrdad wrote:
I'm not having trouble finding workarounds, I'm just pointing
out examples of why people aren't finding D usable (or why they
consider it broken).
And I know no one likes to hear something is broken.
I'm not doing that to be mean or som
On Tuesday, 23 April 2013 at 07:19:47 UTC, Mehrdad wrote:
Sorry, most of my responses are really short because I'm
working on other things at the moment.
I'm just trying to say a few sentences to make a point and go
back to what I'm doing, but it's not going as well as I would
have hoped.
O
On Tuesday, 23 April 2013 at 07:37:29 UTC, Chris Cain wrote:
On Tuesday, 23 April 2013 at 07:19:47 UTC, Mehrdad wrote:
Sorry, most of my responses are really short because I'm
working on other things at the moment.
I'm just trying to say a few sentences to make a point and go
back to what I'm
On Monday, 22 April 2013 at 22:17:33 UTC, eles wrote:
On Monday, 22 April 2013 at 14:25:21 UTC, David Nadlinger wrote:
On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote:
What's holding you from releasing a version now and declaring
it stable for e.g. a year?
What would be the benefit of
On Monday, 22 April 2013 at 14:25:21 UTC, David Nadlinger wrote:
On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote:
What's holding you from releasing a version now and declaring
it stable for e.g. a year?
What would be the benefit of just declaring one release stable?
This is not a tric
On Tuesday, 23 April 2013 at 07:50:44 UTC, Dicebot wrote:
I have raised this topic several times already. Stable version
that is guaranteed to never break user code
So what happens when a flaw in the language is fixed?
Do you fix it and break code, or do you leave it broken?
On Tuesday, 23 April 2013 at 07:52:20 UTC, Mehrdad wrote:
On Tuesday, 23 April 2013 at 07:50:44 UTC, Dicebot wrote:
I have raised this topic several times already. Stable version
that is guaranteed to never break user code
So what happens when a flaw in the language is fixed?
Do you fix it a
On Tuesday, 23 April 2013 at 07:52:20 UTC, Mehrdad wrote:
On Tuesday, 23 April 2013 at 07:50:44 UTC, Dicebot wrote:
I have raised this topic several times already. Stable version
that is guaranteed to never break user code
So what happens when a flaw in the language is fixed?
Do you fix it a
On Tuesday, 23 April 2013 at 08:18:08 UTC, Dicebot wrote:
On Tuesday, 23 April 2013 at 07:52:20 UTC, Mehrdad wrote:
On Tuesday, 23 April 2013 at 07:50:44 UTC, Dicebot wrote:
I have raised this topic several times already. Stable
version that is guaranteed to never break user code
So what hap
On Tuesday, 23 April 2013 at 07:50:44 UTC, Dicebot wrote:
On Monday, 22 April 2013 at 14:25:21 UTC, David Nadlinger wrote:
On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote:
What's holding you from releasing a version now and declaring
it stable for e.g. a year?
What would be the benefi
On Tuesday, 23 April 2013 at 07:52:20 UTC, Mehrdad wrote:
On Tuesday, 23 April 2013 at 07:50:44 UTC, Dicebot wrote:
I have raised this topic several times already. Stable version
that is guaranteed to never break user code
So what happens when a flaw in the language is fixed?
Do you fix it a
On Tuesday, 23 April 2013 at 08:23:34 UTC, David Nadlinger wrote:
Okay, maybe it was somewhat of a trick question after all:
"Tourist" put it as if all that was required was to mark a
certain version stable, and I wanted to hint at the fact that
this alone wouldn't help anybody at all.
David
It is simply impossible for D. Defining trait for C/C++ is very
strict and formal standard paper which completely defines the
language. Revise of standard is decoupled with compiler releases.
Standard can be revised once in a 10 years but compilers keep
evolving having this paper in mind.
D h
On Tuesday, 23 April 2013 at 08:40:16 UTC, Dicebot wrote:
D has reference compiler and thus you technically suggest to
stop releasing any compiler version for 1-2 years. Ugh.
No. Stop adding things.
Besides that, what's the alternative?
On 23 April 2013 09:56, eles wrote:
> On Tuesday, 23 April 2013 at 08:40:16 UTC, Dicebot wrote:
>
>>
>> D has reference compiler and thus you technically suggest to stop
>> releasing any compiler version for 1-2 years. Ugh.
>>
>
> No. Stop adding things.
>
> Besides that, what's the alternative?
On Tuesday, 23 April 2013 at 09:23:50 UTC, Iain Buclaw wrote:
On 23 April 2013 09:56, eles wrote:
On Tuesday, 23 April 2013 at 08:40:16 UTC, Dicebot wrote:
D has reference compiler and thus you technically suggest to
stop
releasing any compiler version for 1-2 years. Ugh.
No. Stop addi
On Tuesday, 23 April 2013 at 08:56:37 UTC, eles wrote:
On Tuesday, 23 April 2013 at 08:40:16 UTC, Dicebot wrote:
D has reference compiler and thus you technically suggest to
stop releasing any compiler version for 1-2 years. Ugh.
No. Stop adding things.
Besides that, what's the alternative?
On Tuesday, 23 April 2013 at 07:43:21 UTC, Flamaros wrote:
On Monday, 22 April 2013 at 22:17:33 UTC, eles wrote:
On Monday, 22 April 2013 at 14:25:21 UTC, David Nadlinger
wrote:
On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote:
What's holding you from releasing a version now and
declari
On 4/23/13 4:33 AM, eles wrote:
On Tuesday, 23 April 2013 at 07:52:20 UTC, Mehrdad wrote:
On Tuesday, 23 April 2013 at 07:50:44 UTC, Dicebot wrote:
I have raised this topic several times already. Stable version that
is guaranteed to never break user code
So what happens when a flaw in the la
On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu
wrote:
I think we shouldn't follow the C++ model. Whatever made C++
successful is not what'll make D successful. The context and
expectations are very different now.
Andrei
That's a pretty vague assertion. Please define the model
On 4/23/13 2:42 PM, eles wrote:
On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu wrote:
I think we shouldn't follow the C++ model. Whatever made C++
successful is not what'll make D successful. The context and
expectations are very different now.
Andrei
That's a pretty vague ass
On Tuesday, 23 April 2013 at 18:57:46 UTC, Andrei Alexandrescu
wrote:
On 4/23/13 2:42 PM, eles wrote:
On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu
I was mainly referring to the fact that C++ succeeded in spite
of having initially an incomplete specification. Nowadays the
expe
On 04/23/2013 10:21 PM, eles wrote:
On Tuesday, 23 April 2013 at 18:57:46 UTC, Andrei Alexandrescu wrote:
On 4/23/13 2:42 PM, eles wrote:
On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu
I was mainly referring to the fact that C++ succeeded in spite of
having initially an incompl
Am 23.04.2013 22:21, schrieb eles:
On Tuesday, 23 April 2013 at 18:57:46 UTC, Andrei Alexandrescu wrote:
On 4/23/13 2:42 PM, eles wrote:
On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu
I was mainly referring to the fact that C++ succeeded in spite of
having initially an incomple
On Tuesday, 23 April 2013 at 20:21:55 UTC, eles wrote:
On Tuesday, 23 April 2013 at 18:57:46 UTC, Andrei Alexandrescu
wrote:
On 4/23/13 2:42 PM, eles wrote:
On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu
I was mainly referring to the fact that C++ succeeded in spite
of having i
On Tuesday, April 23, 2013 07:02:39 Mehrdad wrote:
> Well, I think the float behavior is correct and the string
> example is broken, but that wasn't my point anyway.
>
> The point was that it's still broken.
According to TDPL (section 7.1.5.2, p. 258 - 259), == on structs should be
equivalent to
On Monday, 22 April 2013 at 22:17:33 UTC, eles wrote:
On Monday, 22 April 2013 at 14:25:21 UTC, David Nadlinger wrote:
On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote:
Sorry, I was rude here and I apologize. Finally, D is (at least)
a wonderful place to discuss and test new ideas and,
On Tuesday, 23 April 2013 at 20:21:55 UTC, eles wrote:
On Tuesday, 23 April 2013 at 18:57:46 UTC, Andrei Alexandrescu
wrote:
On 4/23/13 2:42 PM, eles wrote:
On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu
I was mainly referring to the fact that C++ succeeded in spite
of having i
On Sunday, 28 April 2013 at 09:24:13 UTC, SomeDude wrote:
I also think when modules are integrated into the C++ standard,
for most developers, there won't be any case left for D. Even
though D technically is superior in almost every way,
conservatism is strong enough.
C++ will never be suffic
Am 28.04.2013 12:03, schrieb Dicebot:
On Sunday, 28 April 2013 at 09:24:13 UTC, SomeDude wrote:
I also think when modules are integrated into the C++ standard, for
most developers, there won't be any case left for D. Even though D
technically is superior in almost every way, conservatism is stro
On Sunday, 28 April 2013 at 12:01:58 UTC, Paulo Pinto wrote:
True, but only now the major OS vendors are switching from C to
C++ as their main systems programming language.
Curious, which ones are you referring to?
Windows uses C for the kernel, for many reasons, one of which is
that C (unlik
On Sunday, 28 April 2013 at 23:11:30 UTC, Mehrdad wrote:
On Sunday, 28 April 2013 at 12:01:58 UTC, Paulo Pinto wrote:
Which vendors have switched to C++ for systems programming?
Paolo probably had MS in mind which didn't release WinRT for C.
On Monday, 29 April 2013 at 04:19:06 UTC, Oleg Kuporosov wrote:
On Sunday, 28 April 2013 at 23:11:30 UTC, Mehrdad wrote:
On Sunday, 28 April 2013 at 12:01:58 UTC, Paulo Pinto wrote:
Which vendors have switched to C++ for systems programming?
Paolo probably had MS in mind which didn't release
On 2013-04-29 01:11, Mehrdad wrote:
Curious, which ones are you referring to?
Windows uses C for the kernel, for many reasons, one of which is that C
(unlike C++) discourages storing large objects on the stack.
Linux uses C for the kernel too, mainly because Walter hates C++ (and
C++ programme
On Sunday, 28 April 2013 at 12:01:58 UTC, Paulo Pinto wrote:
Am 28.04.2013 12:03, schrieb Dicebot:
On Sunday, 28 April 2013 at 09:24:13 UTC, SomeDude wrote:
I also think when modules are integrated into the C++
True, but only now the major OS vendors are switching from C to
C++ as their main s
On Monday, 29 April 2013 at 06:45:32 UTC, eles wrote:
...
D is simply in no shape to compete for kernels for same reasons
it is rather painful to use in embedded (fat runtime, language
features relying on hidden gc allocations etc.) It is hardly
practical to discuss the moment to compete whe
On Monday, 29 April 2013 at 07:44:15 UTC, Dicebot wrote:
On Monday, 29 April 2013 at 06:45:32 UTC, eles wrote:
D is simply in no shape to compete for kernels for same reasons
it is rather painful to use in embedded (fat runtime, language
features relying on hidden gc allocations etc.) It is har
On Monday, 29 April 2013 at 08:07:05 UTC, eles wrote:
I even start thinking that is better to release a new feature
after a relative short, preliminary discussion, and be prepared
to change it during a time frame, if it is not as practical as
desired, instead of prolonging a discussion for cent
On Sunday, 28 April 2013 at 23:11:30 UTC, Mehrdad wrote:
On Sunday, 28 April 2013 at 12:01:58 UTC, Paulo Pinto wrote:
True, but only now the major OS vendors are switching from C
to C++ as their main systems programming language.
Curious, which ones are you referring to?
Windows uses C for th
On Sunday, 28 April 2013 at 23:11:30 UTC, Mehrdad wrote:
On Sunday, 28 April 2013 at 12:01:58 UTC, Paulo Pinto wrote:
Linux uses C for the kernel too, mainly because Walter hates
C++ (and C++ programmers).
err, Linus
On Monday, 29 April 2013 at 07:44:15 UTC, Dicebot wrote:
On Monday, 29 April 2013 at 06:45:32 UTC, eles wrote:
...
D is simply in no shape to compete for kernels for same reasons
it is rather painful to use in embedded (fat runtime, language
features relying on hidden gc allocations etc.) It
On Monday, 29 April 2013 at 09:54:29 UTC, Paulo Pinto wrote:
This guys don't have any issues selling Oberon compilers for
embedded use.
...
That is simple, "embedded" is a buzzword often understood as
"something like PC but small". Such definition is quite useless
because it implies no speci
On Monday, 29 April 2013 at 10:38:32 UTC, Dicebot wrote:
On Monday, 29 April 2013 at 09:54:29 UTC, Paulo Pinto wrote:
This guys don't have any issues selling Oberon compilers for
embedded use.
...
That is simple, "embedded" is a buzzword often understood as
"something like PC but small". Suc
On Monday, 29 April 2013 at 11:15:20 UTC, Paulo Pinto wrote:
Quoting myself
"Or course this is a very limited subset of what embedded is all
about, but I think D could also be usable in such types of
boards."
Okay, pardon me, may be I have not highlighted my point clear
enough: there is no r
On Monday, 29 April 2013 at 11:24:02 UTC, Dicebot wrote:
On Monday, 29 April 2013 at 11:15:20 UTC, Paulo Pinto wrote:
Quoting myself
"Or course this is a very limited subset of what embedded is
all
about, but I think D could also be usable in such types of
boards."
Okay, pardon me, may be I
91 matches
Mail list logo
