On Friday, 25 April 2014 at 19:51:22 UTC, Adam Wilson wrote:
I know we don't place much value in TIOBE and it's brethren.
However, I thought that this was a milestone worthy of a note
anyways.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
It's interesting that C++ has
On Friday, 25 April 2014 at 08:45:20 UTC, Atila Neves wrote:
After I read the above I wasn't even sure how @Given(foo)
would work so I wrote some code and now know that all I need is
a struct with a regular string field. I think the documenation
on http://dlang.org/attribute.html is severely
On Friday, 25 April 2014 at 08:45:20 UTC, Atila Neves wrote:
Ehm... because until now I didn't know that @Given(foo) was
possible. In my head I was doing compile-time stuff so
everything had to be compile-time, if that makes any sense.
After I read the above I wasn't even sure how
On 2014-04-25 10:31, Atila Neves wrote:
Or I could carry on implementing all the Cucumber features and end up
with an executable that does everything the Ruby version does. I'm happy
with what I've got now though, but the embedding thing is interesting. I
just decided that embedding was too
On Saturday, 27 July 2013 at 22:27:35 UTC, Brian Schott wrote:
* Prints out a complete AST of a source file in XML format.
Neat feature! I met two bugs that need some love:
https://github.com/Hackerpilot/Dscanner/issues/168
https://github.com/Hackerpilot/Dscanner/issues/169
Aside: the D
On Tuesday, 18 February 2014 at 02:24:32 UTC, Steven
Schveighoffer wrote:
Yes, and one can do it with a global flag too. The lack of this
ability is really a terrible omission for D2.
We have the flag - GCX.running, it's just not exposed.
On Sat, Apr 26, 2014 at 06:54:55 +, Joakim via Digitalmars-d-announce wrote:
On Friday, 25 April 2014 at 19:51:22 UTC, Adam Wilson wrote:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
It's interesting that C++ has been declining for the last decade and
especially the
On Saturday, 26 April 2014 at 23:10:22 UTC, Ben Boeckel via
Digitalmars-d-announce wrote:
Wow, TIOBE looks even more useless than the last time looked at
it
(years ago). Is TSQL really more popular than Perl? I wonder
how much
oh dear, I need help with this is conflating these ratings. I
mean,
On Saturday, 26 April 2014 at 23:10:22 UTC, Ben Boeckel via
Digitalmars-d-announce wrote:
Wow, TIOBE looks even more useless than the last time looked at
it
(years ago). Is TSQL really more popular than Perl? I wonder
how much
oh dear, I need help with this is conflating these ratings.
On Saturday, 26 April 2014 at 23:13:49 UTC, Dicebot wrote:
Don't forget that it does not only consider new code but
overall picture. And amount of legacy code in weird languages
is still huge.
It does not consider code, it uses the hitcounters from search
engines for this query:
+language
On Sunday, 27 April 2014 at 05:21:29 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 26 April 2014 at 23:13:49 UTC, Dicebot wrote:
Don't forget that it does not only consider new code but
overall picture. And amount of legacy code in weird languages
is still huge.
It does not consider code, it
On 4/25/2014 7:28 AM, bearophile wrote:
Dicebot:
It is unacceptable to have code that fails with one compiler and works with
the other despite the shared frontend version. Such enhanced @nogc
attributes must be placed into compiler-specific attribute space and not as a
core language feature.
On Friday, 25 April 2014 at 15:29:38 UTC, Steven Schveighoffer
wrote:
Well, @nogc is not released yet. Please tell me we don't have
to avoid breaking code based on git HEAD...
We've already done that before, with UDA's. So, you never know.
--
/Jacob Carlborg
On 4/24/2014 7:16 AM, Iain Buclaw via Digitalmars-d wrote:
On 24 April 2014 12:01, Ary Borenszweig via Digitalmars-d
It wasn't IIRC. 'Twas in-house GC, no?
It was with the C++ version of the original D collector.
On Sat, 26 Apr 2014 00:44:13 -0400
Steven Schveighoffer via Digitalmars-d digitalmars-d@puremagic.com
wrote:
On Fri, 25 Apr 2014 23:26:29 -0400, Xinok xi...@live.com wrote:
On Saturday, 26 April 2014 at 01:57:06 UTC, bearophile wrote:
This is one of the largest problems left in the
http://wiki.dlang.org/DIP61
Best practices in C++ code increasingly means putting functions and declarations
in namespaces. Currently, there is no support in D to call C++ functions in
namespaces. The primary issue is that the name mangling doesn't match. Need a
simple and straightforward
On 2014-04-25 16:28, bearophile wrote:
This problem was underlined during this thread far before the merging of
the @nogc implementation. Why have Walter Andrei ignored the problem?
What's the point of creating a DIP if you ignore the problems found in
its discussion? What's the point of 338
On 2014-04-26 11:31, Walter Bright wrote:
http://wiki.dlang.org/DIP61
Best practices in C++ code increasingly means putting functions and
declarations in namespaces. Currently, there is no support in D to call
C++ functions in namespaces. The primary issue is that the name mangling
doesn't
Walter Bright:
The @nogc logic is entirely contained in the front end, and is
not affected by back end logic.
Thank you for your answer and sorry for me being sometimes too
much nervous.
So the problem I was alarmed about doesn't exists.
Some time ago I have filed this ER:
Walter Bright:
http://wiki.dlang.org/DIP61
Best practices in C++ code increasingly means putting functions
and declarations in namespaces. Currently, there is no support
in D to call C++ functions in namespaces. The primary issue is
that the name mangling doesn't match. Need a simple and
Jonathan M Davis:
However, I'm not sure that treating it as weakly pure buys
us anything except in the case where we're trying to make
the outer function pure as well.
Here is a bit more realistic example of the problem, currently
this (rather common) code doesn't compile:
import
On Saturday, 26 April 2014 at 09:31:48 UTC, Walter Bright wrote:
There have been many proposals earlier:
http://forum.dlang.org/post/lhi1lt$269h$1...@digitalmars.com
My search found the following proposals:
[1]
extern (C++, namespace = A.B) {}
[2]
pragma(cpp_namespace, A.B)
extern(C++)
On Saturday, 26 April 2014 at 10:20:30 UTC, bearophile wrote:
But I prefer an ugly-looking feature that will be used only to
call C++ functions in namespaces, and not for general D
programming. So you will not see D code that looks like C++.
There is an advantage to keeping the D/C++
Am Sat, 26 Apr 2014 02:31:51 -0700
schrieb Walter Bright newshou...@digitalmars.com:
http://wiki.dlang.org/DIP61
but it seems to me that the simplest, most straightforward approach
would be better.
As more and more people are attempting to call C++ libraries from D,
this is getting to
On Saturday, 26 April 2014 at 09:31:48 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP61
Best practices in C++ code increasingly means putting functions
and declarations in namespaces. Currently, there is no support
in D to call C++ functions in namespaces. The primary issue is
that the
On 04/26/2014 11:31 AM, Walter Bright wrote:
http://wiki.dlang.org/DIP61
Best practices in C++ code increasingly means putting functions and
declarations in namespaces. Currently, there is no support in D to call
C++ functions in namespaces. The primary issue is that the name mangling
doesn't
Walter Bright wrote in message news:ljfue4$11dk$1...@digitalmars.com...
There have been many proposals earlier:
http://forum.dlang.org/post/lhi1lt$269h$1...@digitalmars.com
but it seems to me that the simplest, most straightforward approach would
be better.
So, people didn't like the
Jacob Carlborg wrote in message news:ljfvec$126l$1...@digitalmars.com...
That's a problem. The problem is if someone has an idea/code it wants to
be merged, it's enough to convince one developer with push right to get it
merged.
At least these days it only happens when Walter and Andrei
Is there some reason why
extern(c++, std::printf);
is rejected?
If the purpose here is to map c++ code and we are only worried
about namespaces in the c++ context, why not just make it
identical to the c++ declaration?
A pragma to indicate the name mangling scheme since MS and GCC
use
On 04/26/2014 01:57 PM, Dicebot wrote:
I think this is a very bad proposal. Necessity to define namespaces for
interfacing with C++ must not result in usage of namespaces of pure D code.
Well, the proposed feature does not add any new capabilities except
proper mangling. In pure D code
On Saturday, 26 April 2014 at 11:57:48 UTC, Dicebot wrote:
On Saturday, 26 April 2014 at 09:31:48 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP61
I think this is a very bad proposal. Necessity to define
namespaces for interfacing with C++ must not result in usage of
namespaces of pure
On 4/26/14, 7:38 AM, Daniel Murphy wrote:
Walter Bright wrote in message news:ljfue4$11dk$1...@digitalmars.com...
There have been many proposals earlier:
http://forum.dlang.org/post/lhi1lt$269h$1...@digitalmars.com
but it seems to me that the simplest, most straightforward approach
would
On Saturday, 26 April 2014 at 11:57:48 UTC, Dicebot wrote:
I think this is a very bad proposal. Necessity to define
namespaces for interfacing with C++ must not result in usage of
namespaces of pure D code.
I agree, please just add a way of calling C++ and not a brand new
feature that will
On 4/26/2014 4:57 AM, Dicebot wrote:
Necessity to define namespaces for
interfacing with C++ must not result in usage of namespaces of pure D code.
Why?
I don't see much of any use for namespaces in pure D code, though I could be
surprised.
On 4/26/2014 8:19 AM, Timon Gehr wrote:
Well, the proposed feature does not add any new capabilities except proper
mangling. In pure D code
namespace foo{
// declarations
}
would be basically the same as
private mixin template Foo(){
// declarations
}
mixin Foo foo;
That's right.
On 4/26/2014 5:37 AM, Timon Gehr wrote:
import std.stdio;
namespace g{
int foo(int a){ return a; }
}
namespace g{
string foo(string a){ return a; }
}
void main(){
writeln(foo(2));
writeln(foo(a));
writeln(g.foo(2));
writeln(g.foo(a));
}
Both examples should still
On Saturday, 26 April 2014 at 18:13:00 UTC, Walter Bright wrote:
Yeah, template mixins turned out to be a solution looking for a
problem.
template mixins rock, I use them for a bunch of things.
On 4/26/2014 7:38 AM, Daniel Murphy wrote:
So, people didn't like the proposal last time you made the thread, so you made
it again? My objections from the last thread still stand. Mangling is all we
need, just add a pragma or attribute to add mangling and don't tie it to other
language
On Saturday, 26 April 2014 at 18:11:18 UTC, Walter Bright wrote:
On 4/26/2014 4:57 AM, Dicebot wrote:
Necessity to define namespaces for
interfacing with C++ must not result in usage of namespaces of
pure D code.
Why?
I don't see much of any use for namespaces in pure D code,
though I
On Saturday, 26 April 2014 at 15:19:55 UTC, Timon Gehr wrote:
On 04/26/2014 01:57 PM, Dicebot wrote:
I think this is a very bad proposal. Necessity to define
namespaces for
interfacing with C++ must not result in usage of namespaces of
pure D code.
Well, the proposed feature does not add
On Saturday, 26 April 2014 at 18:18:39 UTC, Walter Bright wrote:
On 4/26/2014 7:38 AM, Daniel Murphy wrote:
So, people didn't like the proposal last time you made the
thread, so you made
it again? My objections from the last thread still stand.
Mangling is all we
need, just add a pragma or
On 4/26/2014 4:01 AM, Mike wrote:
My search found the following proposals:
[1]
extern (C++, namespace = A.B) {}
Technically, this can work, and I was initially in favor of it. But it just
strikes me as awkward. It may be one of the first things C++ programmers wanting
to use D may have to
On 4/26/2014 11:17 AM, Adam D. Ruppe wrote:
On Saturday, 26 April 2014 at 18:13:00 UTC, Walter Bright wrote:
Yeah, template mixins turned out to be a solution looking for a problem.
template mixins rock, I use them for a bunch of things.
I stand corrected :-)
On 4/26/2014 11:30 AM, Dicebot wrote:
Compromise - consider namespace definition from extern(C++) during name
resolution. But still keep actual feature tied to extern(C++) to keep its use
case clear.
I mentioned something similar in a previous reply to you. Hope that means we can
reach a
On 4/26/2014 11:21 AM, Dicebot wrote:
Namespaces also don't solve any problem for that can't be already elegantly
solved.
There isn't any existing elegant solution to calling a C++ function in a
namespace. See Mike's post.
We are very reluctant to add new useful features because of implied
On Saturday, 26 April 2014 at 18:51:16 UTC, Walter Bright wrote:
On 4/26/2014 11:21 AM, Dicebot wrote:
Namespaces also don't solve any problem for that can't be
already elegantly
solved.
There isn't any existing elegant solution to calling a C++
function in a namespace.
Can I make a note
On 4/26/2014 11:57 AM, Andrej Mitrovic wrote:
Can I make a note about something? The C++ committee keeps adding new features
to C++, libraries are probably going to start using those features. So when C++
gets feature X and D has to have link compatibility with C++, will we be forced
to invent
Walter Bright wrote in message news:ljgt9v$1psm$1...@digitalmars.com...
Having a pragma to just add mangling doesn't deal with problems like:
namespace N { int foo(); }
namespace M { int foo(); }
foo(); // how to specify which one gets called?
I.e. only addressing name
On 4/26/14, 2:31 AM, Walter Bright wrote:
http://wiki.dlang.org/DIP61
Best practices in C++ code increasingly means putting functions and
declarations in namespaces. Currently, there is no support in D to call
C++ functions in namespaces. The primary issue is that the name mangling
doesn't
On 4/26/14, 12:27 PM, Daniel Murphy wrote:
Walter Bright wrote in message news:ljgt9v$1psm$1...@digitalmars.com...
Having a pragma to just add mangling doesn't deal with problems like:
namespace N { int foo(); }
namespace M { int foo(); }
foo(); // how to specify which one
On Saturday, 26 April 2014 at 09:31:48 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP61
Best practices in C++ code increasingly means putting functions
and declarations in namespaces. Currently, there is no support
in D to call C++ functions in namespaces. The primary issue is
that the
On 4/26/2014 1:06 PM, Jacob Carlborg wrote:
BTW, can't we just handle this automatically in a tool like DStep, with the help
of pragma(mangle).
Just setting the name mangling is not enough. There's also the issue of how does
one refer to A.B.foo() rather than C.D.foo() ?
On 2014-04-26 09:31:51 +, Walter Bright newshou...@digitalmars.com said:
http://wiki.dlang.org/DIP61
Best practices in C++ code increasingly means putting functions and
declarations in namespaces. Currently, there is no support in D to call
C++ functions in namespaces. The primary issue
On 4/26/2014 12:27 PM, Daniel Murphy wrote:
We already have a feature to manage conflicts and organisation in D code -
modules!
True. But what D doesn't have is a global namespace. I don't propose one for D,
but C++ symbols may appear in the C++ global namespace, or in a C++ namespace.
So
24-Apr-2014 05:12, Marco Leise пишет:
Am Wed, 23 Apr 2014 21:23:17 +0400
schrieb Dmitry Olshansky dmitry.o...@gmail.com:
23-Apr-2014 20:56, Daniel Murphy пишет:
Dmitry Olshansky wrote in message news:lj7mrr$1p5s$1...@digitalmars.com...
At a times I really don't know why can't we just drop
On Saturday, 26 April 2014 at 20:07:25 UTC, Andrei Alexandrescu
wrote:
Yah, that's why something along the lines of
extern(C++) module facebook.folly;
comes to mind. Following such a module declaration, stuff
inside of it is considered inside C++ namespace facebook::folly.
The disadvantage
On 2014-04-26 19:13:52 +, Walter Bright newshou...@digitalmars.com said:
I think that trying to be compatible with C++ templates is utter
madness. But we can handle namespaces.
I'd argue that templates aren't the difficult part. Having struct/class
semantics ABI-compatible with C++ is
On 04/26/2014 08:13 PM, Walter Bright wrote:
private mixin template Foo(){
// declarations
}
mixin Foo foo;
... I guess namespaces will occur in pure D code as
sparsely as the above construction, because they are not particularly
useful.
Yeah, template mixins turned out to be a solution
On Saturday, 26 April 2014 at 20:17:45 UTC, Walter Bright wrote:
On 4/26/2014 1:06 PM, Jacob Carlborg wrote:
BTW, can't we just handle this automatically in a tool like
DStep, with the help
of pragma(mangle).
Just setting the name mangling is not enough. There's also the
issue of how does
On Saturday, 26 April 2014 at 18:52:41 UTC, Walter Bright wrote:
On 4/26/2014 11:30 AM, Dicebot wrote:
Compromise - consider namespace definition from extern(C++)
during name
resolution. But still keep actual feature tied to
extern(C++) to keep its use
case clear.
I mentioned something
On 04/26/2014 08:15 PM, Walter Bright wrote:
On 4/26/2014 5:37 AM, Timon Gehr wrote:
import std.stdio;
namespace g{
int foo(int a){ return a; }
}
namespace g{
string foo(string a){ return a; }
}
void main(){
writeln(foo(2));
writeln(foo(a));
writeln(g.foo(2));
On Saturday, 26 April 2014 at 18:11:18 UTC, Walter Bright wrote:
On 4/26/2014 4:57 AM, Dicebot wrote:
Necessity to define namespaces for
interfacing with C++ must not result in usage of namespaces of
pure D code.
Why?
I don't see much of any use for namespaces in pure D code, […]
This is
On Saturday, 26 April 2014 at 18:13:00 UTC, Walter Bright wrote:
Yeah, template mixins turned out to be a solution looking for a
problem.
I disagree, a recent project I'm completing simply wouldn't of
been possible without them. On the surface they look superfluous
but in the right situation
On 04/26/2014 09:27 PM, Daniel Murphy wrote:
We already have a feature to manage conflicts and organisation in D code -
modules!
Named mixin templates are a much closer fit.
There is no need to add namespaces to do that, and if that's really what you
want
it belongs in a completely
On 04/26/2014 10:32 PM, Daniel N wrote:
The disadvantage of this is that it forces one .di file per namespace,
whereas in C++ people frequently use different namespaces within the
same file.
Andrei
I would argue that this restriction is a benefit not a disadvantage,
Why on earth would
On Saturday, 26 April 2014 at 21:57:55 UTC, Timon Gehr wrote:
Which is all the DIP adds. I do not really understand the
objections.
It adds a new language feature, which is not just used only in a
rather specific situation, but also very likely to be confused
with the eponymous feature from
On 04/26/2014 09:56 PM, Andrei Alexandrescu wrote:
I think this is not a good proposal from a proportional response
standpoint: it squanders a keyword for a minor feature.
I also think the preexisting suggestions are each wanting in various ways.
That's why we should guide the discussion not
On 04/27/2014 12:03 AM, David Nadlinger wrote:
On Saturday, 26 April 2014 at 21:57:55 UTC, Timon Gehr wrote:
Which is all the DIP adds. I do not really understand the objections.
It adds a new language feature, which is not just used only in a rather
specific situation, but also very likely
On Saturday, 26 April 2014 at 21:57:55 UTC, Timon Gehr wrote:
On 04/26/2014 09:27 PM, Daniel Murphy wrote:
We already have a feature to manage conflicts and organisation
in D code - modules!
Named mixin templates are a much closer fit.
Using named mixin templates for pure scope resolution
On Saturday, 26 April 2014 at 18:13:00 UTC, Walter Bright wrote:
On 4/26/2014 8:19 AM, Timon Gehr wrote:
Well, the proposed feature does not add any new capabilities
except proper
mangling. In pure D code
namespace foo{
// declarations
}
would be basically the same as
private mixin
On 04/27/2014 12:43 AM, Dicebot wrote:
On Saturday, 26 April 2014 at 21:57:55 UTC, Timon Gehr wrote:
On 04/26/2014 09:27 PM, Daniel Murphy wrote:
We already have a feature to manage conflicts and organisation in D
code - modules!
Named mixin templates are a much closer fit.
Using named
On Saturday, 26 April 2014 at 23:05:23 UTC, Timon Gehr wrote:
On 04/27/2014 12:43 AM, Dicebot wrote:
On Saturday, 26 April 2014 at 21:57:55 UTC, Timon Gehr wrote:
On 04/26/2014 09:27 PM, Daniel Murphy wrote:
We already have a feature to manage conflicts and
organisation in D
code -
On 04/27/2014 01:11 AM, Dicebot wrote:
On Saturday, 26 April 2014 at 23:05:23 UTC, Timon Gehr wrote:
On 04/27/2014 12:43 AM, Dicebot wrote:
On Saturday, 26 April 2014 at 21:57:55 UTC, Timon Gehr wrote:
On 04/26/2014 09:27 PM, Daniel Murphy wrote:
We already have a feature to manage
If I am not missing some more point, what is the best solution?
Before this question gets lost, I'd like to receive some kind of
answer.
Thank you,
bearophile
Since the namespace keyword doesn't seem to be gaining much traction, an
alternative syntax would be:
extern (C++, N.M) { void foo(); }
which would be semantically equivalent to the previous:
extern (C++) namespace N { namespace M { void foo(); }}
this code: std.conv.parse!byte(-128) throws error: Overflow in
integral conversion. but this is obviously not true, as signed
byte can hold such value.
the question is: is it bug, or it's intended behavior to limit
signed integrals to values which can be safely abs()ed?
On 4/26/2014 2:58 PM, Gary Willoughby wrote:
I disagree, a recent project I'm completing simply wouldn't of been possible
without them. On the surface they look superfluous but in the right situation
they are a very elegant solution. I'll be announcing my project soon.
Cool. I'm looking
On 04/27/2014 01:32 AM, bearophile wrote:
If I am not missing some more point, what is the best solution?
Before this question gets lost, I'd like to receive some kind of answer.
Thank you,
bearophile
The front end already distinguishes dynamic and static array literals
(in a limited
On Saturday, 26 April 2014 at 23:35:44 UTC, Walter Bright wrote:
On 4/26/2014 2:45 PM, Dicebot wrote:
On Saturday, 26 April 2014 at 20:17:45 UTC, Walter Bright
wrote:
On 4/26/2014 1:06 PM, Jacob Carlborg wrote:
BTW, can't we just handle this automatically in a tool like
DStep, with the help
Walter Bright:
Since the namespace keyword doesn't seem to be gaining much
traction, an alternative syntax would be:
extern (C++, N.M) { void foo(); }
which would be semantically equivalent to the previous:
extern (C++) namespace N { namespace M { void foo(); }}
It looks worse, so
On 4/26/2014 2:45 PM, Dicebot wrote:
On Saturday, 26 April 2014 at 20:17:45 UTC, Walter Bright wrote:
On 4/26/2014 1:06 PM, Jacob Carlborg wrote:
BTW, can't we just handle this automatically in a tool like DStep, with the help
of pragma(mangle).
Just setting the name mangling is not enough.
On Saturday, 26 April 2014 at 23:32:42 UTC, Walter Bright wrote:
Since the namespace keyword doesn't seem to be gaining much
traction, an alternative syntax would be:
extern (C++, N.M) { void foo(); }
which would be semantically equivalent to the previous:
extern (C++) namespace N {
ketmar:
this code: std.conv.parse!byte(-128) throws error: Overflow
in integral conversion. but this is obviously not true, as
signed byte can hold such value.
the question is: is it bug, or it's intended behavior to limit
signed integrals to values which can be safely abs()ed?
This code
On Saturday, 26 April 2014 at 23:36:28 UTC, ketmar wrote:
this code: std.conv.parse!byte(-128) throws error: Overflow
in integral conversion. but this is obviously not true, as
signed byte can hold such value.
Check your math... the most negative number a signed byte can
hold is -127. The
On 4/26/2014 3:01 PM, Timon Gehr wrote:
On 04/26/2014 10:32 PM, Daniel N wrote:
The disadvantage of this is that it forces one .di file per namespace,
whereas in C++ people frequently use different namespaces within the
same file.
Andrei
I would argue that this restriction is a benefit not
On Saturday, 26 April 2014 at 23:43:11 UTC, Adam D. Ruppe wrote:
Check your math
sorry, i should check my own math. I got it backwards, you're
right.
On 04/27/2014 01:43 AM, Adam D. Ruppe wrote:
On Saturday, 26 April 2014 at 23:36:28 UTC, ketmar wrote:
this code: std.conv.parse!byte(-128) throws error: Overflow in
integral conversion. but this is obviously not true, as signed byte
can hold such value.
Check your math... the most negative
On 4/26/14, 4:32 PM, Walter Bright wrote:
Since the namespace keyword doesn't seem to be gaining much traction, an
alternative syntax would be:
extern (C++, N.M) { void foo(); }
which would be semantically equivalent to the previous:
extern (C++) namespace N { namespace M { void
ah, sorry, this is my own fault, there is no bug in parser. what
i'm doing is parse!byte(128) and then negating the result.
silly me.
On 4/26/14, 4:43 PM, Adam D. Ruppe wrote:
On Saturday, 26 April 2014 at 23:36:28 UTC, ketmar wrote:
this code: std.conv.parse!byte(-128) throws error: Overflow in
integral conversion. but this is obviously not true, as signed byte
can hold such value.
Check your math... the most negative
On 4/26/14, 4:36 PM, ketmar wrote:
this code: std.conv.parse!byte(-128) throws error: Overflow in
integral conversion. but this is obviously not true, as signed byte can
hold such value.
the question is: is it bug, or it's intended behavior to limit signed
integrals to values which can be
On Sunday, 27 April 2014 at 00:01:21 UTC, Andrei Alexandrescu
wrote:
Oops. No bug. -- Andrei
Nah, sorry, that was my giant mistake, I didn't actually do the
math before saying check your math and let my brain get
confused into thinking 1000 was 128, but it is actually -128
in twos
On 04/27/2014 01:59 AM, Andrei Alexandrescu wrote:
On 4/26/14, 4:32 PM, Walter Bright wrote:
Since the namespace keyword doesn't seem to be gaining much traction, an
alternative syntax would be:
extern (C++, N.M) { void foo(); }
which would be semantically equivalent to the previous:
On Sat, Apr 26, 2014 at 04:32:29PM -0700, Walter Bright via Digitalmars-d wrote:
Since the namespace keyword doesn't seem to be gaining much traction,
an alternative syntax would be:
extern (C++, N.M) { void foo(); }
which would be semantically equivalent to the previous:
extern
On 4/26/2014 4:35 PM, Dicebot wrote:
Much better. And global C++ namespace will be plain extern(C++), right?
Right.
On 4/26/2014 4:59 PM, Andrei Alexandrescu wrote:
On 4/26/14, 4:32 PM, Walter Bright wrote:
Since the namespace keyword doesn't seem to be gaining much traction, an
alternative syntax would be:
extern (C++, N.M) { void foo(); }
which would be semantically equivalent to the previous:
On Saturday, 26 April 2014 at 23:32:42 UTC, Walter Bright wrote:
Since the namespace keyword doesn't seem to be gaining much
traction, an alternative syntax would be:
extern (C++, N.M) { void foo(); }
which would be semantically equivalent to the previous:
extern (C++) namespace N {
On Sunday, 27 April 2014 at 00:04:15 UTC, ketmar wrote:
but this is definetely bug, i think:
void main() {
import std.stdio : writeln;
import std.conv : to;
writeln(to!int(29a, 16)); // 666
writeln(to!int(+29a, 16)); // Unexpected '+' when converting
from type string base 16 to type int
ah, i see: if (radix == 10) return parse!Target(s); in Target
parse(Target, Source)(ref Source s, uint radix)
it cheating a little and using 'general' decimal number parser,
which accepts '+' and '-'. for other bases it uses another code
though, where '+' and '-' threats as digits, which
On Wednesday, 9 April 2014 at 14:59:35 UTC, Benjamin Thaut wrote:
E.g. it could look like this (alternative a new keyword
explicit could be introduced, but introduction of new
keywords is usually avoided if possible, AFAIK):
sorry for not reading the whole post and necroposting, but
please,
1 - 100 of 190 matches
Mail list logo
