https://issues.dlang.org/show_bug.cgi?id=23390
Iain Buclaw changed:
What|Removed |Added
Priority|P1 |P3
--
https://issues.dlang.org/show_bug.cgi?id=23390
--- Comment #3 from kdevel ---
(In reply to kdevel from comment #2)
> As far as I recall the terminology for unknown but valid values is
> "unspecified value". Hence this issue.
Please delete the "but valid". My last paragraph should read:
As
it's set. This change would forbid that, and I don't see any
> benefit to doing so.
Sorry for the "UB" in the subject. The documentation says that the value of a
void initialized variable is "implementation defined". I corrected the subject.
"implementation defined" m
|variable is unspecified |variable is unspecified
|(and not subject to UB) |(and not subject to
||implementation defined
||behavior)
--
https://issues.dlang.org/show_bug.cgi?id=23390
elpenguin...@gmail.com changed:
What|Removed |Added
CC||elpenguin...@gmail.com
--- Comment
https://issues.dlang.org/show_bug.cgi?id=23390
Issue ID: 23390
Summary: value of void initialized variable is unspecified (and
not subject to UB)
Product: D
Version: D2
Hardware: All
OS: All
On 2018-01-17 09:41, Binghoo Dang wrote:
at least, the project is not active now
Not sure what you're talking about. The "master" branch was updated 10
days ago [1] and the "dub2 branch two days ago [2].
, you can just try to build it, you will found what I'm saying.
It built 10 days ago
On Tuesday, 16 January 2018 at 12:24:10 UTC, Jacob Carlborg wrote:
On 2018-01-16 09:56, Binghoo Dang wrote:
hi there,
the subject under Ecosystem on this forums exist an `DWT`,
which is now just seams dying , can you guy just remove DWT to
GUI ?
The project is not dead, but the forum
On Tuesday, 16 January 2018 at 12:11:30 UTC, Guillaume Piolat
wrote:
On Tuesday, 16 January 2018 at 08:56:50 UTC, Binghoo Dang wrote:
hi there,
the subject under Ecosystem on this forums exist an `DWT`,
which is now just seams dying , can you guy just remove DWT to
GUI ?
Or maybe
On 1/16/18 7:24 AM, Jacob Carlborg wrote:
On 2018-01-16 09:56, Binghoo Dang wrote:
hi there,
the subject under Ecosystem on this forums exist an `DWT`, which is
now just seams dying , can you guy just remove DWT to GUI ?
The project is not dead, but the forum doesn't get that much activity
On 2018-01-16 09:56, Binghoo Dang wrote:
hi there,
the subject under Ecosystem on this forums exist an `DWT`, which is now
just seams dying , can you guy just remove DWT to GUI ?
The project is not dead, but the forum doesn't get that much activity.
--
/Jacob Carlborg
On Tuesday, 16 January 2018 at 08:56:50 UTC, Binghoo Dang wrote:
hi there,
the subject under Ecosystem on this forums exist an `DWT`,
which is now just seams dying , can you guy just remove DWT to
GUI ?
Or maybe "Ecosystem" since there is no single place to speak
about
hi there,
the subject under Ecosystem on this forums exist an `DWT`, which
is now just seams dying , can you guy just remove DWT to GUI ?
On 5/16/17 2:29 PM, Stanislav Blinov wrote:
On Tuesday, 16 May 2017 at 15:47:37 UTC, Steven Schveighoffer wrote:
On 5/16/17 9:54 AM, Stanislav Blinov wrote:
On Tuesday, 16 May 2017 at 12:27:30 UTC, Steven Schveighoffer wrote:
When I have a type like this:
struct S
{
int foo;
}
and the
On Tuesday, 16 May 2017 at 15:47:37 UTC, Steven Schveighoffer
wrote:
On 5/16/17 9:54 AM, Stanislav Blinov wrote:
On Tuesday, 16 May 2017 at 12:27:30 UTC, Steven Schveighoffer
wrote:
When we have tests using dummy lambdas, are we to expect
users to
immediately extract the lambda body, parse
On 5/16/17 9:54 AM, Stanislav Blinov wrote:
On Tuesday, 16 May 2017 at 12:27:30 UTC, Steven Schveighoffer wrote:
When we have tests using dummy lambdas, are we to expect users to
immediately extract the lambda body, parse it, and figure out what's
wrong?
This is what you have to do today.
On Tuesday, 16 May 2017 at 14:00:51 UTC, Nick Treleaven wrote:
On Tuesday, 16 May 2017 at 11:20:57 UTC, Stanislav Blinov wrote:
On Tuesday, 16 May 2017 at 09:04:32 UTC, Nick Treleaven wrote:
The problem with this approach is all the work required to
convert existing code to use this style.
On Tuesday, 16 May 2017 at 11:20:57 UTC, Stanislav Blinov wrote:
On Tuesday, 16 May 2017 at 09:04:32 UTC, Nick Treleaven wrote:
The problem with this approach is all the work required to
convert existing code to use this style.
...
That's not a problem. In cases where compiler-provided
On Tuesday, 16 May 2017 at 12:27:30 UTC, Steven Schveighoffer
wrote:
When we have tests using dummy lambdas, are we to expect users
to
immediately extract the lambda body, parse it, and figure out
what's wrong?
This is what you have to do today. The task has already been
tried by the
On 5/15/17 8:14 PM, Stanislav Blinov wrote:
On Monday, 15 May 2017 at 20:55:35 UTC, Steven Schveighoffer wrote:
On 5/15/17 4:24 PM, Stanislav Blinov wrote:
On Monday, 15 May 2017 at 19:44:11 UTC, Steven Schveighoffer wrote:
It has to know. It has to evaluate the boolean to see if it should
On Tuesday, 16 May 2017 at 09:04:32 UTC, Nick Treleaven wrote:
...
foreach(i, T; types!args) {
typeof(args) ;-)
Thanks :)
static if (is(T == string)) {
pragma(msg, format!"Argument %d is a string, which
is not supported"
(i+1));
The problem
On Saturday, 13 May 2017 at 14:41:50 UTC, Stanislav Blinov wrote:
template types(args...) {
static if (args.length)
alias types = AliasSeq!(typeof(args[0]),
types!(args[1..$]));
else
alias types = AliasSeq!();
}
...
foreach(i, T; types!args) {
typeof(args) ;-)
On Saturday, 13 May 2017 at 14:41:50 UTC, Stanislav Blinov wrote:
file(line): Error: template foo cannot deduce function from
argument types !()(int, string), candidates are:
file(line): foo(Args...)(auto ref Args arg) if
(!anySatisfy!(isString, Args))
Ya know, even a simple new line before
On Monday, 15 May 2017 at 20:55:35 UTC, Steven Schveighoffer
wrote:
On 5/15/17 4:24 PM, Stanislav Blinov wrote:
On Monday, 15 May 2017 at 19:44:11 UTC, Steven Schveighoffer
wrote:
It has to know. It has to evaluate the boolean to see if it
should
compile! The current situation would be like
On 5/15/17 4:24 PM, Stanislav Blinov wrote:
On Monday, 15 May 2017 at 19:44:11 UTC, Steven Schveighoffer wrote:
It has to know. It has to evaluate the boolean to see if it should
compile! The current situation would be like the compiler saying
there's an error in your code, but won't tell you
On Monday, 15 May 2017 at 19:44:11 UTC, Steven Schveighoffer
wrote:
On 5/15/17 1:16 PM, Stanislav Blinov wrote:
On Monday, 15 May 2017 at 15:30:38 UTC, Steven Schveighoffer
wrote:
Argument 2 is a string, which is not supported
file(line): Error: template foo cannot deduce function from
On 5/15/17 1:16 PM, Stanislav Blinov wrote:
On Monday, 15 May 2017 at 15:30:38 UTC, Steven Schveighoffer wrote:
Argument 2 is a string, which is not supported
file(line): Error: template foo cannot deduce function from argument
types !()(int, string), candidates are:
file(line):
On Monday, 15 May 2017 at 15:30:38 UTC, Steven Schveighoffer
wrote:
Imagine also a constraint like isInputRange!R. This basically
attempts to compile a dummy lambda. How would one handle this
in user-code?
Let's look at something more practical than my initial example,
even if less
On Monday, 15 May 2017 at 15:30:38 UTC, Steven Schveighoffer
wrote:
Argument 2 is a string, which is not supported
file(line): Error: template foo cannot deduce function from
argument
types !()(int, string), candidates are:
file(line): foo(Args...)(auto ref Args arg) if
(noStringArgs!args)
On 5/13/17 10:41 AM, Stanislav Blinov wrote:
Let's suppose I wrote the following template function:
import std.meta;
enum bool isString(T) = is(T == string);
void foo(Args...)(auto ref Args args)
if (!anySatisfy!(isString, Args)) {
// ...
}
This one is variadic, but it could as well
Nobody read that or is it just *that* bad? :)
Let's suppose I wrote the following template function:
import std.meta;
enum bool isString(T) = is(T == string);
void foo(Args...)(auto ref Args args)
if (!anySatisfy!(isString, Args)) {
// ...
}
This one is variadic, but it could as well have been
non-variadic. The important
aspect is
On Tuesday, 28 February 2017 at 20:49:39 UTC, crimaniak wrote:
On Sunday, 26 February 2017 at 21:50:38 UTC, Jordan Wilson
wrote:
.map!(a => a.to!double)
If lambda just calls another function you can pass it directly:
== .map!(to!double)
Learn something new everyday, thanks :-)
On Sunday, 26 February 2017 at 21:50:38 UTC, Jordan Wilson wrote:
.map!(a => a.to!double)
If lambda just calls another function you can pass it directly:
== .map!(to!double)
On Sunday, 26 February 2017 at 21:50:38 UTC, Jordan Wilson wrote:
auto readNumMatCsv2 (string filePath, string ndv, string
new_ndv){
double[][] p_numArray;
try {
auto lines = File(filePath,"r").byLine;
lines.popFront; // get read of header
p_numArray =
I really appriciate your comments and thoughts!
On Sunday, 26 February 2017 at 21:02:52 UTC, ag0aep6g wrote:
On Sunday, 26 February 2017 at 19:34:33 UTC, thorstein wrote:
* "no-data-value"?
No-data-values in data sets are common at least in geosciences:
raster images, spatial simulation
On Sunday, 26 February 2017 at 19:34:33 UTC, thorstein wrote:
// Reads CSV-like files with only numeric values in each column
// new_ndv replaces ndv, which is the original no-data-value
double[][]* readNumMatCsv(char[] filePath, int numHeaderLines,
char[] ndv, char[] new_ndv)
*
Hi,
sorry for posting again, but I used a keyboard combination that
accidently send my post before it was done.
Coming more or less from Python I just started with D. Not a real
programmer, just automating things and looking for a neat
compiled language.
Just to learn, I wrote a function
---BeginMessage---
Another flurry of bounces floated through today (which I handled by removing the suspensions,
again). The only practical choice is a fairly intrusive one. I've enabled the from_is_list option,
meaning that the 'from' address from mail originating through the list will be
---BeginMessage---
Another flurry of bounces floated through today (which I handled by removing the suspensions,
again). The only practical choice is a fairly intrusive one. I've enabled the from_is_list option,
meaning that the 'from' address from mail originating through the list will be
Does it make sense?
I should be really in D.learn but asked that here in context ;)
Sounds like most of us should be in D Learn on this topic.
I should find the time to write up a case for Andrei's
suggestion. I have no problem with the compiler telling me that
my code is ambiguous, in
On Thursday, 21 November 2013 at 07:42:48 UTC, Craig Dillabaugh
wrote:
I should also mention, this post likely better belongs in:
digitalmars.D.learn
I don't entirely think so. I think the OP is arguing that D
should be able to identify symbol as specific enum's field when
used:
- in
On Thursday, 21 November 2013 at 07:22:39 UTC, Steve Teale wrote:
import std.stdio;
enum Intention
{
EVIL,
NEUTRAL,
GOOD,
SAINTLY
}
void foo(Intention rth)
{
if (rth == EVIL)
writeln(Road to hell);
}
void main()
{
foo(EVIL);
}
Why does the compiler complain in both
On Thursday, 21 November 2013 at 08:05:03 UTC, Michal Minich
wrote:
On Thursday, 21 November 2013 at 07:42:48 UTC, Craig Dillabaugh
wrote:
I should also mention, this post likely better belongs in:
digitalmars.D.learn
I don't entirely think so. I think the OP is arguing that D
should be
On Thursday, 21 November 2013 at 17:39:28 UTC, Andrei
Alexandrescu wrote:
On 11/21/13 8:48 AM, Steve Teale wrote:
Could 'with' be extended to cover enum names do you think?
Also a
supplementary question - does auto lock out some things like
this, are
there other examples?
Guess it could.
On Thursday, 21 November 2013 at 16:48:59 UTC, Steve Teale wrote:
Could 'with' be extended to cover enum names do you think? Also
a supplementary question - does auto lock out some things like
this, are there other examples?
Is this what you mean?
enum Intention
{
EVIL,
On 11/21/13 8:48 AM, Steve Teale wrote:
Could 'with' be extended to cover enum names do you think? Also a
supplementary question - does auto lock out some things like this, are
there other examples?
Guess it could. One other thing we could do is to make enum namespaces
behave like imports.
On Thursday, 21 November 2013 at 08:37:32 UTC, Craig Dillabaugh
wrote:
Yes, perhaps that was his intention (no pun intended). First few
times I used enums in D I was caught because I expected the
behavior he is suggesting here would work.
Pun was intended ;=)
On Thursday, 21 November 2013 at 18:44:39 UTC, Steve Teale wrote:
On Thursday, 21 November 2013 at 17:39:28 UTC, Andrei
Alexandrescu wrote:
On 11/21/13 8:48 AM, Steve Teale wrote:
Could 'with' be extended to cover enum names do you think?
Also a
supplementary question - does auto lock out some
On 11/21/2013 02:20 PM, monarch_dodra wrote:
When you import from a module, you only need to specify the module name
if there is ambiguity. So for example:
//
import std.array;
void main()
{
split(hello); //OK!
}
//
import std.array;
import std.algorithm;
void main()
{
BOOM! Code no longer compiles.
As a rule, the code that compiles and works should preserve
its behavior when new code is added, so this is prohibited.
Also please post to D.learn
forgot to add:
void foo(OtherIntention rth) { ... }
Which of the two is being called by main?
I thought
On 11/21/2013 02:20 PM, monarch_dodra wrote:
When you import from a module, you only need to specify the module name
if there is ambiguity. So for example:
//
import std.array;
void main()
{
split(hello); //OK!
}
//
import std.array;
import std.algorithm;
void main()
{
On Thursday, 21 November 2013 at 17:39:28 UTC, Andrei
Alexandrescu wrote:
On 11/21/13 8:48 AM, Steve Teale wrote:
Could 'with' be extended to cover enum names do you think?
Also a
supplementary question - does auto lock out some things like
this, are
there other examples?
Guess it could.
That should be:
if( rth == Intention.EVIL ) and
foo( Intention.EVIL );
Phobos is less picky than the compiler. Try this:
import std.stdio;
enum Intention
{
EVIL,
NEUTRAL,
GOOD,
SAINTLY
}
void foo(Intention rth)
{
if (rth == Intention.EVIL)
writefln(The road to hell is
On 11/21/2013 01:36 PM, Steve Teale wrote:
I thought that compilers were supposed to help you if you did ambiguous
things. An interesting example is:
int bar(int n)
{
return n+1;
}
int bar(int n)
{
return n+2;
}
void main()
{
int v = 22;
int n = bar(22);
}
Compiler helps
On Thursday, 21 November 2013 at 17:19:18 UTC, inout wrote:
On Thursday, 21 November 2013 at 07:22:39 UTC, Steve Teale
wrote:
import std.stdio;
enum Intention
{
EVIL,
NEUTRAL,
GOOD,
SAINTLY
}
void foo(Intention rth)
{
if (rth == EVIL)
writeln(Road to hell);
}
void main()
{
On Thursday, 21 November 2013 at 07:22:39 UTC, Steve Teale wrote:
import std.stdio;
enum Intention
{
EVIL,
NEUTRAL,
GOOD,
SAINTLY
}
void foo(Intention rth)
{
if (rth == EVIL)
writeln(Road to hell);
}
void main()
{
foo(EVIL);
}
Why does the compiler complain in both
On Thursday, 21 November 2013 at 08:05:03 UTC, Michal Minich
wrote:
On Thursday, 21 November 2013 at 07:42:48 UTC, Craig Dillabaugh
wrote:
I should also mention, this post likely better belongs in:
digitalmars.D.learn
I don't entirely think so. I think the OP is arguing that D
should be
On Friday, 22 November 2013 at 00:50:25 UTC, John J wrote:
On 11/21/2013 02:20 PM, monarch_dodra wrote:
When you import from a module, you only need to specify the
module name
if there is ambiguity. So for example:
//
import std.array;
void main()
{
split(hello); //OK!
}
//
import std.stdio;
enum Intention
{
EVIL,
NEUTRAL,
GOOD,
SAINTLY
}
void foo(Intention rth)
{
if (rth == EVIL)
writeln(Road to hell);
}
void main()
{
foo(EVIL);
}
Why does the compiler complain in both places about EVIL. Can it
not work out which EVIL I mean? There's
On Thursday, 21 November 2013 at 07:22:39 UTC, Steve Teale wrote:
import std.stdio;
enum Intention
{
EVIL,
NEUTRAL,
GOOD,
SAINTLY
}
void foo(Intention rth)
{
if (rth == EVIL)
writeln(Road to hell);
}
void main()
{
foo(EVIL);
}
Why does the compiler complain in both
On Thursday, 21 November 2013 at 07:28:14 UTC, Craig Dillabaugh
wrote:
On Thursday, 21 November 2013 at 07:22:39 UTC, Steve Teale
wrote:
clip
Why does the compiler complain in both places about EVIL. Can
it not work out which EVIL I mean? There's only one choice.
That should be:
if( rth
Deep and darkness slumber, endless sleep...
nothing moves inside my funeral suite.
I feel the sun slip down, as hunger strikes,
waking like being born here comes the night!
All my senses awakened, by little demons,
taste the human heartbeat... bittersweet.
(bittersweet)
Can anyone explain this restriction to me?
Trying to extern to a C++ class.
// mirror the C++ vtable
extern (C++) interface IVirtuals
{
void virtualMethod();
}
// create a struct to pose as the C++ class
struct Test
{
// make the virtuals accessible with 'static this'
@property IVirtuals
On 01/27/2013 12:23 AM, Simen Kjaeraas wrote:
On 2013-23-26 20:01, Timon Gehr timon.g...@gmx.ch wrote:
On 01/26/2013 03:41 PM, Simen Kjaeraas wrote:
While the storm raged, I decided to try implementing properties as
library types. I encountered a few obstacles, which I will outline here.
On 2013-49-27 09:01, Timon Gehr timon.g...@gmx.ch wrote:
On 01/27/2013 12:23 AM, Simen Kjaeraas wrote:
On 2013-23-26 20:01, Timon Gehr timon.g...@gmx.ch wrote:
On 01/26/2013 03:41 PM, Simen Kjaeraas wrote:
While the storm raged, I decided to try implementing properties as
library types. I
While the storm raged, I decided to try implementing properties as library
types. I encountered a few obstacles, which I will outline here.
First, my intended syntax:
class A {
int _n;
Property!(
() = _n,
value = _n = value
) n;
}
Property would then be a struct,
Reason why library properties are not that usable is simple:
typeof(A._n) must be same as typeof(A.n) or this is not really a
property. Please take a look at examples and arguments in wiki:
http://wiki.dlang.org/Property_Discussion_Wrap-up
On Saturday, 26 January 2013 at 14:41:43 UTC, Simen Kjaeraas
wrote:
Now, the obstacle here is I can't refer to _n in those lambdas.
Why not? I'm guessing the struct has no context member, and the
lambdas don't because the class is not yet instantiated. Could
this be fixed? I think so, and I
On 01/26/2013 03:41 PM, Simen Kjaeraas wrote:
While the storm raged, I decided to try implementing properties as
library types. I encountered a few obstacles, which I will outline here.
First, my intended syntax:
class A {
int _n;
mixin Property!(
() = _n,
value
On 2013-23-26 20:01, Timon Gehr timon.g...@gmx.ch wrote:
On 01/26/2013 03:41 PM, Simen Kjaeraas wrote:
While the storm raged, I decided to try implementing properties as
library types. I encountered a few obstacles, which I will outline here.
First, my intended syntax:
class A {
int
Hi folks,
I just wanted to share a minor pet peeve I have with the list (and with
Usenet in general). There's a bad habit here of taking discussions off
on (worthwhile) tangents, but not amending the Subject line to reflect
the new topic.
For example, there's an enormous discussion on Andrei's
the Subject line to reflect
the new topic.
For example, there's an enormous discussion on Andrei's Google Talk
which is really about DDoc and Doxygen. It has totally left the Google
Talk building, and deserves a revised subject.
The Subject line is our friend, use it well! :)
Good point, I'll try
On 06/06/10 13:40, new to d wrote:
After reading on this newsgroup about the use of D with cgi i've
tried it on my host. Even a simple hello world program gives me
internal server error while equivalent c program compiled with gcc
works fine. Does any one here have any idea what the problem
Robert Clipsham Wrote:
On 06/06/10 14:00, new to d wrote:
It's a typical hello world program:
import std.stdio;
void main(string[] args) { writeln(Hello world!); }
I also tried using printf instead of writeln. I'm compiling it with
dmd test.d. I'm using dmd v2.046. I'm compiling
new to d Wrote:
Robert Clipsham Wrote:
On 06/06/10 14:00, new to d wrote:
It's a typical hello world program:
import std.stdio;
void main(string[] args) { writeln(Hello world!); }
I also tried using printf instead of writeln. I'm compiling it with
dmd test.d. I'm
Michal Minich wrote:
On Sun, 06 Jun 2010 09:00:25 -0400, new to d wrote:
import std.stdio;
void main(string[] args)
{
writeln(Hello world!);
}
Just a guess, but maybe the difference of your C and D programs is in
return value, which can be differently interpreted by CGI host. try
Jussi Jumppanen a écrit :
Vincent Richomme Wrote:
I would like to know if there are some parsers/scripts that could parse
some C/C++ language and that could insert printf in each function.
One option would be to use a regular expression within a search
and replace.
Just as a simple test I
Vincent Richomme wrote:
Hi,
sorry to ask my question here but since people are motivated by new
language, source code, ... I thought it was a good place to ask my
question about source code analysis.
I would like to know if there are some parsers/scripts that could parse
some C/C++ language
79 matches
Mail list logo
