Channel 9 Forums - Tech Off - is 'new object().property' or 'new object().method()' a good idea?

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

ScanIAm — Mon, 03 Dec 2007 16:09:21 GMT

There is a completely different thread about a slightly tangential topic, but I'm noticing a number of pieces of example code that concerns me.

I've done this myself, but how 'safe' is it:

Console.WriteLine(new String("Bob").Length);

The part that concerns me is the accessing of the function 'Length' when you don't really know that the new String has actually been created.

The other side of the coin, however, is that you could end up with twice as many lines of code if you check every single variable before using it.

What do you do?

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

William Kempf — Mon, 03 Dec 2007 16:43:00 GMT

ScanIAm wrote:

There is a completely different thread about a slightly tangential topic, but I'm noticing a number of pieces of example code that concerns me.

I've done this myself, but how 'safe' is it:

Console.WriteLine(new String("Bob").Length);

The part that concerns me is the accessing of the function 'Length' when you don't really know that the new String has actually been created.

The other side of the coin, however, is that you could end up with twice as many lines of code if you check every single variable before using it.

What do you do?

First, your example is bad:

Console.WriteLine("Bob".Length);

However, the idea is there, so I'll address it. The new String will either be created, thus no problem, or an exception will be thrown and so Length won't be called, so also no problem. The only problems that exist here exist whether or not you "chain" the calls to the constructor.

Check the variable before using it? Like I said, either it worked, and so there's no reason to check, or it threw an exception, so there's no reason to check. I guess I don't get what you think the problem is?

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

evildictaitor — Mon, 03 Dec 2007 17:05:52 GMT

ScanIAm wrote:

There is a completely different thread about a slightly tangential topic, but I'm noticing a number of pieces of example code that concerns me.

I've done this myself, but how 'safe' is it:

Console.WriteLine(new String("Bob").Length);

The part that concerns me is the accessing of the function 'Length' when you don't really know that the new String has actually been created.

The other side of the coin, however, is that you could end up with twice as many lines of code if you check every single variable before using it.

What do you do?

In an unsafe language like C that is absolutely correct:

#include

int main(){
int len;
string b;

b = (string)malloc(sizeof(char) * 3);
strcpy(b, "Bob\0", 3);
len = strlen(b);
}

Should have checks in it:

int main(){
int len;
string b;

b = (string)malloc(sizeof(char) * 3);
assert(b != NULL);
strcpy(b, "Bob\0", 3);
len = strlen(b);
}

In case you run your system down to the point where it can't allocate 3 bytes for you (heaven forbid).

In a language like C#, however, new is a memory safe operation, since if the internal malloc fails a new OutOfMemoryException() is thrown at the il line where the newobj instruction is.

There is no T such that
new T( args ...) === null

however, the line new T(args ... ) can throw an OutOfMemoryException if there is not enough system memory to allocate T on the stack.

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

odujosh — Mon, 03 Dec 2007 17:37:33 GMT

I think the whole topic is splitting hairs in managed code. C or C++ I can see worrying. When you hard coding the string like you suggest I see no problem not testing for IsEmptyOrNull as you will always get the same result. In random input scenarios like reading in from file, form etc I would always test for invalid input before you commit it to anything non trivial.

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

Curt Nichols — Mon, 03 Dec 2007 20:21:18 GMT

ScanIAm wrote:

I've done this myself, but how 'safe' is it:

Console.WriteLine(new String("Bob").Length);

The part that concerns me is the accessing of the function 'Length' when you don't really know that the new String has actually been created.

You absolutely know that the new String has been created before Length is called. An exception will be thrown if the String could not be created.

[Edge case ahead.]

Now, in the case of

new MyObject().LongRunningMethod();

the instance of MyObject may be garbage collected before LongRunningMethod returns. This usually doesn't cause a problem, but it can; to cause a problem usually involves a questionable design decision (e.g., a disposed MyObject cleans up a field, and this happens to occur after LongRunningMethod's last reference to your MyObject instance but before using a locally stored reference to that field). I can make it happen but I don't expect to see it in the wild.

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

