On 07/12/2013 17:29, Walter Bright wrote:
On 12/7/2013 1:52 AM, Joseph Rushton Wakeling wrote:
On 07/12/13 02:10, Walter Bright wrote:
I know well that people used to C++ will likely do this. However, one can get in
the habit of by default adding "final:" as the first line in a class definition
I won't continue nitpicking on separate points because it clearly
seems to me we are speaking with completely different
applications in mind. Have you noticed project example I have
described for Manu
(http://forum.dlang.org/post/mznzsfktnzfggckgy...@forum.dlang.org)?
It does not work with applica
On 12.12.2013 12:12, Timon Gehr wrote:> On 12/12/2013 11:12 AM, Daniel Murphy
wrote:
>> "ed" wrote in message
>> news:ibnfbsvxqzjxyfpnz...@forum.dlang.org...
>>>
>>> I'm writing my C code with DMD. When tested and tweaked I do a final
>>> compile with C compiler (test once more) then commit for
On Monday, 16 December 2013 at 17:39:14 UTC, Francesco Cattoglio
wrote:
On Monday, 16 December 2013 at 17:32:11 UTC, deadalnix wrote:
On Monday, 16 December 2013 at 00:53:21 UTC, Walter Bright
Good idea. I suggest writing a pull request against the
documentation for this.
That is a bad idea a
On Monday, 16 December 2013 at 19:08:49 UTC, Ola Fosheim Grøstad
wrote:
10% of the total performance. GPUs now do TerraFLOPs. FPGAS are
Tera… ;)
On Monday, 16 December 2013 at 18:20:23 UTC, Andrei Alexandrescu
wrote:
Nonsense. Using extralinguistic tools including code generators
is not the exclusive appurtenance of C.
Not sure what you mean is nonsense. In general, having to resort
to macros and source-generating tools have been seen
Am Mon, 16 Dec 2013 18:39:13 +0100
schrieb "Francesco Cattoglio" :
> On Monday, 16 December 2013 at 17:32:11 UTC, deadalnix wrote:
> > On Monday, 16 December 2013 at 00:53:21 UTC, Walter Bright
> >> Good idea. I suggest writing a pull request against the
> >> documentation for this.
> >
> > That
On 12/16/13 5:35 AM, "Ola Fosheim Grøstad"
" wrote:
On Wednesday, 11 December 2013 at 00:19:50 UTC, H. S. Teoh wrote:
hardware. So arguably, no matter what code fragment you may present in
C++ or D, there's always a corresponding C code fragment that performs
equally fast or faster.
Yes, but t
On Monday, 16 December 2013 at 17:32:11 UTC, deadalnix wrote:
On Monday, 16 December 2013 at 00:53:21 UTC, Walter Bright
Good idea. I suggest writing a pull request against the
documentation for this.
That is a bad idea as it preclude any GC optimization based on
immutability.
What do you m
On Monday, 16 December 2013 at 00:53:21 UTC, Walter Bright wrote:
On 12/15/2013 4:22 PM, jerro wrote:
You, as the guy who wrote the code, will (or should) know
that there are no
other live references, hence you are telling the compiler
"trust me, I know
there aren't any".
So, is the intended
On Wednesday, 11 December 2013 at 00:19:50 UTC, H. S. Teoh wrote:
hardware. So arguably, no matter what code fragment you may
present in
C++ or D, there's always a corresponding C code fragment that
performs
equally fast or faster.
Yes, but the unix/C-way is to have many simple programs that
Am Sun, 15 Dec 2013 16:53:21 -0800
schrieb Walter Bright :
> On 12/15/2013 4:22 PM, jerro wrote:
> >> You, as the guy who wrote the code, will (or should) know that there are no
> >> other live references, hence you are telling the compiler "trust me, I know
> >> there aren't any".
> >
> > So, is
On 12/16/2013 01:53 AM, Walter Bright wrote:
On 12/15/2013 4:22 PM, jerro wrote:
You, as the guy who wrote the code, will (or should) know that there
are no
other live references, hence you are telling the compiler "trust me,
I know
there aren't any".
So, is the intended meaning the following:
On 12/15/2013 11:53 PM, Uplink_Coder wrote:
On Sunday, 15 December 2013 at 11:52:17 UTC, Timon Gehr wrote:
On 12/15/2013 02:20 AM, Walter Bright wrote:
On 12/14/2013 4:36 PM, Timon Gehr wrote:
I cannot cast data from my own storage allocator to immutable
because the
behaviour will be undefined
On Sunday, 15 December 2013 at 22:53:19 UTC, Uplink_Coder wrote:
On Sunday, 15 December 2013 at 11:52:17 UTC, Timon Gehr wrote:
On 12/15/2013 02:20 AM, Walter Bright wrote:
On 12/14/2013 4:36 PM, Timon Gehr wrote:
I cannot cast data from my own storage allocator to
immutable because the
behav
On 12/15/2013 4:22 PM, jerro wrote:
You, as the guy who wrote the code, will (or should) know that there are no
other live references, hence you are telling the compiler "trust me, I know
there aren't any".
So, is the intended meaning the following: If there exist any immutable
references to th
You, as the guy who wrote the code, will (or should) know that
there are no other live references, hence you are telling the
compiler "trust me, I know there aren't any".
So, is the intended meaning the following: If there exist any
immutable references to the data, mutating it results in
und
Undefined behaviour may have a precise meaning to a academic,
but
for me as a programmer it means. AVOID THIS SITUATION !!! unless
you know what you do!
And to the compiler writer it means: In this situation, you can
do whatever the hell you want! Later, when you think you know
what you are do
On 12/15/2013 3:52 AM, Timon Gehr wrote:
On 12/15/2013 02:20 AM, Walter Bright wrote:
On 12/14/2013 4:36 PM, Timon Gehr wrote:
I cannot cast data from my own storage allocator to immutable because the
behaviour will be undefined.
http://dlang.org/const3.html
Is this a documentation bug? What
On Sunday, 15 December 2013 at 11:52:17 UTC, Timon Gehr wrote:
On 12/15/2013 02:20 AM, Walter Bright wrote:
On 12/14/2013 4:36 PM, Timon Gehr wrote:
I cannot cast data from my own storage allocator to immutable
because the
behaviour will be undefined.
http://dlang.org/const3.html
Is this a d
On 12/15/2013 02:20 AM, Jesse Phillips wrote:
On Sunday, 15 December 2013 at 00:36:31 UTC, Timon Gehr wrote:
I cannot cast data from my own storage allocator to immutable because
the behaviour will be undefined.
http://dlang.org/const3.html
Is this a documentation bug? What should be the actua
On 12/15/2013 02:20 AM, Walter Bright wrote:
On 12/14/2013 4:36 PM, Timon Gehr wrote:
I cannot cast data from my own storage allocator to immutable because the
behaviour will be undefined.
http://dlang.org/const3.html
Is this a documentation bug? What should be the actual rules?
It means it'
Am 14.12.2013 20:33, schrieb Walter Bright:
On 12/14/2013 9:37 AM, Paulo Pinto wrote:
On Saturday, 14 December 2013 at 17:12:16 UTC, bearophile wrote:
Dicebot:
@safe is a joke for barebone, you almost never be able to apply it :)
I think you can have some safe functions in C-style code to
On Dec 14, 2013 10:51 PM, "Walter Bright"
wrote:
>
> On 12/14/2013 11:46 AM, Iain Buclaw wrote:
>>
>> I honestly don't know how one would be able to make AsmStatement work
>> for non-x86 architectures. At least this is not possible in GDC
>> unless you want to resort to doing things in a way that
On 12/14/2013 4:36 PM, Timon Gehr wrote:
I cannot cast data from my own storage allocator to immutable because the
behaviour will be undefined.
http://dlang.org/const3.html
Is this a documentation bug? What should be the actual rules?
It means it's up to you to ensure it is correct.
On Sunday, 15 December 2013 at 00:36:31 UTC, Timon Gehr wrote:
I cannot cast data from my own storage allocator to immutable
because the behaviour will be undefined.
http://dlang.org/const3.html
Is this a documentation bug? What should be the actual rules?
Casting to immutable is defined, it
On 12/14/2013 08:30 PM, Walter Bright wrote:
On 12/14/2013 9:19 AM, Timon Gehr wrote:
On 12/11/2013 12:46 AM, Walter Bright wrote:
On 12/10/2013 3:04 PM, Timon Gehr wrote:
Malloc is part of the language runtime. Everything needed is known
about it, in
particular that it is pure (in the D sense
On 12/14/2013 11:46 AM, Iain Buclaw wrote:
I honestly don't know how one would be able to make AsmStatement work
for non-x86 architectures. At least this is not possible in GDC
unless you want to resort to doing things in a way that are shamed
upon (like checking the definition of a particular T
On 12/14/2013 08:45 PM, Walter Bright wrote:
dmd's forward reference issues come from a bad design choice in the
compiler implementation. I've been gradually fixing the design, and
things have gotten a lot better. For example, with the latest release
you can forward reference enum members, even
On 12/14/2013 9:39 AM, H. S. Teoh wrote:
On Fri, Dec 13, 2013 at 06:01:10PM -0800, Walter Bright wrote:
On 12/13/2013 6:52 AM, Dicebot wrote:
I was so scarred from the experience that when I saw that D supported
unicode natively, I was totally sold.
Funny story about that. Before I started D,
On 14 December 2013 17:44, Walter Bright wrote:
> On 12/14/2013 6:08 AM, Iain Buclaw wrote:
>>
>> The implementation of which existed in GDC first, and was released as
>> dual GPL/BSD license to allow into LDC devs to use and improve (they
>> added 64bit assembler support for instance, years befor
On 12/14/2013 9:37 AM, Paulo Pinto wrote:
On Saturday, 14 December 2013 at 17:12:16 UTC, bearophile wrote:
Dicebot:
@safe is a joke for barebone, you almost never be able to apply it :)
I think you can have some safe functions in C-style code too :-)
Yes, given my experience in Turbo Pas
On 12/14/2013 9:19 AM, Timon Gehr wrote:
On 12/11/2013 12:46 AM, Walter Bright wrote:
On 12/10/2013 3:04 PM, Timon Gehr wrote:
Malloc is part of the language runtime. Everything needed is known
about it, in
particular that it is pure (in the D sense). Also, the source code of
malloc
will not be
On 12/14/2013 06:39 PM, H. S. Teoh wrote:
I still do that even in D programs, because DMD's handling of forward
references is, shall we say, quirky? It works most of the time, but
sometimes you get odd errors because certain symbol resolution
algorithms used by dmd will produce unexpected results
Am Fri, 13 Dec 2013 18:01:10 -0800
schrieb Walter Bright :
> On 12/13/2013 6:52 AM, Dicebot wrote:
> >> 1. compile speed
> >
> > Only partially true. Large projects need separate compilation and D does not
> > behave that good in such scenario. Still better than C, but not good enough
> > to
> >
H. S. Teoh:
I still do that even in D programs, because DMD's handling of
forward references is, shall we say, quirky?
In the last three years it has improved :-) Please submit the
remaining bugs on this.
Bye,
bearophile
On 12/14/2013 9:12 AM, bearophile wrote:
Dicebot:
2. dependable sizes of basic types
Not a real issue as your platform SDK always includes some kind of "stdint.h"
On the other hand in D you have less noise. Most D modules you find around use
and will use the built-in types, instead of choos
On 12/14/2013 6:08 AM, Iain Buclaw wrote:
The implementation of which existed in GDC first, and was released as
dual GPL/BSD license to allow into LDC devs to use and improve (they
added 64bit assembler support for instance, years before DMD got 64bit
support),
I didn't know this, thanks for te
On Fri, Dec 13, 2013 at 06:01:10PM -0800, Walter Bright wrote:
> On 12/13/2013 6:52 AM, Dicebot wrote:
[...]
> >>3. unicode
> >
> >Number one my list of advantages. Does not apply to plenty of
> >projects though.
>
> It applies more than you might think. Most D apps will be inherently
> unicode co
On Saturday, 14 December 2013 at 17:12:16 UTC, bearophile wrote:
Dicebot:
@safe is a joke for barebone, you almost never be able to
apply it :)
I think you can have some safe functions in C-style code too :-)
Yes, given my experience in Turbo Pascal and Oberon, there are
lots of places i
On 12/11/2013 12:46 AM, Walter Bright wrote:
On 12/10/2013 3:04 PM, Timon Gehr wrote:
Malloc is part of the language runtime. Everything needed is known
about it, in
particular that it is pure (in the D sense). Also, the source code of
malloc
will not be standard C code.
All right, so write yo
Dicebot:
2. dependable sizes of basic types
Not a real issue as your platform SDK always includes some kind
of "stdint.h"
On the other hand in D you have less noise. Most D modules you
find around use and will use the built-in types, instead of
choosing every time different ones. This uni
On 14 December 2013 04:08, Walter Bright wrote:
> On 12/13/2013 11:07 AM, David Nadlinger wrote:
>>
>> LDC in fact implements DMD-style inline assembly (occasionally there are
>> bugs,
>> though, as it's a complete reimplementation).
>
>
> Thank you! That's awesome!
>
The implementation of which
@attribute("forceinline") foo()
should be
@attribute("forceinline") ReturnType foo()
of course.
The alt-compilers have an attribute... if only we could alias
attributes
(or groups of attributes). Another thing we need... :/
With GDC you can already do this:
import gcc.attribute;
@attribute("forceinline") foo()
...
Am 13.12.2013 18:34, schrieb H. S. Teoh:
On Fri, Dec 13, 2013 at 03:30:21PM +0100, Paulo Pinto wrote:
[...]
Maybe the best way to fix this issue is to follow what other
language standards do (C++, Ada) and only define that inline
assembly is possible and how the entry point, e.g. asm () looks
li
On Saturday, 14 December 2013 at 04:09:18 UTC, Walter Bright
wrote:
On 12/13/2013 12:06 PM, deadalnix wrote:
I'm reinventing it right now for SDC, so it indeed make sense.
Reinventing EH or inline asm?
EH. Still very similar to what LDC does (which is understandable
as it uses LLVM as well)
On 12/13/2013 12:06 PM, deadalnix wrote:
I'm reinventing it right now for SDC, so it indeed make sense.
Reinventing EH or inline asm?
On 12/13/2013 11:07 AM, David Nadlinger wrote:
LDC in fact implements DMD-style inline assembly (occasionally there are bugs,
though, as it's a complete reimplementation).
Thank you! That's awesome!
I don't think it would be unreasonable to work towards a common D ABI on the
various Posix x86
On 12/13/13 11:07 AM, David Nadlinger wrote:
On Thursday, 12 December 2013 at 20:46:26 UTC, Walter Bright wrote:
On 12/12/2013 12:33 PM, Max Samukha wrote:
Don't you find it somewhat alarming that both alternative compilers follow
neither the standard inline asm nor ABI?
I find it unfortunate
On 14 December 2013 04:29, Walter Bright wrote:
> On 12/13/2013 9:01 AM, Manu wrote:
>
>> We really do need __forceinline. Walter did agreed on one occasion. He
>> said
>> something like "I've been thinking on it, and I think you might be
>> right", which
>> is almost a mental commitment... so th
On 12/13/2013 6:52 AM, Dicebot wrote:
1. compile speed
Only partially true. Large projects need separate compilation and D does not
behave that good in such scenario. Still better than C, but not good enough to
make a difference.
Doesn't behave that good how?
2. dependable sizes of basic t
On Friday, 13 December 2013 at 19:07:47 UTC, David Nadlinger
wrote:
On Thursday, 12 December 2013 at 20:46:26 UTC, Walter Bright
wrote:
On 12/12/2013 12:33 PM, Max Samukha wrote:
Don't you find it somewhat alarming that both alternative
compilers follow
neither the standard inline asm nor ABI?
13-Dec-2013 22:29, Walter Bright пишет:
On 12/13/2013 9:01 AM, Manu wrote:
We really do need __forceinline. Walter did agreed on one occasion. He
said
something like "I've been thinking on it, and I think you might be
right", which
is almost a mental commitment... so there's hope! :P
Sadly it wa
On Thursday, 12 December 2013 at 20:46:26 UTC, Walter Bright
wrote:
On 12/12/2013 12:33 PM, Max Samukha wrote:
Don't you find it somewhat alarming that both alternative
compilers follow
neither the standard inline asm nor ABI?
I find it unfortunate. But it also can be difficult and time
cons
On 12/13/2013 9:01 AM, Manu wrote:
We really do need __forceinline. Walter did agreed on one occasion. He said
something like "I've been thinking on it, and I think you might be right", which
is almost a mental commitment... so there's hope! :P
Sadly it was in a hotel parking lot, and not committ
Am Fri, 13 Dec 2013 09:34:17 -0800
schrieb "H. S. Teoh" :
> On Fri, Dec 13, 2013 at 03:30:21PM +0100, Paulo Pinto wrote:
> [...]
> > Maybe the best way to fix this issue is to follow what other
> > language standards do (C++, Ada) and only define that inline
> > assembly is possible and how the en
On Fri, Dec 13, 2013 at 03:30:21PM +0100, Paulo Pinto wrote:
[...]
> Maybe the best way to fix this issue is to follow what other
> language standards do (C++, Ada) and only define that inline
> assembly is possible and how the entry point, e.g. asm () looks
> like.
>
> The real inline assembly sy
On 14 December 2013 03:07, Dicebot wrote:
> On Friday, 13 December 2013 at 17:01:21 UTC, Manu wrote:
>
>> On 14 December 2013 02:50, Dicebot wrote:
>>
>> On Friday, 13 December 2013 at 16:28:33 UTC, Manu wrote:
>>>
>>> I could still REALLY do with __forceinline though. D doesn't have an
e
On Friday, 13 December 2013 at 17:01:21 UTC, Manu wrote:
On 14 December 2013 02:50, Dicebot wrote:
On Friday, 13 December 2013 at 16:28:33 UTC, Manu wrote:
I could still REALLY do with __forceinline though. D doesn't
have an
effective macro.
Obviously, if by 'language X' you mean 'any non-c
On 14 December 2013 02:50, Dicebot wrote:
> On Friday, 13 December 2013 at 16:28:33 UTC, Manu wrote:
>
>> I could still REALLY do with __forceinline though. D doesn't have an
>> effective macro.
>> Obviously, if by 'language X' you mean 'any non-compiled language with
>> pointers', then I totally
On Friday, 13 December 2013 at 16:28:33 UTC, Manu wrote:
I could still REALLY do with __forceinline though. D doesn't
have an
effective macro.
Obviously, if by 'language X' you mean 'any non-compiled
language with
pointers', then I totally agree! People who make claims like
you say, don't
gene
On 14 December 2013 01:42, Dicebot wrote:
> On Thursday, 12 December 2013 at 13:17:14 UTC, Manu wrote:
>
>> But that's not a concern for typical programmers. That the responsibility
>> of sysadmins.
>> What I meant was, 'what's more valuable [to a programmer]...'
>>
>
> Leaning dangerously close
On Thursday, 12 December 2013 at 13:17:14 UTC, Manu wrote:
But that's not a concern for typical programmers. That the
responsibility
of sysadmins.
What I meant was, 'what's more valuable [to a programmer]...'
Leaning dangerously close to philosophy here :)
Did you use many different compilers
On 13.12.2013 15:59, Adam D. Ruppe wrote:
On Friday, 13 December 2013 at 13:07:32 UTC, Rainer Schuetze wrote:
Implicite TLS in XP-DLLs has a workaround in druntime for a few years
now (emulating it for the system). IIRC Denis has even found a
solution how to unload these DLLs later.
There mu
On Friday, 13 December 2013 at 13:07:32 UTC, Rainer Schuetze
wrote:
Implicite TLS in XP-DLLs has a workaround in druntime for a few
years now (emulating it for the system). IIRC Denis has even
found a solution how to unload these DLLs later.
There must still be some bugs, I tried the COM thing
On Thursday, 12 December 2013 at 17:56:12 UTC, Walter Bright
wrote:
that does not even help you in sticking with that crippled
subset.
Is there a point to having a compiler flag that'll warn you if
you use "pure"?
Ugh, how "pure" is relevant? (I have not tried it but would
expect it to work
On Friday, 13 December 2013 at 13:57:09 UTC, Marco Leise wrote:
Am Thu, 12 Dec 2013 12:46:26 -0800
schrieb Walter Bright :
On 12/12/2013 12:33 PM, Max Samukha wrote:
> Don't you find it somewhat alarming that both alternative
> compilers follow
> neither the standard inline asm nor ABI?
I fi
Am Thu, 12 Dec 2013 12:46:26 -0800
schrieb Walter Bright :
> On 12/12/2013 12:33 PM, Max Samukha wrote:
> > Don't you find it somewhat alarming that both alternative compilers follow
> > neither the standard inline asm nor ABI?
>
> I find it unfortunate. But it also can be difficult and time cons
On 12.12.2013 19:46, Adam D. Ruppe wrote:
On Thursday, 12 December 2013 at 17:56:12 UTC, Walter Bright wrote:
5. thread local storage
I think this is a negative. D's TLS has caused me more problems than it
has fixed: for example, if you write an in-process COM server in Windows
XP, it will c
On 13 December 2013 15:39, Daniel Murphy wrote:
> "Manu" wrote in message
> news:mailman.513.1386905921.3242.digitalmar...@puremagic.com...
> >
> > Which appears basically everywhere an asm block does. 'asm' could
> > optionally receive an architecture as argument, and lower to the version
> > w
"Manu" wrote in message
news:mailman.513.1386905921.3242.digitalmar...@puremagic.com...
>
> Which appears basically everywhere an asm block does. 'asm' could
> optionally receive an architecture as argument, and lower to the version
> wrapper:
>
> asm(x86)
> {
> ...
> }
> else asm(ARM)
> {
> ..
Am 12.12.2013 21:16, schrieb Max Samukha:
On Thursday, 12 December 2013 at 20:06:37 UTC, Walter Bright
wrote:
On 12/12/2013 11:57 AM, Max Samukha wrote:
On Thursday, 12 December 2013 at 17:56:12 UTC, Walter Bright
wrote:
11. inline assembler being a part of the language rather than
an extensi
On 13 December 2013 13:38, Manu wrote:
> On 13 December 2013 06:08, H. S. Teoh wrote:
>
>> On Thu, Dec 12, 2013 at 08:57:42PM +0100, Max Samukha wrote:
>> > On Thursday, 12 December 2013 at 17:56:12 UTC, Walter Bright wrote:
>> >
>> > >11. inline assembler being a part of the language rather tha
On 13 December 2013 06:08, H. S. Teoh wrote:
> On Thu, Dec 12, 2013 at 08:57:42PM +0100, Max Samukha wrote:
> > On Thursday, 12 December 2013 at 17:56:12 UTC, Walter Bright wrote:
> >
> > >11. inline assembler being a part of the language rather than an
> > >extension that is in a markedly differ
On Thursday, 12 December 2013 at 09:01:17 UTC, Paulo Pinto wrote:
On Thursday, 12 December 2013 at 02:12:00 UTC, ed wrote:
On Wednesday, 11 December 2013 at 03:33:47 UTC, Walter Bright
wrote:
[snip]
The issue is convenience of writing C code in D vs C.
So you're trying to say that it's easi
On Thursday, 12 December 2013 at 20:46:26 UTC, Walter Bright
wrote:
On 12/12/2013 12:33 PM, Max Samukha wrote:
Don't you find it somewhat alarming that both alternative
compilers follow
neither the standard inline asm nor ABI?
I find it unfortunate. But it also can be difficult and time
cons
On 12/12/2013 12:33 PM, Max Samukha wrote:
Don't you find it somewhat alarming that both alternative compilers follow
neither the standard inline asm nor ABI?
I find it unfortunate. But it also can be difficult and time consuming to
reimplement an assembler for those back ends, so I can unders
On Thursday, 12 December 2013 at 20:24:19 UTC, Walter Bright
wrote:
On 12/12/2013 12:16 PM, Max Samukha wrote:
But the question is what to do about other targets? What about
ARM, MIL, LLVM IR
or whatever low-level target a D compiler may compile too?
Will those be
standardized as part of the l
On 12/12/2013 12:08 PM, H. S. Teoh wrote:
I've always wondered about that. What is D supposed to do with asm
blocks when compiling for a CPU that *isn't* x86??
Give an error. asm blocks should be protected with version statements for the
CPU type. The asm format should be what the CPU manufact
Am 12.12.2013 21:08, schrieb H. S. Teoh:
On Thu, Dec 12, 2013 at 08:57:42PM +0100, Max Samukha wrote:
On Thursday, 12 December 2013 at 17:56:12 UTC, Walter Bright wrote:
11. inline assembler being a part of the language rather than an
extension that is in a markedly different format for every
On 12/12/2013 12:16 PM, Max Samukha wrote:
But the question is what to do about other targets? What about ARM, MIL, LLVM IR
or whatever low-level target a D compiler may compile too? Will those be
standardized as part of the language?
I certainly think they ought to be.
On Thursday, 12 December 2013 at 20:06:37 UTC, Walter Bright
wrote:
On 12/12/2013 11:57 AM, Max Samukha wrote:
On Thursday, 12 December 2013 at 17:56:12 UTC, Walter Bright
wrote:
11. inline assembler being a part of the language rather than
an extension
that is in a markedly different format
On 12/12/2013 11:57 AM, Max Samukha wrote:
On Thursday, 12 December 2013 at 17:56:12 UTC, Walter Bright wrote:
11. inline assembler being a part of the language rather than an extension
that is in a markedly different format for every compiler
Ahem. If we admit that x86 is not the only ISA in
On Thu, Dec 12, 2013 at 08:57:42PM +0100, Max Samukha wrote:
> On Thursday, 12 December 2013 at 17:56:12 UTC, Walter Bright wrote:
>
> >11. inline assembler being a part of the language rather than an
> >extension that is in a markedly different format for every
> >compiler
>
> Ahem. If we admit
On Thursday, 12 December 2013 at 17:56:12 UTC, Walter Bright
wrote:
11. inline assembler being a part of the language rather than
an extension that is in a markedly different format for every
compiler
Ahem. If we admit that x86 is not the only ISA in exsistence,
then what is (under)specifie
On 12/12/2013 10:46 AM, Adam D. Ruppe wrote:
I agree with the rest of them, but D's default TLS has been a big pain to me.
You're right that TLS on XP with DLLs is a miserable problem. Fortunately, with
TLS now standard at least in C++, this problem is going away.
And, of course, you can use
On Thursday, 12 December 2013 at 17:56:12 UTC, Walter Bright
wrote:
5. thread local storage
I think this is a negative. D's TLS has caused me more problems
than it has fixed: for example, if you write an in-process COM
server in Windows XP, it will crash the host application if you
hit almos
On 12/12/2013 3:16 AM, Dicebot wrote:
To remove all "smart"
side-effects in D you need to get rid of all druntime, avoid
using some language features and resort to inline assembly
relatively often.
I don't see why you'd have to resort to inline assembler in D any more than in
C.
But it leave
On Thursday, 12 December 2013 at 12:21:31 UTC, Dicebot wrote:
I can't find code Adam used to provide minimal d runtime stubs
to compile C-like programs but he was forced to use in-line
assembly there in few cases. Can't remember details, sorry.
http://arsdnet.net/dcode/minimal.zip (not sure if
On 12 December 2013 22:21, Dicebot wrote:
> On Thursday, 12 December 2013 at 11:42:12 UTC, Manu wrote:
>
>> I've built a C codebase from the ground over the course of a decade with
>> ~25 programmers.
>> It takes discipline, and a certainly sense of simplicity in your
>> solutions.
>>
>
> It may
On Thursday, 12 December 2013 at 11:42:12 UTC, Manu wrote:
I've built a C codebase from the ground over the course of a
decade with
~25 programmers.
It takes discipline, and a certainly sense of simplicity in
your solutions.
It may work if you can afford to guarantee certain level of
compete
On Thursday, 12 December 2013 at 11:42:12 UTC, Manu wrote:
On 12 December 2013 21:16, Dicebot wrote:
On Thursday, 12 December 2013 at 09:01:17 UTC, Paulo Pinto
wrote:
Currently I always advocate that C and C++ development should
always be done with warnings as errors enabled, coupled with
s
On 12 December 2013 21:16, Dicebot wrote:
> On Thursday, 12 December 2013 at 09:01:17 UTC, Paulo Pinto wrote:
>
>> Currently I always advocate that C and C++ development should
>> always be done with warnings as errors enabled, coupled with
>> static analyzers at very least during CI builds, brea
On 12/12/2013 11:12 AM, Daniel Murphy wrote:
"ed" wrote in message
news:ibnfbsvxqzjxyfpnz...@forum.dlang.org...
I'm writing my C code with DMD. When tested and tweaked I do a final
compile with C compiler (test once more) then commit for our QA to pick
up. Occasionally I'll compile with the C
On Thursday, 12 December 2013 at 11:16:07 UTC, Dicebot wrote:
what does this give me over raw C to motivate the
transition? So far I don't see anything convincing.
Every time I write #define in one of my 8bit μC pet projects, I
know a reason.
On Thursday, 12 December 2013 at 09:01:17 UTC, Paulo Pinto wrote:
Currently I always advocate that C and C++ development should
always be done with warnings as errors enabled, coupled with
static analyzers at very least during CI builds, breaking them
if
anything is found.
I literally can't i
On 12/12/13 10:01, Paulo Pinto wrote:
Currently I always advocate that C and C++ development should
always be done with warnings as errors enabled, coupled with
static analyzers at very least during CI builds, breaking them if
anything is found.
I do think I owe quite a bit to the university pr
"ed" wrote in message
news:ibnfbsvxqzjxyfpnz...@forum.dlang.org...
>
> I'm writing my C code with DMD. When tested and tweaked I do a final
> compile with C compiler (test once more) then commit for our QA to pick
> up. Occasionally I'll compile with the C compiler to ensure I haven't
> leake
On Thursday, 12 December 2013 at 02:12:00 UTC, ed wrote:
On Wednesday, 11 December 2013 at 03:33:47 UTC, Walter Bright
wrote:
[snip]
The issue is convenience of writing C code in D vs C.
So you're trying to say that it's easier to write C code in
D, rather
than in C?
I thought this thread
1 - 100 of 297 matches
Mail list logo
