Just get it out of the way of the language
implementation.
But NONE of this needs to be done right now, or even this year,
or even next year. All I'm asking for with this thread is that
instead of making it harder to move away from the current
structure by adding core.stdcpp to druntime,
On 2014-08-29 23:00, simendsjo wrote:
It's still available at dsource: http://www.dsource.org/projects/ares
I don't think he's referring to Ares, he's referring to some other D
runtime.
--
/Jacob Carlborg
On Saturday, 30 August 2014 at 08:39:12 UTC, eles wrote:
On Saturday, 30 August 2014 at 00:01:50 UTC, Mike wrote:
On Friday, 29 August 2014 at 16:54:18 UTC, Sean Kelly wrote:
On Wednesday, 27 August 2014 at 09:43:03 UTC, Mike wrote:
On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright
w
On Saturday, 30 August 2014 at 00:01:50 UTC, Mike wrote:
On Friday, 29 August 2014 at 16:54:18 UTC, Sean Kelly wrote:
On Wednesday, 27 August 2014 at 09:43:03 UTC, Mike wrote:
On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright
wrote:
I'm judging by both the responses in this thread a
efine a "low-level library" and that
is probably why the line between phobos and druntime looks so
blurry to some.
In this thread, I'm simply trying to avoid having core.stdcpp
thrown in the druntime when I'm trying to move core.stdc to std.c.
It is wise to first use these
On 08/29/2014 07:07 PM, Sean Kelly wrote:
> On Wednesday, 27 August 2014 at 18:06:00 UTC, Daniel Murphy wrote:
>> "eles" wrote in message news:rixtiaiokrukvqjsf...@forum.dlang.org...
>>
>>> One such platform exists and is the embedded system, others are the
>>> linux kernel and the like, and even
On 8/29/14, 10:02 AM, Sean Kelly wrote:
Don't get me wrong, I hate having to maintain the modules in
core.stdc and core.sys. It's the worst job ever.
It's also one of those jobs silently appreciated by many. -- Andrei
On 8/27/2014 2:38 PM, deadalnix wrote:
The problem is that you don't always want to bring libc and libstdc++ with you
with every single project you write.
Remember that a library is not simply inserted bodily into the executable. A
library is searched for modules that define unresolved symbols
On Wednesday, 27 August 2014 at 18:06:00 UTC, Daniel Murphy wrote:
"eles" wrote in message
news:rixtiaiokrukvqjsf...@forum.dlang.org...
One such platform exists and is the embedded system, others
are the linux kernel and the like, and even others are writing
D compiler back-ends and, yes, dr
On Wednesday, 27 August 2014 at 21:38:04 UTC, deadalnix wrote:
The problem is that you don't always want to bring libc and
libstdc++ with you with every single project you write.
Thus it shouldn't be in the runtime (except the very bit you
can't get rid of). It can still be core.stdc .
To
On Wednesday, 27 August 2014 at 09:43:03 UTC, Mike wrote:
On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright
wrote:
The irony is D1 has std.c, and for D2 it was migrated to
core.stdc.
...and design takes the backseat to convenience.
This was a necessary part of the separation of t
On Wednesday, 27 August 2014 at 04:23:28 UTC, Mike wrote:
On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote:
I'm asking this community to consider setting a new precedent
for druntime: reduce the scope to just the language
implementation, encapsulate and isolate the platform specific
On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright wrote:
On 8/26/2014 5:32 PM, Mike wrote:
We currently have std.c and core.stdc. I believe core.stdc
should be
migrated to std.c, not the other way around. And before we
make the same
mistake with core.stdcpp, we should set a new
"eles" wrote in message news:rixtiaiokrukvqjsf...@forum.dlang.org...
But the request is simply to split the current druntime in a
language-runtime and a phobos-runtime. The namespace and so on might even
remain the same and the existing code would run unmodified. What is really
important is t
On Wednesday, 27 August 2014 at 02:17:39 UTC, Dicebot wrote:
On Wednesday, 27 August 2014 at 01:57:38 UTC, Mike wrote:
What do you think about following compromise:
1) C bindings are defined in spec to be optional
2) They are still kept in druntime repo but declared an
implementation detail
3)
On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright wrote:
On 8/26/2014 5:32 PM, Mike wrote:
We currently have std.c and core.stdc. I believe core.stdc
should be
migrated to std.c, not the other way around. And before we
make the same
mistake with core.stdcpp, we should set a new
On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright wrote:
On 8/26/2014 5:32 PM, Mike wrote:
Moving it back in an endless search for taxonomical perfection
Well, keeping things in limbo for such many years (@property,
anyone?) is not going to help neither.
I agree it is a fine bal
On Wednesday, 27 August 2014 at 07:52:18 UTC, Daniel Murphy wrote:
"eles" wrote in message
news:ybcxmuwwpsiyupwer...@forum.dlang.org...
Requiring full c/OS bindings in druntime is so useful, and it
costs us so little.
But the request is simply to split the current druntime in a
language-ru
"eles" wrote in message news:ybcxmuwwpsiyupwer...@forum.dlang.org...
The question of dupplication may be addressed now better, since the newly
fixed bug about hierarchical packaging.
I don't see how.
_only that_ should be the runtime. And the sole part that one needs to
port in order to cla
On 8/26/2014 5:32 PM, Mike wrote:
We currently have std.c and core.stdc. I believe core.stdc should be
migrated to std.c, not the other way around. And before we make the same
mistake with core.stdcpp, we should set a new precedent with std.cpp instead.
The irony is D1 has std.c, and for D2
On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote:
On Tuesday, 26 August 2014 at 18:28:38 UTC, Andrei Alexandrescu
wrote:
No. We currently have std.c and core.stdc.
Let's not even say this is confusing.
rk towards migrating them to phobos
or some other library in the years to come.
Since C++ language bindings are a new addition, let's not
exacerbate the problem by putting it in druntime as core.stdcpp,
but set a new precedent by putting them in std.cpp (or
core.stdcpp in phobos, or whate
On Wednesday, 27 August 2014 at 01:21:59 UTC, deadalnix wrote:
I think this cannot be understated. People have existing
codebase
that they aren't going to rewrite from scratch.
PS: This is the reason why SDC unwind C++'s exception properly
(but you obviously can't catch them).
On Wednesday, 27 August 2014 at 01:57:38 UTC, Mike wrote:
What do you think about following compromise:
1) C bindings are defined in spec to be optional
2) They are still kept in druntime repo but declared an
implementation detail
3) C bindings are defined to be mandatory in Phobos - if
Phobos
On Wednesday, 27 August 2014 at 01:05:19 UTC, Dicebot wrote:
On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote:
I believe druntime's scope should be reduced to simply
implementing the language, not creating an OS or library API.
That's what phobos and DUB are for.
I'm asking this comm
On Tuesday, 26 August 2014 at 14:48:48 UTC, Andrei Alexandrescu
wrote:
On 8/26/14, 3:06 AM, Mike wrote:
D has a lot of potential beyond it's current use. Please take
this
opportunity to reflect on what's been done, take a look ahead,
and see
if we can set a better precedent for the future.
On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote:
I believe druntime's scope should be reduced to simply
implementing the language, not creating an OS or library API.
That's what phobos and DUB are for.
I'm asking this community to consider setting a new precedent
for druntime: redu
t the artificial
dependencies to phobos or other libraries.
... and start by creating std.cpp instead of core.stdcpp.
On Tuesday, 26 August 2014 at 18:28:38 UTC, Andrei Alexandrescu
wrote:
I don't understand the objection. Are you arguing that we
shouldn't make core.stdc and core.stdcpp available, and instead
let anyone who wants to use libc and libc++ write their own
declarations?
No. We curr
On Tuesday, 26 August 2014 at 19:22:22 UTC, Daniel Murphy wrote:
"eles" wrote in message
news:qrfucjdbmydvoqgey...@forum.dlang.org...
Apart from the fact that it's too late to change of course.
Well, that separation is just a detail of the implementation, not
of the specification. You coul
"eles" wrote in message news:qrfucjdbmydvoqgey...@forum.dlang.org...
While this might be acceptable, there is one more question: what use to
have the druntime separated from phobos, in this case?
Apart from the fact that it's too late to change of course.
For me the druntime shall include on
On Tuesday, 26 August 2014 at 18:33:07 UTC, Daniel Murphy wrote:
"Mike" wrote in message
news:bkkdiikafdsraqssj...@forum.dlang.org...
> I really don't see a practical problem with having them in
> druntime, only a philosophical one.
It give the impression that D requires the C standard libr
On Tuesday, 26 August 2014 at 17:09:58 UTC, Walter Bright wrote:
On 8/26/2014 8:30 AM, Mike wrote:
There's never going to be a clear distinction between druntime
and phobos. The original reason for the split anyway was >
druntime would be a
Well, in C there is and I like that distinction: t
"Mike" wrote in message news:bkkdiikafdsraqssj...@forum.dlang.org...
> I really don't see a practical problem with having them in druntime,
> only a philosophical one.
It give the impression that D requires the C standard library, the C++
standard library, and an full-featured desktop OS in
g use of it.
Great.
But libstdc++ is not part of C++-the-language, and libc is not part of
C-the-language. C and C++ can be used without them; I do every day.
If core.stdcpp is intended to be the language bindings to libstdc++, I
don't think it should belong it D's language implemen
On Tuesday, 26 August 2014 at 17:09:58 UTC, Walter Bright wrote:
On 8/26/2014 8:30 AM, Mike wrote:
Regardless of where stdcpp goes, one issue is that the stuff in
it goes into the namespace "std", which conflicts with Phobos'
"std" higher level package name.
wow. I remember the hot debate a
On Tuesday, 26 August 2014 at 18:13:01 UTC, eles wrote:
On Tuesday, 26 August 2014 at 17:09:58 UTC, Walter Bright wrote:
On 8/26/2014 8:30 AM, Mike wrote:
wow. I remember the hot debate about the name o the standard
library back then.
well, namesace name
On 8/26/2014 8:30 AM, Mike wrote:
If core.stdcpp is intended to be the language bindings to libstdc++, I don't
think it should belong it D's language implementation, druntime, any more the
language bindings to Cairo or GTK should.
The same goes for core.stdc and core.sys.linux and f
On Tuesday, 26 August 2014 at 15:44:31 UTC, eles wrote:
On Tuesday, 26 August 2014 at 15:30:35 UTC, Mike wrote:
On Tuesday, 26 August 2014 at 14:48:48 UTC, Andrei
Alexandrescu wrote:
On 8/26/14, 3:06 AM, Mike wrote:
The same goes for core.stdc and core.sys.linux and friends, as
these are not
On Tuesday, 26 August 2014 at 12:54:49 UTC, Daniel Murphy wrote:
I really don't see a practical problem with having them in
druntime, only a philosophical one.
It give the impression that D requires the C standard library,
the C++ standard library, and an full-featured desktop OS in
order to
On Tuesday, 26 August 2014 at 15:30:35 UTC, Mike wrote:
On Tuesday, 26 August 2014 at 14:48:48 UTC, Andrei Alexandrescu
wrote:
On 8/26/14, 3:06 AM, Mike wrote:
The same goes for core.stdc and core.sys.linux and friends, as
these are not part of D's language implementation.
Am I correct to d
not part of C++-the-language, and libc is not
part of C-the-language. C and C++ can be used without them; I do
every day.
If core.stdcpp is intended to be the language bindings to
libstdc++, I don't think it should belong it D's language
implementation, druntime, any more the lang
On 8/26/14, 3:06 AM, Mike wrote:
D has a lot of potential beyond it's current use. Please take this
opportunity to reflect on what's been done, take a look ahead, and see
if we can set a better precedent for the future.
C++ interoperability is very important for D's future. -- Andrei
"Ola Fosheim Grøstad" " wrote in message
news:mclztlymyjydwhcxs...@forum.dlang.org...
Probably, at least without whole-program optimization turned on.
Linking with D is not a concern for whole-program-optimized C++ programs.
But you still have to track compiler version changelogs and then de
On Tuesday, 26 August 2014 at 12:23:18 UTC, Daniel Murphy wrote:
I would be very surprised to find a C++ compiler that does this
over public function boundaries, as it would prevent mixing
optimized and unoptimized code.
Probably, at least without whole-program optimization turned on.
But you
. The fact that druntime includes a prototype for memcpy or fopen
does not change anything either. It just makes D more convenient for
porting C code.
I politely ask those pursuing core.stdcpp to reconsider and look further
in the future. Please think beyond desktop and server application
prog
"Ola Fosheim Grøstad" " wrote in message
news:pbfaphgiugafrhach...@forum.dlang.org...
I know, but the vendor provided C++ libraries could trigger compiler-magic
in the optimizer, so it might not be enough to look at the source code in
the general case…
I would be very surprised to find a C++
On Tuesday, 26 August 2014 at 10:57:10 UTC, eles wrote:
For me, what it would be really nice to have in C from C++
would be templates.
And from D, that scope().
When I think about it, I think one of the reasons for going from
C to C++ in visualization/games was that 3D operations in C are
un
On Tuesday, 26 August 2014 at 07:56:45 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 26 August 2014 at 07:06:57 UTC, eles wrote:
convenient inlining and operator overloading. So people use it
For me, what it would be really nice to have in C from C++ would
be templates.
And from D, that scop
On Tuesday, 26 August 2014 at 10:44:03 UTC, Mike wrote:
On Tuesday, 26 August 2014 at 07:56:45 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 26 August 2014 at 07:06:57 UTC, eles wrote:
Yeah, I think C's success is directly linked to having a clear
use scenario and avoiding being a "general purpos
On Tuesday, 26 August 2014 at 07:56:45 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 26 August 2014 at 07:06:57 UTC, eles wrote:
Yeah, I think C's success is directly linked to having a clear
use scenario and avoiding being a "general purpose language"
What? C is THE quintessential general purpo
On Tuesday, 26 August 2014 at 06:35:18 UTC, Walter Bright wrote:
On 8/25/2014 11:12 PM, Mike wrote:
The C standard library and C++ standard library are not part
of D-the-language.
D would even be better served by putting these features in
phobos as std.stdc
and std.stdcpp. This would make them
On Tuesday, 26 August 2014 at 08:15:07 UTC, Marc Schütz wrote:
On Tuesday, 26 August 2014 at 06:12:54 UTC, Mike wrote:
The C standard library and C++ standard library are not part
of D-the-language. D would even be better served by putting
these features in phobos as std.stdc and std.stdcpp.
On Tuesday, 26 August 2014 at 08:25:58 UTC, Jonathan M Davis via
Digitalmars-d-announce wrote:
Quite possibly, but then it wouldn't integrate with existing
C++ libraries
built with the system's C++ compiler, which would be the point.
I know, but the vendor provided C++ libraries could trigger
On Tue, 26 Aug 2014 07:00:26 +
Ola Fosheim Gr via Digitalmars-d-announce
wrote:
> On Tuesday, 26 August 2014 at 06:35:18 UTC, Walter Bright wrote:
> > The implementation of it, however, is going to be ugly and very
> > specific to each C++ compiler. The user shouldn't need to have
> > to see
On Tuesday, 26 August 2014 at 06:12:54 UTC, Mike wrote:
The C standard library and C++ standard library are not part of
D-the-language. D would even be better served by putting these
features in phobos as std.stdc and std.stdcpp. This would make
them just as conveniently available to users, a
On Tuesday, 26 August 2014 at 07:06:57 UTC, eles wrote:
Apparently, all things have this tendency to get bloated. One
of the main reasons for C's still unbelievable success is its
slimness.
Yeah, I think C's success is directly linked to having a clear
use scenario and avoiding being a "gener
On Tuesday, 26 August 2014 at 06:12:54 UTC, Mike wrote:
On Tuesday, 26 August 2014 at 05:03:01 UTC, Daniel Murphy wrote:
"Mike" wrote in message
news:sdrjfagsayomsngme...@forum.dlang.org...
line between the language and the platform. Make it a more of
a language, and less of a framework.
On Tuesday, 26 August 2014 at 06:35:18 UTC, Walter Bright wrote:
The implementation of it, however, is going to be ugly and very
specific to each C++ compiler. The user shouldn't need to have
to see that ugliness, though.
Sounds easier to write your own ::std:: on the c++ side...
On 8/25/2014 11:12 PM, Mike wrote:
The C standard library and C++ standard library are not part of D-the-language.
D would even be better served by putting these features in phobos as std.stdc
and std.stdcpp. This would make them just as conveniently available to users,
and reduce the coupling b
instead of core.stdc,
libcpp_d instead of core.stdcpp, liblinux_d instead of
core.sys.linux, etc...?
I don't see how.
The C standard library and C++ standard library are not part of
D-the-language. D would even be better served by putting these
features in phobos as std.stdc and std.stdcpp. T
61 matches
Mail list logo