evildictaitor — Mon, 03 Dec 2007 20:48:55 GMT

Curt Nichols wrote:

ScanIAm wrote:

I've done this myself, but how 'safe' is it:

Console.WriteLine(new String("Bob").Length);

The part that concerns me is the accessing of the function 'Length' when you don't really know that the new String has actually been created.

You absolutely know that the new String has been created before Length is called. An exception will be thrown if the String could not be created.

[Edge case ahead.]

Now, in the case of

new MyObject().LongRunningMethod();
the instance of MyObject may be garbage collected before LongRunningMethod returns. This usually doesn't cause a problem, but it can; to cause a problem usually involves a questionable design decision (e.g., a disposed MyObject cleans up a field, and this happens to occur after LongRunningMethod's last reference to your MyObject instance but before using a locally stored reference to that field). I can make it happen but I don't expect to see it in the wild.

This is interesting, and would be a bug in the CLR.

You won't be able to test for it either since

1: MyObject o = new MyObject();
2: if(null == o)
3: throw new Exception();
4: var result = o.LongRunningMethod();

If what you say is correct then lines 2 and 3 are superflouous since o could be garbage collected between 2,3 and 4.

To protect against it you could do

MyObject o = new MyObject();
var result = o.LongRunningMethod();
GC.KeepAlive(o);

But in fairness this is a bug that should be fixed by Microsoft rather than coded around, and you should write an bugreport if you find in your code that this is happening.

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

ScanIAm — Mon, 03 Dec 2007 21:56:40 GMT

wkempf wrote:

ScanIAm wrote:

There is a completely different thread about a slightly tangential topic, but I'm noticing a number of pieces of example code that concerns me.

I've done this myself, but how 'safe' is it:

Console.WriteLine(new String("Bob").Length);

The part that concerns me is the accessing of the function 'Length' when you don't really know that the new String has actually been created.

The other side of the coin, however, is that you could end up with twice as many lines of code if you check every single variable before using it.

What do you do?

First, your example is bad:

Console.WriteLine("Bob".Length);

However, the idea is there, so I'll address it. The new String will either be created, thus no problem, or an exception will be thrown and so Length won't be called, so also no problem. The only problems that exist here exist whether or not you "chain" the calls to the constructor.

Check the variable before using it? Like I said, either it worked, and so there's no reason to check, or it threw an exception, so there's no reason to check. I guess I don't get what you think the problem is?

Yep, that's what I get for not actually compiling the code and testing it, but it was meant as an example.

I've seen this used, more often, when adding ListItem to a radiobutton/combobox/dropdownlist.

I guess, for me, the fear of using this construct comes from C/C++ training.

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

AndyC — Mon, 03 Dec 2007 22:26:17 GMT

evildictaitor wrote:

Should have checks in it:

int main(){
int len;
string b;

b = (string)malloc(sizeof(char) * 3);
assert(b != NULL);
strcpy(b, "Bob\0", 3);
len = strlen(b);
}

assert really doesn't count as a check, since it is only functional during debugging sessions. For runtime checks you really should use a proper if else construct.

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

evildictaitor — Mon, 03 Dec 2007 22:53:17 GMT

AndyC wrote:

evildictaitor wrote:

Should have checks in it:

int main(){
int len;
string b;

b = (string)malloc(sizeof(char) * 3);
assert(b != NULL);
strcpy(b, "Bob\0", 3);
len = strlen(b);
}

assert really doesn't count as a check, since it is only functional during debugging sessions. For runtime checks you really should use a proper if else construct.

Well if we're being fussy we can go into propagating error results or implementing the C Exception library, but I was just trying to get my point across, not write release code

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

Christian Liensberger — Mon, 03 Dec 2007 22:59:22 GMT

Curt Nichols wrote:

ScanIAm wrote:

I've done this myself, but how 'safe' is it:

Console.WriteLine(new String("Bob").Length);

The part that concerns me is the accessing of the function 'Length' when you don't really know that the new String has actually been created.

