On Sat, 20 Aug 2011 01:42:56 +0100, Stewart Gordon wrote:
> So essentially you're looking to catch cases where, if you consider the
> function as a flow chart, there is no chain of arrows from the start of
> the function to the statement in question. That should be
> straightforward. But you're
"Marco Leise" wrote in message
news:op.v0f018nh9y6...@dslb-088-070-152-209.pools.arcor-ip.net...
>
>"By not adopting a technology capable of competing with native apps on
iOS, Android, Windows, and Mac, web vendors are preventing important
classes of applications such as high-end games and simula
nsf:
> Well, D currently says I can't shadow variables:
Right, that's a third way to shadow variables that D forbids, thank you. But in
my post I've shown other kinds of shadowing that currently D accepts. Shadowing
global variables has caused some problems in my C code. One good commercial C
On Fri, 19 Aug 2011 11:07:12 -0400
bearophile wrote:
> Some ways to face this problem:
>
> 1) Do nothing.
> 2) Give optional explicit information about the source of all variable names
> used in a function, using the optional @outer() I have proposed elsewhere.
> 3) Statically disallow (gives a
I've massively improved my RegionAllocator (formerly TempAlloc) module thanks
to the excellent suggestions from Andrei and from Dimitri Olshansky (the GSoC
student working on regexes).
For the curious:
http://cis.jhu.edu/~dsimcha/d/phobos/std_regionallocator.html
https://github.com/dsimcha/TempAl
On 8/19/2011 8:29 AM, Timon Gehr wrote:
On 08/19/2011 05:12 PM, Andrei Alexandrescu wrote:
On 8/19/11 1:50 AM, Jacob Carlborg wrote:
This might sound like a crazy idea. I don't expect everyone to drop
what
they're doing and start to implement this, it's just an idea.
In Java (C, C++ and other
On 8/19/2011 8:17 AM, Andrej Mitrovic wrote:
It's not just globals. It's hiding fields as well:
class A
{
int x;
this()
{
int x; //<- hides this.x
}
}
I've had this happen during a cut/paste session, which happens when
I'm refactoring my code.
I actually use this o
On 18/08/2011 13:19, Bernard Helyer wrote:
I'm talking about the unambiguous cases, the ones where a basic block has
no parents (i.e. there is no way to enter that code block).
So essentially you're looking to catch cases where, if you consider the function as a flow
chart, there is no chain
On Friday, August 19, 2011 15:27 Timon Gehr wrote:
> On 08/19/2011 10:36 PM, Jonathan M Davis wrote:
> > On Friday, August 19, 2011 04:58 Timon Gehr wrote:
> >> On 08/19/2011 01:50 AM, Jonathan M Davis wrote:
> >>> On Thursday, August 18, 2011 16:00 Timon Gehr wrote:
> On 08/19/2011 12:35 AM,
On 08/19/2011 02:51 PM, filgood wrote:
Yes, I've also had the same error in the last few days...maybe we can
have a mirror (that is sync'd regularly)?
~filgood
It's available through Gmane:
nntp://news.gmane.org/gmane.comp.lang.d.general
On 08/19/2011 10:36 PM, Jonathan M Davis wrote:
On Friday, August 19, 2011 04:58 Timon Gehr wrote:
On 08/19/2011 01:50 AM, Jonathan M Davis wrote:
On Thursday, August 18, 2011 16:00 Timon Gehr wrote:
On 08/19/2011 12:35 AM, Jonathan M Davis wrote:
On Thursday, August 18, 2011 14:33 jdrewsen w
On Friday, August 19, 2011 04:58 Timon Gehr wrote:
> On 08/19/2011 01:50 AM, Jonathan M Davis wrote:
> > On Thursday, August 18, 2011 16:00 Timon Gehr wrote:
> >> On 08/19/2011 12:35 AM, Jonathan M Davis wrote:
> >>> On Thursday, August 18, 2011 14:33 jdrewsen wrote:
> Den 17-08-2011 18:21, Ti
Den 18-08-2011 20:12, Martin Nowak skrev:
On Tue, 16 Aug 2011 13:48:57 +0200, Jonas Drewsen
wrote:
Hi all,
This is a review request for the curl wrapper. Please read the "known
issues" in the top of the source file and if possible suggest a solution.
We also need somebody for running the rev
Den 19-08-2011 00:55, Timon Gehr skrev:
On 08/18/2011 11:33 PM, jdrewsen wrote:
Den 17-08-2011 18:21, Timon Gehr skrev:
On 08/17/2011 05:58 PM, Jonathan M Davis wrote:
On Wednesday, August 17, 2011 11:30:06 Steven Schveighoffer wrote:
On Wed, 17 Aug 2011 11:05:56 -0400, jdrewsen
wrote:
Den 1
On Fri, 19 Aug 2011 15:18:34 -0400, Marco Leise wrote:
Am 19.08.2011, 17:15 Uhr, schrieb Stijn Herreman
:
On 19/08/2011 16:18, kennytm wrote:
Timon Gehr wrote:
On 08/19/2011 03:44 PM, Steven Schveighoffer wrote:
Has there been some strange issue with the newsgroup lately?
Frequently,
I
Am 19.08.2011, 17:15 Uhr, schrieb Stijn Herreman
:
On 19/08/2011 16:18, kennytm wrote:
Timon Gehr wrote:
On 08/19/2011 03:44 PM, Steven Schveighoffer wrote:
Has there been some strange issue with the newsgroup lately?
Frequently,
I'm getting load errors (I assume this means the NG load is
On 19/08/2011 14:44, Steven Schveighoffer wrote:
Has there been some strange issue with the newsgroup lately? Frequently,
I'm getting load errors (I assume this means the NG load is too large to
deal with my communication).
It seems to be happening daily...
-Steve
Yes, I've also had the same
On 2011-08-19 15:44, Steven Schveighoffer wrote:
Has there been some strange issue with the newsgroup lately? Frequently,
I'm getting load errors (I assume this means the NG load is too large to
deal with my communication).
It seems to be happening daily...
-Steve
I'm getting the same error.
On 2011-08-19 16:33, kennytm wrote:
Trass3r wrote:
Am 19.08.2011, 14:16 Uhr, schrieb Timon Gehr:
I think this makes code harder to read for no obvious benefit.
I don't think this is any better than
class Foo{
private int a_;
int a(){return a_;}
int a(int a){return a_ = a;}
}
On 2011-08-19 17:12, Andrei Alexandrescu wrote:
On 8/19/11 1:50 AM, Jacob Carlborg wrote:
This might sound like a crazy idea. I don't expect everyone to drop what
they're doing and start to implement this, it's just an idea.
In Java (C, C++ and others) braces are optional for statements like if
On Aug 18, 2011, at 10:29 AM, Nick Sabalausky wrote:
> "Bernard Helyer" wrote in message
> news:j2ithq$12kd$1...@digitalmars.com...
>> I asked the Ars forums ( http://arstechnica.com/civis/viewtopic.php?
>> f=20&t=1153378&p=21965411 ) and I ask the same of you: should
>> unambiguously unreachabl
Am 19.08.2011, 14:50 Uhr, schrieb Timon Gehr :
void foo(ref S);
...
foo(S(...));
is equivalent to one explicitly declaring the temporary:
{auto __temp=S(...); foo(__temp);}
The difference is that the first is more pleasant to write. If
temporaries would become rvalues everyone would always h
On 08/19/2011 05:12 PM, Andrei Alexandrescu wrote:
On 8/19/11 1:50 AM, Jacob Carlborg wrote:
This might sound like a crazy idea. I don't expect everyone to drop what
they're doing and start to implement this, it's just an idea.
In Java (C, C++ and others) braces are optional for statements like
Why not a warning but when compiling using the -release flag throw an error?
Sounds logical to me as unreachable code can be there because of
debugging,etc but any released executable should not contain unreachable
code.
2011/8/18 Don
> Timon Gehr wrote:
>
>> On 08/18/2011 02:38 PM, Bernard Hely
On 19/08/2011 16:18, kennytm wrote:
Timon Gehr wrote:
On 08/19/2011 03:44 PM, Steven Schveighoffer wrote:
Has there been some strange issue with the newsgroup lately? Frequently,
I'm getting load errors (I assume this means the NG load is too large to
deal with my communication).
It seems to
It's not just globals. It's hiding fields as well:
class A
{
int x;
this()
{
int x; // <- hides this.x
}
}
I've had this happen during a cut/paste session, which happens when
I'm refactoring my code.
On 8/19/11 1:50 AM, Jacob Carlborg wrote:
This might sound like a crazy idea. I don't expect everyone to drop what
they're doing and start to implement this, it's just an idea.
In Java (C, C++ and others) braces are optional for statements like if,
while, for and so on, containing only one expre
After translating some buggy C code (full of gotos and global variables) to D
and going hunting for bugs for some time, I have grown a desire to write this
post.
Variable name hiding is a source of bugs. A typical example:
int x;
void foo() {
int x = 5;
// lot of code code here
x++
On 08/19/2011 04:33 PM, kennytm wrote:
Timon Gehr wrote:
On 08/19/2011 03:46 PM, kennytm wrote:
Timon Gehr wrote:
auto ref currently treats struct literals as lvalues too. (therefore, as
ref). And passing by value would be considerably less efficient for large
structs.
As I understand it
Trass3r wrote:
> Am 19.08.2011, 14:16 Uhr, schrieb Timon Gehr :
>> I think this makes code harder to read for no obvious benefit.
>> I don't think this is any better than
>>
>> class Foo{
>> private int a_;
>> int a(){return a_;}
>> int a(int a){return a_ = a;}
>> }
>
> +1
>
> Op
Timon Gehr wrote:
> On 08/19/2011 03:46 PM, kennytm wrote:
>> Timon Gehr wrote:
>>
>>> auto ref currently treats struct literals as lvalues too. (therefore, as
>>> ref). And passing by value would be considerably less efficient for large
>>> structs.
>>>
>>> As I understand it, the only issue
Timon Gehr wrote:
> On 08/19/2011 03:44 PM, Steven Schveighoffer wrote:
>> Has there been some strange issue with the newsgroup lately? Frequently,
>> I'm getting load errors (I assume this means the NG load is too large to
>> deal with my communication).
>>
>> It seems to be happening daily...
>
On Fri, 19 Aug 2011 15:52:40 +0200, Timon Gehr wrote:
> On 08/19/2011 03:44 PM, Steven Schveighoffer wrote:
>> Has there been some strange issue with the newsgroup lately?
>> Frequently, I'm getting load errors (I assume this means the NG load is
>> too large to deal with my communication).
>>
>>
There is one case where it might make sense. I've brought up a
variation of this before, but basically;
Object getMeSome() try {
// Really try
} catch (SpecificFailure e) {
return null;
}
vs.
Object getMeSome() {
try {
// Really try
} catch (SpecificFailure e) {
return null;
}
2011/8/19 Timon Gehr :
> Oh, interesting. So why were they implemented with different semantics then?
I don't know the background, sorry.
> Also, how would they work in a non-templated function?
In my opinion, that might work like C++ const T&, that allows
receiving a rvalue argument.
> Would th
On 08/19/2011 03:46 PM, kennytm wrote:
Timon Gehr wrote:
auto ref currently treats struct literals as lvalues too. (therefore, as
ref). And passing by value would be considerably less efficient for large
structs.
As I understand it, the only issue with allowing literals and function
results
On 08/19/2011 03:44 PM, Steven Schveighoffer wrote:
Has there been some strange issue with the newsgroup lately? Frequently,
I'm getting load errors (I assume this means the NG load is too large to
deal with my communication).
It seems to be happening daily...
-Steve
It has been the same for
Timon Gehr wrote:
> auto ref currently treats struct literals as lvalues too. (therefore, as
> ref). And passing by value would be considerably less efficient for large
> structs.
>
> As I understand it, the only issue with allowing literals and function
> results as lvalues is that generic cod
Has there been some strange issue with the newsgroup lately? Frequently,
I'm getting load errors (I assume this means the NG load is too large to
deal with my communication).
It seems to be happening daily...
-Steve
On 08/19/2011 03:04 PM, kenji hara wrote:
2011/8/19 Timon Gehr:
On 08/19/2011 02:16 PM, Steven Schveighoffer wrote:
On Thu, 18 Aug 2011 18:56:01 -0400, bearophile
wrote:
Jonathan M Davis:
I see _zero_ reason to
treat a newly constructed object as any different from one which is
returned
2011/8/19 Timon Gehr :
> On 08/19/2011 02:16 PM, Steven Schveighoffer wrote:
>>
>> On Thu, 18 Aug 2011 18:56:01 -0400, bearophile
>> wrote:
>>
>>> Jonathan M Davis:
>>>
I see _zero_ reason to
treat a newly constructed object as any different from one which is
returned
from a fu
On 08/19/2011 02:16 PM, Steven Schveighoffer wrote:
On Thu, 18 Aug 2011 18:56:01 -0400, bearophile
wrote:
Jonathan M Davis:
I see _zero_ reason to
treat a newly constructed object as any different from one which is
returned
from a function.
I have not followed fully this thread, so I am no
bearophile wrote:
I'd like some optional functionality like SAFECode in the D compiler too.
Very little code in a D program needs to be @system, so I see little
need for this.
Am 19.08.2011, 14:16 Uhr, schrieb Timon Gehr :
I think this makes code harder to read for no obvious benefit.
I don't think this is any better than
class Foo{
private int a_;
int a(){return a_;}
int a(int a){return a_ = a;}
}
+1
Optional braces should be limited to statements.
On Thu, 18 Aug 2011 18:56:01 -0400, bearophile
wrote:
Jonathan M Davis:
I see _zero_ reason to
treat a newly constructed object as any different from one which is
returned
from a function.
I have not followed fully this thread, so I am not sure what you are
talking about, so sorry if
On 08/19/2011 08:50 AM, Jacob Carlborg wrote:
This might sound like a crazy idea. I don't expect everyone to drop what
they're doing and start to implement this, it's just an idea.
In Java (C, C++ and others) braces are optional for statements like if,
while, for and so on, containing only one e
On 08/19/2011 01:50 AM, Jonathan M Davis wrote:
On Thursday, August 18, 2011 16:00 Timon Gehr wrote:
On 08/19/2011 12:35 AM, Jonathan M Davis wrote:
On Thursday, August 18, 2011 14:33 jdrewsen wrote:
Den 17-08-2011 18:21, Timon Gehr skrev:
On 08/17/2011 05:58 PM, Jonathan M Davis wrote:
On W
Sorry guys for disappearing. I'll put some time into this...
On Wed, Aug 10, 2011 at 12:52 AM, Jonathan M Davis wrote:
> Jose, are you ready for std.log to be reviewed? I believe that it's the item
> which has been in the review queue the longest at this point. So, if you're
> ready, then it shou
48 matches
Mail list logo
