Thu, 14 Oct 2010 17:21:39 +0200, Andrej Mitrovic wrote:
> Don't forget pragma abuse! I don't have the exact source, but I've seen
> code like this in several medium-big sized projects:
>
> // Shut up stupid compiler warnings
> #pragma (DISABLE, 5596)
> #pragma (DISABLE, 5597)
> #pragma (DISABLE,
On 10/2/10, retard wrote:
> Thu, 30 Sep 2010 21:12:53 -0400, bearophile wrote:
>
>> Here (pdf alert) I have found a very simple but interesting paper that
>> has confirmed an hypothesis of mine.
>>
>> This is a page that contains a pdf that shows a short introduction to
>> the paper: http://www.ga
retard wrote:
Some languages prevent this bug by making the parameters immutable in
some sense (at least shallow immutability). It's even possible in Java,
and in one place I worked previously "final params by default" was one of
the rules in code review and style guides.
this(const int x, co
Fri, 01 Oct 2010 12:38:26 +0200, Simen kjaeraas wrote:
> Daniel Gibson wrote:
>
>> this(int this.x, int this.y, int a)
>
> Me likes.
Looks almost like Scala:
class MyClass(var x: Int, var y: Int, a: Int) {
...
}
On 01/10/2010 02:12, bearophile wrote:
Researchers at Stanford have just released a paper detailing their use of
automated tools
to look for redundant code in 1.6 million lines of Linux. "Redundant" is
defined as:
- Idempotent operations (like assigning a variable to itself)
Idempotent ope
Thu, 30 Sep 2010 21:12:53 -0400, bearophile wrote:
> Here (pdf alert) I have found a very simple but interesting paper that
> has confirmed an hypothesis of mine.
>
> This is a page that contains a pdf that shows a short introduction to
> the paper: http://www.ganssle.com/tem/tem80.htm
>
> This
> // Code #2
> struct Something {
> int x, y, aa;
> this(this.x, this.y, int a_) {
> this.aa = a_ * a_ + x;
> }
> void update(this.x) {
> this.aa += b;
> }
> }
Sorry, that's wrong. The correct part:
void update(this.x, int b) {
this.aa += b;
}
bearophile wrote:
but it can't avoid bugs like the following inc(), so I think it's not
enough to solve the problems I was talking about:
// Code #5
class Foo {
int x;
void inc(int x) { x += x; }
}
void main() {}
Oh, but it can (sort of). By allowing this syntax, there is *very* l
Thank you for all the answers.
Daniel Gibson:
> Well, maybe "this(int this.x, int this.y, int a)" would be better.
This reduces useless code in the constructor and keep the code more DRY, looks
able to avoid part of the problems I was talking about (but not all of them).
So this struct:
//
On 2/10/2010 1:52 AM, Justin Johansson wrote:
Whoops, bug in my reply.
ZIP as "zero intolerance for plagiarism" is obviously
what I did not mean. I meant "zero tolerance"
rather than "zero intolerance" but then the acronym
ZTP does not sound so good, :-(
On 1/10/2010 11:12 AM, bearophile wrote:
Here (pdf alert) I have found a very simple but interesting paper that has
confirmed an hypothesis of mine.
So far most respondents have gone completely off-subject here.
In hardware systems redundancy is critical for safety. In software
systems redun
"Peter Alexander" wrote in message
news:i843rl$1gr...@digitalmars.com...
>> I dont know if it is, but IMO it really should be an error to declare
>> local
>> variables that hide member variables.
>
> I disagree. I always do that in constructors:
>
> int x, y;
> this(int x, int y)
> {
> this.x
Daniel Gibson wrote:
this(int this.x, int this.y, int a)
Me likes.
--
Simen
On Fri, Oct 1, 2010 at 9:50 AM, Peter Alexander
wrote:
>> I dont know if it is, but IMO it really should be an error to declare local
>> variables that hide member variables.
>
> I disagree. I always do that in constructors:
>
> int x, y;
> this(int x, int y)
> {
> this.x = x;
> this.y = y;
> }
> I dont know if it is, but IMO it really should be an error to declare local
> variables that hide member variables.
I disagree. I always do that in constructors:
int x, y;
this(int x, int y)
{
this.x = x;
this.y = y;
}
I think you would annoy a lot of people if it was forbidden.
"bearophile" wrote in message
news:i83cil$2o0...@digitalmars.com...
>
> situations like x=x; reveal true bugs like:
>
> class Foo {
>int x, y;
>this(int x_, int y_) {
>this.x = x;
>y = y;
>
>}
> }
I get hit much more often by somthing like this
class Foo {
in
On Thursday 30 September 2010 23:33:26 Kagamin wrote:
> bearophile Wrote:
> > errors will be found
> > often hide bugs
> >
> > situations like x=x; reveal true bugs like:
> >
> > class Foo {
> >
> > int x, y;
> > this(int x_, int y_) {
> >
> > this.x = x;
> > y = y;
bearophile Wrote:
> errors will be found
> often hide bugs
> situations like x=x; reveal true bugs like:
>
> class Foo {
> int x, y;
> this(int x_, int y_) {
> this.x = x;
> y = y;
>
> }
> }
> void main() {}
Yes, fields and locals in camelCase is a bug.
Here (pdf alert) I have found a very simple but interesting paper that has
confirmed an hypothesis of mine.
This is a page that contains a pdf that shows a short introduction to the paper:
http://www.ganssle.com/tem/tem80.htm
This is the paper, "Using Redundancies to Find Errors", by Yichen Xie
19 matches
Mail list logo