You absolutely know that the new String has been created before Length is called. An exception will be thrown if the String could not be created.

[Edge case ahead.]

Now, in the case of

new MyObject().LongRunningMethod();
the instance of MyObject may be garbage collected before LongRunningMethod returns. This usually doesn't cause a problem, but it can; to cause a problem usually involves a questionable design decision (e.g., a disposed MyObject cleans up a field, and this happens to occur after LongRunningMethod's last reference to your MyObject instance but before using a locally stored reference to that field). I can make it happen but I don't expect to see it in the wild.

The MyObject instance won't be collected by the GC if you are accessing any fields that held by that instance... otherwise - as said - it would be a heavy CLR (GC) bug!

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

Sven Groot — Mon, 03 Dec 2007 23:51:53 GMT

ScanIAm wrote:

Console.WriteLine(new String("Bob").Length);

The part that concerns me is the accessing of the function 'Length' when you don't really know that the new String has actually been created.

Ignoring that String is a bad example because you can do "Bob".Length (as was mentioned), I still don't see what you're getting at.

What is it you want to check? Any error conditions that cause the object not to be created would throw an exception.

Code like what evildictaitor wrote:
MyObject o = new MyObject();
if( o == null )
throw new Exception();

That's completely pointless. O can never be null after a "new", since if the object couldn't be created an exception would be thrown (e.g. an OutOfMemoryException).

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

William Stacey — Tue, 04 Dec 2007 02:28:22 GMT

I ~think what your asking is if that var gets collected correctly as it is an internal assignment. That is interesting as I recall a c# ng thread circa 2.0 that someone showed that is was never collected even after some GCs. I personally did not test or repro the issue, but IIRC, others could repo the issue. Me thinks it was fixed, but not sure. Save that issue, I don't see a problem other then it would be easier to debug if ctor and assignment was on a line by itself and maybe more clear.

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

DinoViehland — Tue, 04 Dec 2007 03:28:33 GMT

littleguru wrote:

The MyObject instance won't be collected by the GC if you are accessing any fields that held by that instance... otherwise - as said - it would be a heavy CLR (GC) bug!

Just to shed a little light on the situation the typical example of this is using IntPtr's and the Dispose pattern. Such as:

class MyDisposable : IDisposable {
    private IntPtr _foo;
    public void DoIt() {
        SomePInvokeOperation(_foo);
    }

    ~MyDisposable() {
        Dispose();
    }
    public void Dispose() {
        CloseMyHandle(_foo);
        GC.SuppressFinalization(this);
    }
}

Now you do: new MyDisposable().DoIt(); The IntPtr is read and right after that read there are no longer any references to the MyDisposable() instance. Before SomePInvokeOperation can run the GC kicks in and collects the MyDisposable class. Next the finalizer thread runs which runs the finalizer which closes the native resource. Finally your SomePInvokeOperation runs and is operating on a _foo that is no longer valid.

The worst case scenario here is that you can use this for a handle recycling attack which violates security. If you're lucky the app is just going to crash. Anyway, the way to fix this is to put a GC.KeepAlive(this); in DoIt() so that the object survives the lifetime of the call. But it's really only a problem when you're interacting with native resources which the GC doesn't understand and keep alive its self. So still not a bug, but a good thing to know about if you're doing any interop programming.

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

Pop Catalin — Tue, 04 Dec 2007 11:19:41 GMT

Curt Nichols wrote:

...

[Edge case ahead.]

Now, in the case of

new MyObject().LongRunningMethod();
the instance of MyObject may be garbage collected before LongRunningMethod returns. This usually doesn't cause a problem, but it can; to cause a problem usually involves a questionable design decision (e.g., a disposed MyObject cleans up a field, and this happens to occur after LongRunningMethod's last reference to your MyObject instance but before using a locally stored reference to that field). I can make it happen but I don't expect to see it in the wild.

This is not a problem and this is why:

1) if LongRunningMethod() acceses fields on MyObject instance the "this" parameter is passed on the stack to the method meaning you have a rooted reference to the object instance, the method call practicaly is like this

