IRC Logs

Network: freenode Channel: #csharp

	Enter your search terms Submit search form
	Web www.irclog.org

[00:00]<jrrcrdrg>so how about class.Finalize() or something
[00:00]<lnvnzxu>in c++/cli, delete can be called on a IDisposable type
[00:00]<lnvnzxu>JackRyan: no, you can't do it; let the GC handle it
[00:00]<jrrcrdrg>http://pastebin.com/768329
[00:00]<lnvnzxu>or have the C# type implement IDisposable
[00:00]<jrrcrdrg>Thats what I have, should I implement IDispoable instea
[00:00]<lnvnzxu>you should implement both
[00:01]<lnvnzxu>IDisposable.Dispose should supress finalization
[00:01]<jrrcrdrg>Can you show me a snippet?
[00:01]<lnvnzxu>http://msdn2.microsoft.com/en-us/system.idisposable.aspx
[00:02]<lnvnzxu>that is the recommended pattern
[00:03]<lnvnzxu>which is why c++/cli implements it inherently
[00:03]<lnvnzxu>a destructor implements exactly that pattern
[00:03]<jrrcrdrg>why isnt this pattern implemented as a language feature in C#
[00:04]<lnvnzxu>that's a question for hans
[00:04]<jrrcrdrg>whats the point of calling Dispose(false) in the Finalizer
[00:04]<jrrcrdrg>if Dispose(bool) doesn't **do** anything when the disposing value is false?
[00:04]<lnvnzxu>to ensure it is still cleaned up if no one called IDisposable.Dispose, the false just prevents any field references from being disposed
[00:05]<jrrcrdrg>ah wait, i misread the code..
[00:05]<lnvnzxu>a type that implements IDisposable should (must) call Dispose on all IDisposable references it holds
[00:05]<lnvnzxu>fxcop complains about that
[00:05]<jrrcrdrg>it disposes of the unmanaged resources either way? how does that work?
[00:05]<lnvnzxu>if the user of the type does not call Dispose, the object will be marked for finalization when collected because it implements a finalizers
[00:06]<lnvnzxu>-s
[00:06]<jrrcrdrg>I think I see.. it leaves the managed resources to be GCd later
[00:06]<jrrcrdrg>this is crying out to be implemented into the language though
[00:06]<lnvnzxu>yep; the IDisposable pattern allows users to control it if they want to
[00:08]<lnvnzxu>another thing i really like about C++/CLI is that is enables auto storage semantics for reference types; in this case, if your C# type implemented IDisposable, and you wanted to ensure Dispose was called when the object went out of scope, you'd declare it as "Foo f;"
[00:09]<lnvnzxu>essentially the C# using statement
[00:10]<lnvnzxu>c++/cli makes managed development a lot more c++ like, compared to managed extensions for c++
[00:10]<jrrcrdrg>peterhu: you mean as if the object was on the stack?
[00:10]<lnvnzxu>correct
[00:10]<jrrcrdrg>wow
[00:11]<jrrcrdrg>i wish i had VS2005:(
[00:14]<lnvnzxu>JackRyan: herb sutter's c++/cli design rationale, http://www.gotw.ca/publications/C++CLIRationale.pdf
[00:14]<jrrcrdrg>and here i thought that mcpp and cpp/cli was the same
[00:14]<lnvnzxu>a good read
[00:14]<lnvnzxu>oh no
[00:14]<lnvnzxu>c++/cli is an ECMA standard, becoming an ISO standard
[00:14]<jrrcrdrg>wow
[00:14]<lnvnzxu>managed extensions for c++ are a propriety extension, and a bad one at that
[00:14]<jrrcrdrg>any other compilers that support it though?
[00:15]<lnvnzxu>none that i know of yet, though herb sutter and friends were working with other vendors for adoption
[00:15]<jrrcrdrg>would be cool if g could do it
[00:15]<jrrcrdrg>gcc*
[00:15]<jrrcrdrg>so Cpp/CLI doesn't necessarily have to use dotNET?
[00:16]<gfgdggv7w>well it's a CLI language, obviously
[00:16]<gfgdggv7w>but it doesn't have to run on the MS CLR
[00:16]<lnvnzxu>i think there's a gcc frontend project on it, but i don't know it's progres (cxxcli)
[00:16]<jrrcrdrg>what is CLI again, common language implementation?
[00:16]<lnvnzxu>infrastructure
[00:16]<jrrcrdrg>oh ok.. maybe mono? :)
[00:16]<y-gz>a student does the gcc frontend as part of google's summer of code for Mono
[00:17]<y-gz>afaik
[00:17]<lnvnzxu>mono 2.0 should be able to reference c++/cli assemblies (c++/cli is easily capable of producing safe and pure assemblies)
[00:17]<lnvnzxu>but there's no plans to support a compiler, afaik
[00:17]<y-gz>no point imho
[00:17]<jrrcrdrg>wont Cpp/CLI still support native code?
[00:18]<y-gz>dunno when 2.0 will be ready
[00:18]<lnvnzxu>it will (through a term called "c++ interop"), but not in safe and pure modes
[00:18]<y-gz>there is quite a lot of work till it
[00:18]<jrrcrdrg>There's always a point.. cant have true open source code if you have to compile it in visual studio eh?
[00:18]<y-gz>heh that is a stupid statement....
[00:18]<y-gz>you don't have to
[00:19]<jrrcrdrg>if it costs several hundred $ just to be able to compile it..
[00:19]<lnvnzxu>man i hate acrobat reader heh
[00:19]<lnvnzxu>and here i thought firefox was hung
[00:19]<jrrcrdrg>now theres probably some kind of free compiler for it, but who knows how nice the licensing is
[00:19]<lnvnzxu>nope, just an update dialog that popped up under the browser window
[00:19]<mdsvyrmrg>while debugging, how to break if a variable reaches a particular value?
[00:19]<lnvnzxu>a breakpoint condition
[00:20]<y-gz>i don't know C++ very well, but I don't see the point in C++/CLI when there is C#
[00:20]<gfgdggv7w>be warned that conditional breakpoints slow things down a lot
[00:20]<gfgdggv7w>i-nZ, it's for interop, that's all
[00:20]<jrrcrdrg>probably mixing native code easier
[00:20]<lnvnzxu>well, certainly less than a breakpoint without a condition would
[00:21]<mdsvyrmrg>thanks
[00:21]<gfgdggv7w>a regular breakpoint doesn't really slow down perceptibly
[00:21]<gfgdggv7w>the condition really grinds it down
[00:21]<gfgdggv7w>but if that's what you need, that's what you need
[00:21]<sdnffdxdlld>lol a regular breakpoint couldn't slow it much more really ;)
[00:21]<lnvnzxu>a conditional breakpoint still int3s, evaluates an expression, and depending on the result, breaks or continues it
[00:21]<lnvnzxu>nothing you wouldn't have to do manually
[00:22]<jrrcrdrg>peterhu: does this look better? http://pastebin.com/768415
[00:22]<gfgdggv7w>i can't really say anything about WHY conditional breaks are slow
[00:22]<gfgdggv7w>they just are
[00:23]<lnvnzxu>if they're slow, it's likely a result of the managed EE
[00:23]<y-gz>dunno how they are implemented in a managed environment
[00:23]<gfgdggv7w>they're pretty slow in unmanaged code too
[00:23]<y-gz>but may be it is because the code actually breaks and checks the condition :)
[00:24]<lnvnzxu>JackRyan: close; the if (disposing) conditional in Dispose(bool) should be responsible for calling Dispose on any held reference on IDisposable types
[00:24]<y-gz>then continues if it is false
[00:24]<kjr>they're slow because god is punshing the use of GOTO
[00:24]<kjr>GOTO is considered harmful
[00:24]<lnvnzxu>you should be closing the stream irrespect of disposing
[00:24]<lnvnzxu>so if you have no IDisposable contained types, it should just be if (!disposed) { close_stream(); disposed = true }
[00:25]<lnvnzxu>note: TcpClient is IDisposable
[00:26]<lnvnzxu>so it really should be: if (!disposed) { if (disposing) myClient.Dispose(); disposed = true; }
[00:26]<jrrcrdrg>oh

Back to #csharp
Or go to some related logs:
#ubuntu
#gentoo
#gentoo
#gentoo
#php