> > 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
Hi all,
I'm back with another exception safety musing. Let me start by stating
that one of the goals of exception safety is to ensure the integrity of
the software in the face of exceptions. That being the case, consider the
following contrived C++ class.
class MyClass
{
public:
MyClas
14 matches
Mail list logo