newobj MyObject //Returns a reference in the stack
call LongRunningMethod

so when the LongRunningMethod is called there is a reference in the stack pointing at the MyObject instance. Also because LongRunningMethod acceses fields of the object it keeps a referente to the object instace in it's own stack frame and the object won't be garbage colected.

2) LongRunningMethod() doesn't access any fields on MyObject instance so that means even if the object is garbage colected (because now the jit can optimize the method to eliminate the reference from the stack) the method will never try to dereference a null object (the this pointer) so won't get a NullReference exception.

To test it you can even try to call with reflection a instance method that doesn't access any fields passing a null value and it will work.

NullReference is only thown when you try to dereference a null pointer and not by calling a method (if that method doesn't try to dereference a null pointer the exception will never be thrown)

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

ScanIAm — Tue, 04 Dec 2007 18:02:39 GMT

Sven Groot wrote:

ScanIAm wrote:
Console.WriteLine(new String("Bob").Length);

The part that concerns me is the accessing of the function 'Length' when you don't really know that the new String has actually been created.

Ignoring that String is a bad example because you can do "Bob".Length (as was mentioned), I still don't see what you're getting at.

What is it you want to check? Any error conditions that cause the object not to be created would throw an exception.

Code like what evildictaitor wrote:
MyObject o = new MyObject();
if( o == null )
throw new Exception();

That's completely pointless. O can never be null after a "new", since if the object couldn't be created an exception would be thrown (e.g. an OutOfMemoryException).

Exactly, and I'm fine with that, now, but it doesn't 'feel' right. That's my own cross to bear

string s = "bob";
if(s!=null)
Console.WriteLine(bob.Length);

just seems safer.

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

stevo_ — Tue, 04 Dec 2007 18:11:40 GMT

Well, you do that..

The concept behind most things in .NET is; the operation either worked, or it didn't (and caused an exception)..

All these pointless null checks are just chipping away at your performance slowly.. your code will be utterly confusing for anyone else who has to take it over..

I'd put the action to work, and work on getting over mentally, because carrying on doing that is bad practice for a .NET app..

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

William Stacey — Tue, 04 Dec 2007 18:12:00 GMT

ScanIAm wrote:

Sven Groot wrote:

ScanIAm wrote:
Console.WriteLine(new String("Bob").Length);

The part that concerns me is the accessing of the function 'Length' when you don't really know that the new String has actually been created.

Ignoring that String is a bad example because you can do "Bob".Length (as was mentioned), I still don't see what you're getting at.

What is it you want to check? Any error conditions that cause the object not to be created would throw an exception.

Code like what evildictaitor wrote:
MyObject o = new MyObject();
if( o == null )
throw new Exception();

That's completely pointless. O can never be null after a "new", since if the object couldn't be created an exception would be thrown (e.g. an OutOfMemoryException).

Exactly, and I'm fine with that, now, but it doesn't 'feel' right. That's my own cross to bear

string s = "bob";
if(s!=null)
Console.WriteLine(bob.Length);

just seems safer.

Feeling are important. You should do what feels right. However "abc".length will *never be null, unless there is some very strange memory issue or hardware failure - in which case, you have bigger issues to deal with. Happy coding

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

Pop Catalin — Tue, 04 Dec 2007 18:19:50 GMT

ScanIAm wrote:

Exactly, and I'm fine with that, now, but it doesn't 'feel' right. That's my own cross to bear

string s = "bob";
if(s!=null)
Console.WriteLine(bob.Length);

just seems safer.

It may seem to you safer, but if you dig deeper into the innner workings of .Net (reading books, blogs, articles etc) it won't seem safer anymore it will seem redundant and also less performant.

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

A1C Stephen Collins — Wed, 05 Dec 2007 18:22:00 GMT

ScanIAm wrote:

Console.WriteLine(new String("Bob").Length);

The part that concerns me is the accessing of the function 'Length' when you don't really know that the new String has actually been created.

Of course you know that the new String has been created. why would you not? that's exactly what you are telling the compiler to do. consider:

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            System.Console.WriteLine(new System.String('c', 10).Length);
        }
    }
}

