On Thu, 2005-05-26 at 19:25 -0700, Kris wrote:
> "Chris Sauls" <ibisbasenji@gmail.com> wrote in message news:d75vht$hkv$2@digitaldaemon.com...
> > Carlos Santander wrote:
> > > I'm part of the camp that thinks that std.c.stdio is C and not D, so
> > > when I do things like that I use std.stream. Weird thing is that I
> > > prefer writef() over stdout.writef() ... Hehe...
> >
> > I admit to often being naughty and adding an "alias stdout.writef writef;" to the tops of my modules that use std.stream...  I'm probably just making a confusion trap for anyone else who reads that code, but it saves me ty ping "stdout" a thousand times in debug-console-logging code.
> >
> > -- Chris Sauls
> 
> 
> I configure the editor to insert common "phrases" based upon characters typed thus far (like intellisense), using a version of Emacs. I imagine you could do something similar with other editors, such as binding some text to a function-key?
> 
> Short names, combined with a lack of namespace isolation, often makes code quite a bit harder to maintain over time. But, just recently I've started to realize that the percentage of code with a lifespan of more than a semester has been dropping at an increasing rate. Might the whole "long-term maintenance" thing actually be a sinking ship?
> 
> 
> 

Perhaps, but the day you start believing that and drop your good coding habits, is the day your code will start lasting 10+ years! <g>

John Demme

On Thu, 26 May 2005 19:25:15 -0700, Kris wrote:


[snip]

> Short names, combined with a lack of namespace isolation, often makes code quite a bit harder to maintain over time. But, just recently I've started to realize that the percentage of code with a lifespan of more than a semester has been dropping at an increasing rate. Might the whole "long-term maintenance" thing actually be a sinking ship?

No!

Wait till you are being paid to write code and then explain your code to somebody else who has to maintain it. One can *never* write code that is too clear or over supported by good practices.

-- 
Derek
Melbourne, Australia
27/05/2005 12:44:07 PM

