|
rolleyes posted:Quick followup question - what are the implications of passing unmanaged resources to other methods? Does the 'using' in the parent maintain resource safety or would the target method need to do use it too? Or does it depend on the way exceptions are handled within the target method? This code: code:
code:
So if the method you're calling is going to write some stuff to the StreamWriter, then return without keeping state around, it'll work just fine. If the method is going to squirrel away the StreamWriter in a field somewhere and try to reference it later, you might have a problem if "later" is after execution has left the using block.
|
# ? Sep 10, 2011 18:10 |
|
|
# ? Apr 23, 2024 21:52 |
|
I'd figured actually storing it (as opposed to just using it and returning) would be a bad idea for just that reason. The ability to stack multiple using statements is handy too. Thanks for the help guys. rolleyes fucked around with this message at 19:00 on Sep 10, 2011 |
# ? Sep 10, 2011 18:57 |
|
It's sorta interesting to note that the stacking of using statements isn't anything special, it's just a statement idiom that's generally frowned upon elsewhere. Just like c/c++ and Java it's possible to have control statements followed by a single statement instead of a block of statements. E.g. code:
code:
code:
code:
code:
code:
Dr Monkeysee fucked around with this message at 21:03 on Sep 11, 2011 |
# ? Sep 11, 2011 21:00 |
|
I was reading through some Microsoft example code when I came across this:code:
code:
|
# ? Sep 12, 2011 01:04 |
|
PDP-1 posted:That's the way I've always triggered events, is there some subtlety I'm missing that makes the extra variable declaration useful? This code is a parallel computation example if that makes any difference. http://piers7.blogspot.com/2010/03/3-races-with-net-events.html By declaring a local copy you're ensuring thread safety.
|
# ? Sep 12, 2011 01:12 |
|
Is it bad form to just declare events likecode:
|
# ? Sep 12, 2011 01:18 |
|
Orzo posted:http://stackoverflow.com/questions/2582052/c-event-handlers-not-thread-safe Ah ok, that explains it. I've never seen that done before but it makes sense that they would be being extra careful about thread safety in a multi-threaded example. Thanks!
|
# ? Sep 12, 2011 01:26 |
|
I wouldn't use events in a multithreaded scenario because there's still a race condition: the invocation list could change between the temporary multicast delegate assignment and the event raise finishing. You could fix that by wrapping the entire event fire in a mutex, but that seems like a quick way to introduce deadlocks. Instead use Task, Async, IObservable, etc for your multithreading needs.
|
# ? Sep 12, 2011 03:40 |
|
The second link that Orzo gave references a blog post by Eric Lippert that addresses that second race condition. He argues that thread safety is a two part problem: (1) the object raising the event has to guard against null references by making a local copy of the multicast delegate, and (2) any objects subscribed to the event have to internally track what events they are currently listening to and need to fail gracefully if an event is fired after they unsubscribe (or ignore it). The first problem is solvable by making the local copy, but the second problem doesn't seem to have a really clean solution in the sense that you have the coupled logic of un/subscribing to events plus the internal 'what am I listening for' code. If you change one part you have to remember to change the other part or risk transient and unrepeatable bugs. So yeah, either not using events or using them sparingly and only as a last resort seems to be the best option for multithreaded systems with transient event listeners.
|
# ? Sep 12, 2011 05:03 |
|
Sedro posted:I wouldn't use events in a multithreaded scenario because there's still a race condition: the invocation list could change between the temporary multicast delegate assignment and the event raise finishing. You could fix that by wrapping the entire event fire in a mutex, but that seems like a quick way to introduce deadlocks. Instead use Task, Async, IObservable, etc for your multithreading needs. Delegate instances (including multicast delegates) are immutable. If someone adds or removes themselves from the invocation list of an event while another thread is simultaneously iterating over the list to deliver event notifications, it won't break anything because the iterating thread is working from what is effectively a snapshot of the list. What is still a potential race condition in multithreaded events is add/remove. Since the delegate instance is immutable, simultaneous access from two threads won't corrupt the list, but an update to the field made on one thread might be lost if another thread is in the middle of combining a new delegate instance together as well. Simple Monitor.Lock mutex in the event's add and remove blocks would make that problem go away though. biznatchio fucked around with this message at 07:00 on Sep 12, 2011 |
# ? Sep 12, 2011 06:55 |
|
Ok, since this is something I imagine I'll come across sooner or later, let me just check I've got this. Initially, I was wondering why creating a local copy would make any difference because it would still refer to the same instance (delegates are reference types yes?) so any changes would still be seen by the local copy. But, because delegates are immutable (a-la-strings) what actually happens when one is changed is that it creates a new instance with the changes and returns it, so the local copy still refers to the original instance but the 'real' copy now refers to a new instance? And then I guess once the local copy falls out of scope the garbage collector eats it, assuming no other references.
|
# ? Sep 12, 2011 09:13 |
|
epswing posted:Is it bad form to just declare events like It's not terrible, but you do lose the ability to easily check if you even have handlers, and it won't work at all if you have an eventhandler that doesn't return void (doing so is a horror in and of itself, but it is used in some places, e.g. the AppDomain assembly load events). I just defined two extension methods and used them instead: code:
biznatchio posted:What is still a potential race condition in multithreaded events is add/remove. Since the delegate instance is immutable, simultaneous access from two threads won't corrupt the list, but an update to the field made on one thread might be lost if another thread is in the middle of combining a new delegate instance together as well. Simple Monitor.Lock mutex in the event's add and remove blocks would make that problem go away though. The default implementation of add/remove is thread safe though, so, unless you define them explicitly, you don't have to worry about it. edit: rolleyes posted:But, because delegates are immutable (a-la-strings) what actually happens when one is changed is that it creates a new instance with the changes and returns it, so the local copy still refers to the original instance but the 'real' copy now refers to a new instance? Yep. dwazegek fucked around with this message at 09:16 on Sep 12, 2011 |
# ? Sep 12, 2011 09:14 |
|
dwazegek posted:I just defined two extension methods and used them instead That's pretty spiffy. Extension methods are still black magic to me. I love them
|
# ? Sep 12, 2011 14:13 |
|
I've got a custom ASP.NET control that I don't have the source code for. This control has events which I have added handlers for, but they don't behave as I expect them to. The events are processed asynchronously and, when debugging, the postbacks never hit my Page_Load event (they go straight into the event handler). Any changes I make while in these handlers do not "hold". That is, if I have a string which I set equal to "test" in the handler, I can set a watch for that string and its value is not "test" until I enter back into the handler code. It's like there are two conflicting versions of the variable, one that exists in the rest of my code and one that exists in this control's handler. What could be going on here? How do I get it so I can change and update values while in this control's event handlers? edit: Never mind, got my answer: quote:The events are static so you cannot set page control properties which are instance variables. Holy Diver fucked around with this message at 21:43 on Sep 12, 2011 |
# ? Sep 12, 2011 21:10 |
|
I've spent the last couple of evenings messing about with something which... well I've got it working after a few accidental infinite process creation loops, but I can't decide whether it was a dumb idea or not. The users of that analysis app I was asking about a page or so back would find it useful to run it from both the command line and as a GUI. Rather than having two separate binaries I did some googling and now have a single binary which, through a dirty hack, does both. To summarise:
The problem now is that when the app starts, up pops a GUI with a console window behind it. This is where the dirty hack comes in.
The only artifact of this you see when starting the application by launching it from explorer is that a console window briefly flickers on the screen as the initial instance starts, calls CreateProcess and exits before the second instance appears as a GUI. While I'm frankly amazed that this is working, is this a really awful idea? The obvious downside is that the chain of execution for the console mode is all happening inside the MainWindow constructor but other than that I can't see anything immediately dangerous. I'd never build a large app like this but this is just a simple utility I'm building to replace a legacy version. edit: Just to clarify this is definitely not my own work - I found the rough description of how to do this in a stackoverflow post (I think) and googled the details. rolleyes fucked around with this message at 23:17 on Sep 12, 2011 |
# ? Sep 12, 2011 22:48 |
|
rolleyes posted:I've spent the last couple of evenings messing about with something which... well I've got it working after a few accidental infinite process creation loops, but I can't decide whether it was a dumb idea or not. You don't need to do your "dirty hack" logic in MainWindow's constructor. If you open up your Application.xaml and remove the StartupUri attribute from the root element, then you can add an event handler to Application.Startup. Add your logic to check command line arguments and either create or not create MainWindow there.
|
# ? Sep 13, 2011 11:15 |
|
Say I have a function prototype like so:code:
|
# ? Sep 14, 2011 20:05 |
|
Zhentar posted:Say I have a function prototype like so: Yes, sure. code:
|
# ? Sep 14, 2011 20:40 |
|
ninjeff posted:You don't need to do your "dirty hack" logic in MainWindow's constructor. If you open up your Application.xaml and remove the StartupUri attribute from the root element, then you can add an event handler to Application.Startup. Add your logic to check command line arguments and either create or not create MainWindow there. Could you elaborate slightly? My XAML knowledge is not great, which is one of the reasons this is a WPF project (for learning). I already have a startup event handler which grabs the command line arguments (but doesn't do the processing on them). My App.xaml currently looks like this: code:
code:
edit: I've pretty much answered my own question by trying this, and the short version is that the above is correct. The only thing I'm unsure of is Show() vs. ShowDialog(). Does it even matter when it's the first form to be shown? rolleyes fucked around with this message at 20:58 on Sep 14, 2011 |
# ? Sep 14, 2011 20:45 |
|
Has anyone been watching the Windows 8 talks at today's BUILD conference? UI guidelines for "Metro" apps, by Jensen Harris: http://channel9.msdn.com/Events/BUILD/BUILD2011/BPS-1004 How to build Metro apps using C#/VB/XAML -- also covers C++/XAML and Javascript/HTML, but the .NET approach used async . By Ales Holocek and John Sheehan for the first half, and then Kieren Mockford and Chris Sells at the 1h08 mark: http://channel9.msdn.com/Events/BUILD/BUILD2011/BPS-1005
|
# ? Sep 14, 2011 20:45 |
|
ljw1004 posted:How to build Metro apps using C#/VB/XAML -- also covers C++/XAML and Javascript/HTML, but the .NET approach used async . By Ales Holocek and John Sheehan for the first half, and then Kieren Mockford and Chris Sells at the 1h08 mark: Hopefully that will go some way to calming all the "omg no .NET in Windows 8" hysteria which blew up a couple of months back. I've caught bits of the presentation and skimmed a few news stories, at some point I really need to sit down and watch it all.
|
# ? Sep 14, 2011 20:50 |
|
ljw1004 posted:However, it has to infer T from the Action<T> argument. It will never infer from what you do with the return type. Ah, yeah. I secretly meant "without an explicitly typed Action<T>". I'm pretty sure the answer to this is no, but is there any way to make a generic constraint on a generic class, e.g. where T : List<>?
|
# ? Sep 14, 2011 21:02 |
|
Zhentar posted:Ah, yeah. I secretly meant "without an explicitly typed Action<T>". Sure, but you'll need to at least have a type param for the item. .NET generics don't use type erasure. Here are a few things you can do, depending on what you want to accomplish. What do you want to accomplish? code:
|
# ? Sep 14, 2011 22:01 |
|
I hacked together a really lovely VBscript for a project I'm working on. Basically what it does it pull information about a workstation via WMI when I give it a text file with a list of them. I have it working with a list of a few workstations around me (six of them). However when I give it the full list of 37 machines it craps itself with the message "Error: 438 - Object doesn't support this property or method" after one computer. I assumed it was the second computer that made it die so I used a second script (both the same one just takes the computer as the argument) and it ran just fine, so what the gently caress? Here is the hideous script: code:
|
# ? Sep 15, 2011 00:13 |
|
It sounds like it might be a single machine causing the issue? Why not try each machine 1 at a time.
|
# ? Sep 15, 2011 01:50 |
|
Sedro posted:Sure, but you'll need to at least have a type param for the item. .NET generics don't use type erasure. Here are a few things you can do, depending on what you want to accomplish. What do you want to accomplish? That's about what I figured, thanks. What I'm trying to accomplish is getting stronger typing with a collection class, while hopefully minimizing changes to my existing code and code duplication, and learning more about effectively using generics in the process.
|
# ? Sep 15, 2011 01:57 |
|
Sprawl posted:It sounds like it might be a single machine causing the issue? Why not try each machine 1 at a time. That's what is stupidly annoying, I ran it one machine at a time and it didn't freak out, but when I use the list it throws the error. Say I have a text file with the following: MachineA MachineB MachineC I run it against that file and it spits out the information for MachineA just fine, but as soon as it gets to MachineB it breaks. So I go ahead and run it against just MachineB and it spits out the information just fine!
|
# ? Sep 15, 2011 02:30 |
|
rolleyes posted:edit: Glad you got it working! I suppose you'd use Show() if you wanted to show several windows at once or perform some other logic immediately after showing the first window, and ShowDialog() if you wanted to add some logic that would run after the first form closed. Note also that you could achieve both of these things in other ways if you wanted to. If Application_Startup's only responsibility is to display the form, though, then yeah there should be no difference.
|
# ? Sep 15, 2011 03:01 |
|
Zhentar posted:What I'm trying to accomplish is... After poking around at it a bit more, I can actually explain the main problem I'm having. I've got this: code:
code:
Making it public Container<T> SomeFunctionOrOther<T>() sucks, in part because it can't infer the type so I'd have to add in the right type to hundreds of lines of code, and in part because generic constraints won't let me specify that T must be castable from SubClass. I'm also concerned that the complexity of my actual code may mean that I end up with a long list of types for some functions.
|
# ? Sep 15, 2011 04:23 |
|
Zhentar posted:Making it public Container<T> SomeFunctionOrOther<T>() sucks, in part because it can't infer the type so I'd have to add in the right type to hundreds of lines of code... code:
Zhentar posted:...and in part because generic constraints won't let me specify that T must be castable from SubClass.
|
# ? Sep 15, 2011 05:06 |
|
Sedro posted:So a call to SomeFunctionOrOther<SubClass> can return a Container<SubClass>, Container<BaseClass> or Container<object>? That would be contravariance, and its possibility depends on what Container does. I mean something like this: code:
|
# ? Sep 15, 2011 06:31 |
|
Zhentar posted:I mean something like this: You'd have to remove this line to make it work, you can't mix generics and non-generic types that way: code:
|
# ? Sep 15, 2011 09:02 |
|
I don't have vs2010 in front of me, but try this. code:
|
# ? Sep 15, 2011 12:38 |
|
dwazegek posted:And no amount of where constraints will get it to work, since the only way to guarantee that Container<T> will be able to take a SubClass is if SubClass (or a base class of SubClass) is T . Yeah, that was my point. That is an actual functional requirement of my code anyway; I just can't express that with constraints.
|
# ? Sep 15, 2011 15:02 |
|
Me and my text file pattern finding are back again. Mostly done, but one particular pattern is trickier. These files have tags which denote the starts and ends of named regions. Within those regions are references to labels. I need to check that, for each label reference within a region, the label it refers to is also within that region and if it isn't write this out to the output file as an error. Just to make matters more fun these files support both line comments (//) and block comments (/* */) and both labels and references inside comments are to be ignored. I'm starting to get the impression I'm building a script interpreter here... Anyway, to avoid multiple passes over each file to sort this all out, my plan goes something like:
Apart from using more memory, am I missing any serious downsides to this approach? Although I haven't done any profiling I'm assuming it'll be quicker as most of the work is done in memory rather than by spooling backwards and forwards over a file like searching a backup tape.
|
# ? Sep 20, 2011 19:19 |
|
rolleyes posted:Me and my text file pattern finding are back again. I'm pretty sure it's preferable to use a bit of system memory rather than reading back and forth in a file, so I think you're on the right track. Is there some other reason you need to know the positional information (column, line number)? If not, you could just do your checking incrementally as you read a block, kind of like this (I'm assuming that "labels" can be anywhere either before or after "label references"): code:
HashSet is a data structure that only allows unique items. Available in .Net Framework 3.5 and up. Che Delilas fucked around with this message at 22:19 on Sep 20, 2011 |
# ? Sep 20, 2011 22:15 |
|
Che Delilas posted:Stuff Thanks, that's an approach I should really have considered. HashSet is new to me too so that's very handy. Positional information is required as I need to spit any errors I find out to a file, e.g.: pre:Results for someFile.txt: ------------------------- Label "someLabel" referred to at line 6 column 10 in region "someRegion" is not defined in this region. ...etc edit: To put this in context, a region can be somewhere in the region () of 6,000 lines long so positional information saves a lot of time otherwise wasted hunting around masses of text. rolleyes fucked around with this message at 22:34 on Sep 20, 2011 |
# ? Sep 20, 2011 22:28 |
|
rolleyes posted:Thanks, that's an approach I should really have considered. Ah yeah. Then I would suggest using a HashSet for labels (because you only need to know THAT they exist somewhere in the block, unless you want the program to warn about duplicate labels too ) and a List of structs for your label references, where the struct contains all the info you need like line and column number. So in pseudo: code:
vvv Welcome. Che Delilas fucked around with this message at 23:02 on Sep 20, 2011 |
# ? Sep 20, 2011 22:50 |
|
Yep that ought to work, and storing the positional information in the structs should let me use your incremental approach because I can then pull it back out in the foreach at the end of the region. Thanks again.
|
# ? Sep 20, 2011 22:54 |
|
|
# ? Apr 23, 2024 21:52 |
|
Really easy question because I can't figure out what to type into the google. I'm learning winforms and making a very simple program to try out various stuff, and I'm trying to add a small options screen with some configuration info in it. What I want to do is make it impossible for the main window to have focus as long as the options window is up, as many programs do. I'm sure there's some simple way to accomplish this but I can't seem to find it.
|
# ? Sep 21, 2011 05:35 |