here you are telling the runtime to create a new object of type String by calling the constructor with provided parameters, get the Length property, and pass a copy of it to the Console.WriteLine function. from there it doesn't matter what happens to the String object because it is no longer needed; the WriteLine function has it's own copy (because it's a value type) of what we wanted, so no worries.

am i right, guys?

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

Richard Anthony Hein — Wed, 05 Dec 2007 18:34:48 GMT

ScanIAm wrote:

Exactly, and I'm fine with that, now, but it doesn't 'feel' right. That's my own cross to bear

string s = "bob";
if(s!=null)
Console.WriteLine(bob.Length);

just seems safer.

Sorry, that's just not making sense; maybe you need to come up with a better example, but I can't see it. s can never be null here ... even if it was you'd sure as hell WANT an exception to be thrown, because it's exceptional ... you don't want to hide this kind of exception.

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

ScanIAm — Wed, 05 Dec 2007 18:47:58 GMT

Richard.Hein wrote:

ScanIAm wrote:

Exactly, and I'm fine with that, now, but it doesn't 'feel' right. That's my own cross to bear

string s = "bob";
if(s!=null)
Console.WriteLine(bob.Length);

just seems safer.

Sorry, that's just not making sense; maybe you need to come up with a better example, but I can't see it. s can never be null here ... even if it was you'd sure as hell WANT an exception to be thrown, because it's exceptional ... you don't want to hide this kind of exception.

OK, it appears that some of you never started out coding in ASM, C or C++ because you aren't able to envision a time and place where

1) dinosaurs ruled the planet
2) memory allocations were managed by the developer
3) some of them could fail for more reasons than just 'out of memory'.

So,

Console.WriteLine(new Object().ToString());

Would be a great way to cause your application to fail catastrophically.

It's also evident that from your point of view, failure is simply something that the end user can recover from. This is not the case when working on server software. You don't want your application to fail, you want it to retry.

So, All I'm saying is that I've spent at least 1 decade forcing myself to remember these limitations and when I see

Console.WriteLine(new Object().ToString());

It feels 'wrong' to me because, in the past, it WAS wrong, based on my experience.

I'm quite aware that it isn't wrong, and is, in fact, a simpler way to code.

I really don't have anything more to say about it.

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

Christian Liensberger — Wed, 05 Dec 2007 19:59:31 GMT

DinoViehland wrote:

littleguru wrote:

The MyObject instance won't be collected by the GC if you are accessing any fields that held by that instance... otherwise - as said - it would be a heavy CLR (GC) bug!

Just to shed a little light on the situation the typical example of this is using IntPtr's and the Dispose pattern. Such as:

class MyDisposable : IDisposable {
    private IntPtr _foo;
    public void DoIt() {
        SomePInvokeOperation(_foo);
    }

    ~MyDisposable() {
        Dispose();
    }
    public void Dispose() {
        CloseMyHandle(_foo);
        GC.SuppressFinalization(this);
    }
}

Now you do: new MyDisposable().DoIt(); The IntPtr is read and right after that read there are no longer any references to the MyDisposable() instance. Before SomePInvokeOperation can run the GC kicks in and collects the MyDisposable class. Next the finalizer thread runs which runs the finalizer which closes the native resource. Finally your SomePInvokeOperation runs and is operating on a _foo that is no longer valid.

The worst case scenario here is that you can use this for a handle recycling attack which violates security. If you're lucky the app is just going to crash. Anyway, the way to fix this is to put a GC.KeepAlive(this); in DoIt() so that the object survives the lifetime of the call. But it's really only a problem when you're interacting with native resources which the GC doesn't understand and keep alive its self. So still not a bug, but a good thing to know about if you're doing any interop programming.

Let's sum up: I'm sure that the first parameter that is passed in with that method is a this pointer... Why would the GC mean that the instance should be collected, if I try to access a member variable later on? If I don't access it, it is fine because I'll never discover that the GC collected it.