"Derek Parnell" <derek@psych.ward> wrote in message news:1equswhmhxo0t$.lq37ul35nfcj$.dlg@40tude.net...
> On Thu, 26 May 2005 21:50:57 -0400, Ben Hinkle wrote:
>
> [snip]
>> ... Actually I typically use printf since it is in object.d so I
>> don't have to import anything and it handles pointers better than writef
>> (when I'm debugging and I have an object x and I want to print the
>> address
>> of x I can't use writef - very annoying).
>
>  writefln("Address of object is %08X", &x);

doesn't that print the address of the variable holding the reference to the
object? I'm looking for the equivalent to
  printf("%p\n",x);

On Thu, 26 May 2005 23:13:25 -0400, Ben Hinkle wrote:

> "Derek Parnell" <derek@psych.ward> wrote in message news:1equswhmhxo0t$.lq37ul35nfcj$.dlg@40tude.net...
>> On Thu, 26 May 2005 21:50:57 -0400, Ben Hinkle wrote:
>>
>> [snip]
>>> ... Actually I typically use printf since it is in object.d so I
>>> don't have to import anything and it handles pointers better than writef
>>> (when I'm debugging and I have an object x and I want to print the
>>> address
>>> of x I can't use writef - very annoying).
>>
>>  writefln("Address of object is %08X", &x);
> 
> doesn't that print the address of the variable holding the reference to the
> object? I'm looking for the equivalent to
>   printf("%p\n",x);

You're correct. I misunderstood your 'request'.

By the way, what would you do with the address of the object anyway?

This might work for you ...

<code>

import std.stdio;
class Foo { int a;}
class Bar { real a;}
class Muc { char[200] a;}

// Returns the address of an object.
size_t ObjAddr( Object x )
{
    return cast(size_t) *(cast(size_t*)&x);
}

void main()
{
    Bar qwe = new Bar;
    Muc rty = new Muc;
    Foo uio = new Foo;

    writefln("%X %X %X", &qwe, ObjAddr(qwe), &qwe.a);
    writefln("%X %X %X", &rty, ObjAddr(rty), &rty.a);
    writefln("%X %X %X", &uio, ObjAddr(uio), &uio.a);

}

</code>

-- 
Derek
Melbourne, Australia
27/05/2005 2:04:09 PM

In article <d760ec$jll$1@digitaldaemon.com>, Kris says...
>
>Short names, combined with a lack of namespace isolation, often makes code quite a bit harder to maintain over time. But, just recently I've started to realize that the percentage of code with a lifespan of more than a semester has been dropping at an increasing rate. Might the whole "long-term maintenance" thing actually be a sinking ship?

That would be an interesting thing to find out.  It's always been the case that programs are used for far longer than the designers had ever planned, but it wasn't until recently that the platforms applications are built on began to change rapidly.  Has the browser as a platform given rise to disposable code, or will companies continue to use systems until they are years (or decades) out of date?


Sean

"Sean Kelly" <sean@f4.ca> wrote in message news:d76833$qrc$1@digitaldaemon.com...
> In article <d760ec$jll$1@digitaldaemon.com>, Kris says...
> >
> >Short names, combined with a lack of namespace isolation, often makes
code
> >quite a bit harder to maintain over time. But, just recently I've started
to
> >realize that the percentage of code with a lifespan of more than a
semester
> >has been dropping at an increasing rate. Might the whole "long-term maintenance" thing actually be a sinking ship?
>
> That would be an interesting thing to find out.  It's always been the case
that
> programs are used for far longer than the designers had ever planned, but
it
> wasn't until recently that the platforms applications are built on began
to
> change rapidly.  Has the browser as a platform given rise to disposable
code, or
> will companies continue to use systems until they are years (or decades)
out of
> date?

Yes; interesting indeed. For example, I know of one /giant/ electronics manufacturer (I imagine almost everyone owns something made by them) who hire developers on a project by project basis only. There are no in-house developers, therefore all internal knowledge of the code effectively dies when the product ships. My understanding is that it's more cost-effective overall for them to recreate than to maintain; but then the product itself has a limited lifespan anyway. Disposable code for a disposable society <g>

Being the old-fart that I am, that concept almost blew my mind through my nostrils.

Kris wrote:
> "Sean Kelly" <sean@f4.ca> wrote in message
> news:d76833$qrc$1@digitaldaemon.com...
> 
>>In article <d760ec$jll$1@digitaldaemon.com>, Kris says...
>>
>>>Short names, combined with a lack of namespace isolation, often makes
> 
> code
> 
>>>quite a bit harder to maintain over time. But, just recently I've started
> 
> to
> 
>>>realize that the percentage of code with a lifespan of more than a
> 
> semester
> 
>>>has been dropping at an increasing rate. Might the whole "long-term
>>>maintenance" thing actually be a sinking ship?
>>
>>That would be an interesting thing to find out.  It's always been the case
> 
> that
> 
>>programs are used for far longer than the designers had ever planned, but
> 
> it
> 
>>wasn't until recently that the platforms applications are built on began
> 
> to
> 
>>change rapidly.  Has the browser as a platform given rise to disposable
> 
> code, or
> 
>>will companies continue to use systems until they are years (or decades)
> 
> out of
> 
>>date?
> 
> 
> Yes; interesting indeed. For example, I know of one /giant/ electronics
> manufacturer (I imagine almost everyone owns something made by them) who
> hire developers on a project by project basis only. There are no in-house
> developers, therefore all internal knowledge of the code effectively dies
> when the product ships. My understanding is that it's more cost-effective
> overall for them to recreate than to maintain; but then the product itself
> has a limited lifespan anyway. Disposable code for a disposable society <g>
> 
> Being the old-fart that I am, that concept almost blew my mind through my
> nostrils.
> 
> 

Sounds like Philips.

"Derek Parnell" <derek@psych.ward> wrote in message news:1v7b3qw0dppoz.iv4epes53a68.dlg@40tude.net...
> On Thu, 26 May 2005 23:13:25 -0400, Ben Hinkle wrote:
>
>> "Derek Parnell" <derek@psych.ward> wrote in message news:1equswhmhxo0t$.lq37ul35nfcj$.dlg@40tude.net...
>>> On Thu, 26 May 2005 21:50:57 -0400, Ben Hinkle wrote:
>>>
>>> [snip]
>>>> ... Actually I typically use printf since it is in object.d so I
>>>> don't have to import anything and it handles pointers better than
>>>> writef
>>>> (when I'm debugging and I have an object x and I want to print the
>>>> address
>>>> of x I can't use writef - very annoying).
>>>
>>>  writefln("Address of object is %08X", &x);
>>
>> doesn't that print the address of the variable holding the reference to
>> the
>> object? I'm looking for the equivalent to
>>   printf("%p\n",x);
>
> You're correct. I misunderstood your 'request'.
>
> By the way, what would you do with the address of the object anyway?

without a debugger there's no other way to see what reference is stored in a variable. I'm curious how people debug code involving objects otherwise since I find myself quite often wondering just which variable refers to which object.

In article <1qg5mxr25hl82$.1x1w1jaflnwy5.dlg@40tude.net>, Derek Parnell says...
>
>Wait till you are being paid to write code and then explain your code to somebody else who has to maintain it. One can *never* write code that is too clear or over supported by good practices.

Some contractors working at an old job of mine admitted to me that they designed complexity into their code to assure continued business with the client (and long hours for even the simplest change).  I had a look at a Monte Carlo app they wrote at one point and it was the most horrifying bit of code I've ever seen.  Between things like this and the mistakes of inexperience, I wonder just how much code out there is actually less cost-effective to maintain than to rewrite from scratch.


Sean