> > It would also introduce under-documented determinism into
> the system.
> > One would have to look all the way back to the class definition to
> > find out if an object reference is [Counted].
> Dejan wrote:
>
> No no no :).
>
> Marking a class as [Counted] would simply imbue a reference
> cou
Peter Stephens wrote:
> > (The requirement being, of course, that [Counted] references
> > can only be embedded in [Counted] objects or used on the stack.)
>
> Would this exclude casting a [Counted] object to type System.Object?
> Certainly System.Object would not be counted, so casting your
MyCou
> (The requirement being,
> of course, that [Counted] references can only be embedded in
> [Counted] objects or used on the stack.)
Would this exclude casting a [Counted] object to type System.Object?
Certainly System.Object would not be counted, so casting your MyCounted
object to System.Object w
Chad M. Gross wrote:
> > That could be used to ensure that Dispose() is called when the
> > last [Counted] reference is destroyed, as a way to reclaim
> > handles and other resources. Then later the garbage collector
> > would come and reclaim the memory.
>
> Brian addresses your exact point regra
On Wed, 23 Oct 2002 20:18:59 +0200, Dejan Jelovic <[EMAIL PROTECTED]> wrote:
>Patrick Steele wrote:
>
>> > What I can't understand why reference couting wasn't
>> > implemented in CLI as a standard facility. A [Counted]
>> > attribute would do the trick nicely.
>> > ...
>>
>> See:
>>
>>
>http://di
Wednesday, October 23, 2002 2:19 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [ADVANCED-DOTNET] Exception safety in C#
>
>
> Patrick Steele wrote:
>
> > > What I can't understand why reference couting wasn't
> > > implemented in CLI as a standard f
Patrick Steele wrote:
> > What I can't understand why reference couting wasn't
> > implemented in CLI as a standard facility. A [Counted]
> > attribute would do the trick nicely.
> > ...
>
> See:
>
>
http://discuss.develop.com/archives/wa.exe?A2=ind0010a&L=dotnet&P=39459
I've seen Brian's argumen
> First of all, you say: "The key is in the std::swap. It is guaranteed,
> by the standard, never to throw".
Technically, you are correct about std::swap. Again, I need to be more
clear. std::swap on raw pointers is guaranteed never to throw. (simiar
to an assignment, but easier to write) And,
sing references, exception safety becomes easier (also since structs can't have
user-defined assignment operators).
Johan
-Original Message-
From: Trey Nash [mailto:tnash@;DIGITRIX.COM]
Sent: Wednesday, October 23, 2002 8:46 AM
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] E
> -Original Message-
> From: Dejan Jelovic [mailto:dejan@;JELOVIC.COM]
> Sent: Wednesday, October 23, 2002 10:46 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [ADVANCED-DOTNET] Exception safety in C#
>
> What I can't understand why reference couting wasn'
Ooops. I have succeeded in being not so clear again. :-) For some
reason, I have an uncanny knack at that. :-(
OK, what I *really* meant had nothing to do with assignment operations and
copy operations in C#. They had more to do with the exception safety
guideline that reads similar to this:
Ian Griffiths wrote:
> So if you want to assign a bunch of stuff you would just do this:
>
> temp1 = orig1.Clone();
> temp2 = orig2.Clone();
> temp3 = orig3.Clone();
>
> // If we were going to have thrown we
> // would have done by now.
> dest1 = temp1;
> dest2 = temp2;
> dest3 = t
There are no copy constructors in C#, so how exactly would this be an issue?
Assignment is never overloaded. So I don't think it can ever throw. Isn't
the only reason that this is only a big hairy issue in C++ because you can't
trust things like assignment not to throw?
So if you want to assign
13 matches
Mail list logo