I'm accessing a private member of the class in the DoIt method. How can the GC collect the instance that is holding that before I access it. I thought the GC is only collecting if the instance is no longer reachable!

Correct me if I'm wrong!

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

yinxi88 — Thu, 06 Dec 2007 09:36:14 GMT

:O wow ,my god

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

evildictaitor — Thu, 06 Dec 2007 11:24:06 GMT

littleguru wrote:

I'm accessing a private member of the class in the DoIt method. How can the GC collect the instance that is holding that before I access it. I thought the GC is only collecting if the instance is no longer reachable!

Correct me if I'm wrong!

Turns out this is only happens when interacting with PInvoke and unmanaged operations. Within managed code it doesn't happen.

Read Dino's post.

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

Christian Liensberger — Thu, 06 Dec 2007 11:45:50 GMT

evildictaitor wrote:

littleguru wrote:

I'm accessing a private member of the class in the DoIt method. How can the GC collect the instance that is holding that before I access it. I thought the GC is only collecting if the instance is no longer reachable!

Correct me if I'm wrong!

Turns out this is only happens when interacting with PInvoke and unmanaged operations. Within managed code it doesn't happen.

Read Dino's post.

I thought that this has to do with PInvoke. But I guess it has to do while the PInvoke code is running not before that!

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

evildictaitor — Thu, 06 Dec 2007 11:51:05 GMT

littleguru wrote:

evildictaitor wrote:

littleguru wrote:

I'm accessing a private member of the class in the DoIt method. How can the GC collect the instance that is holding that before I access it. I thought the GC is only collecting if the instance is no longer reachable!

Correct me if I'm wrong!

Turns out this is only happens when interacting with PInvoke and unmanaged operations. Within managed code it doesn't happen.

Read Dino's post.

I thought that this has to do with PInvoke. But I guess it has to do while the PInvoke code is running not before that!

Yes. It reminds me of one of the really hard-to-repro bugs I've ever seen which was in an app designed to "turn off" the Windows key while in certain applications.

Basically you have to interact with Windows and give them a delegate object which they call whenever a key is pressed, but sadly even delegate objects get garbage collected, at which point the next keystroke kills the application immediately. Took me weeks to find that bug.

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

Curt Nichols — Tue, 11 Dec 2007 23:31:22 GMT

evildictaitor wrote:

To protect against it you could do

MyObject o = new MyObject();
var result = o.LongRunningMethod();
GC.KeepAlive(o);

But in fairness this is a bug that should be fixed by Microsoft rather than coded around, and you should write an bugreport if you find in your code that this is happening.

You could use KeepAlive, but it's probably better to fix the design of your code. This is definitely not a bug.

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

Curt Nichols — Tue, 11 Dec 2007 23:37:39 GMT

littleguru wrote:

The MyObject instance won't be collected by the GC if you are accessing any fields that held by that instance... otherwise - as said - it would be a heavy CLR (GC) bug!

This is incorrect, and it's not a bug. Objects referenced by fields of the MyObject instance will be collected only if when are no rooted references to them, not when the MyObject instance is collected. The MyObject instance may be collected even if there are other outstanding references to objects that its fields refer to. You can see for yourself here, code is included.

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

Curt Nichols — Tue, 11 Dec 2007 23:43:30 GMT

Pop Catalin Sever wrote:

1) if LongRunningMethod() acceses fields on MyObject instance the "this" parameter is passed on the stack to the method meaning you have a rooted reference to the object instance, the method call practicaly is like this

newobj MyObject //Returns a reference in the stack
call LongRunningMethod

What you're not seeing is that the JITter helps the GC know when the reference is no longer needed. In this case the MyObject reference is needed only to invoke the call to LongRunningMethod, but isn't needed afterward. If a GC occurs during LongRunningMethod the instance may be collected if there are no other rooted references to the object.

See here if you want code to reproduce the behavior.

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

Herbie Smith — Wed, 12 Dec 2007 14:44:39 GMT

I would see

new object().SomeMethod()

as a 'smell' indicating that SomeMethod should be static ...

Herbie

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

shuff1203 — Thu, 24 Jan 2008 19:25:05 GMT

Dr Herbie wrote:

I would see

new object().SomeMethod()

as a 'smell' indicating that SomeMethod should be static ...
Herbie

Can this even be done in VB.NET?

I'm trying to convert some sample code from c# that says:

New Application().run(f)

But that doesnt' work in VB.NET. Is there an equivalant?

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

JChung2006 — Thu, 24 Jan 2008 19:33:53 GMT

Dim o = New Application()
o.run(f)

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

shuff1203 — Thu, 24 Jan 2008 19:59:45 GMT

JChung2006 wrote:

Dim o = New Application()
o.run(f)

My quesiton was is there an equivalent to:

New Application().run(f)

I realize I could declare a var and use it.

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

evildictaitor — Thu, 24 Jan 2008 20:46:29 GMT

shuff1203 wrote:

My quesiton was is there an equivalent to:

New Application().run(f)

I realize I could declare a var and use it.

Try declaring a function and passing that as the arguments:

foo( New Application().run(f) )

If that throws an error, then no you can't, otherwise you might need to declare the type of the variable you're assigning first.

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

JChung2006 — Thu, 24 Jan 2008 20:55:40 GMT

GetType(Application).GetConstructor(New System.Type() {}).Invoke(New Object() {}).Run(f)

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

evildictaitor — Thu, 24 Jan 2008 22:58:42 GMT

JChung2006 wrote:

GetType(Application).GetConstructor(New System.Type() {}).Invoke(New Object() {}).Run(f)

While your post is technically correct, using reflection just to inline a function is never a good idea.

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

shuff1203 — Fri, 25 Jan 2008 02:46:01 GMT

evildictaitor wrote:
JChung2006 wrote:

GetType(Application).GetConstructor(New System.Type() {}).Invoke(New Object() {}).Run(f)
While your post is technically correct, using reflection just to inline a function is never a good idea.

Ya, but he did answer the question, that is a way to do it with just oneline of code in vb.net...

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

evildictaitor — Fri, 25 Jan 2008 03:11:26 GMT

shuff1203 wrote:

Ya, but he did answer the question, that is a way to do it with just oneline of code in vb.net...

Well, sort of. The inlined expression in C# does a very different control path to the thing he showed there, which can experience considerable slowdown, since reflection is a relatively expensive process (computationally speaking), and is never a good idea if there's an alternative.

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

Minh — Fri, 25 Jan 2008 04:56:49 GMT

If new String("Bob") could not be created, then an exception would be thrown, would it not?

Then .Length would never be called.

Also, you worry too much.

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

JChung2006 — Fri, 25 Jan 2008 05:02:49 GMT

evildictaitor wrote:

shuff1203 wrote:

Ya, but he did answer the question, that is a way to do it with just oneline of code in vb.net...

Well, sort of. The inlined expression in C# does a very different control path to the thing he showed there, which can experience considerable slowdown, since reflection is a relatively expensive process (computationally speaking), and is never a good idea if there's an alternative.

You missed the point so please just drop it. Yes, reflection is slower than if the references were already there, but guess what? Reflection is still faster than a network roundtrip or a disk seek by several orders of magnitude.

"Premature optimization is the root of all evil." -C. A. R. Hoare

Tech Off - is 'new object().property' or 'new object().method()' a good idea?

evildictaitor — Fri, 25 Jan 2008 06:30:44 GMT

JChung2006 wrote:

You missed the point so please just drop it. Yes, reflection is slower than if the references were already there, but guess what? Reflection is still faster than a network roundtrip or a disk seek by several orders of magnitude.

"Premature optimization is the root of all evil." -C. A. R. Hoare

Maybe, but compiler optimisations is one of the reasons your computer is getting faster year-on-year. It's not all hardware you know.

And even if reflection is faster than a network roundtrip it's less maintainable code, and automatic reasoning agents can't reason over reflection code, so the compiler can't do any optimisations over the function call.

But I'll assume I've missed the point, and stop pressing the issue.