|
You weren't per chance fixing this security issue with SP that is currently all the rage with hackers, no?
"I had the right to remain silent, but I didn't have the ability!"
Ron White, Comedian
|
|
|
|
|
I wish, I was actually doing something as mundane as updating site titles. It should in theory be easy. But those things that work in theory never work in practice. Even when you practice them.
To err is human to really mess up you need a computer
|
|
|
|
|
rnbergren wrote: about a certain software package from Microsoft. It really shouldn't work that way but it does.
You mean Windows? 
Latest Article - A 4-Stack rPI Cluster with WiFi-Ethernet Bridging
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
Close. SharePoint.
To err is human to really mess up you need a computer
|
|
|
|
|
C'mon now, don't leave us hanging!  Share so that we can all learn from your mistakes...what are friends for?
"Go forth into the source" - Neal Morse
|
|
|
|
|
Laughing at? 
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
exactly, that is why I didn't reveal the full extent of my idiocy. It is HUGE I say
To err is human to really mess up you need a computer
|
|
|
|
|
I've always been kind of bummed about the universal garbage collection in .NET because you can't do realtime coding with a GC running in the background.
What I'd have liked to see, at the very least, is a segregated heap that wasn't collected, and an ability to suspend background collection.
You can kind of hack something like it into there using the large object heap and also using .NET 4+'s ability to reserve heap and suspend GC but it's non-optimal.
See, I'd really like to write VST plugins in C# for example, and while there are offerings to do so, they are not realtime. They are kinda realtime. Not good enough for live music performance.
Instead I'm forced to do it in something like C++ or *gasp* Delphi, which is costlier/more time consuming to write solid code with.
I'd be okay with C# code blocks (similar to unsafe) where realtime code could run but apparently that's too much to ask.
Also, I love garbage collection. Don't get me wrong. I even used it in C++ ISAPI server apps (using Boehm collector) for my strings in order to avoid heap fragmentation - in the right areas it can even improve performance.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Nothing in windows is truly real time - and I never used heaps in realtime apps because of the fragmentation problem. When you are designing an inkjet printer that should just run for years on a conveyor belt with just the ink cartridge needing changing, you can't risk fragmentation or you'll miss product. Windows was never a choice for that!
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
VSTs are realtime, and run in windows.
I get that windows is not an RTOS. But windows is pretty good at faking it enough for games and music apps.
That's what's important - not the largely academic technical category of RTOS.
Otherwise people would never use Macs or PCs to write or perform music with.
But yeah, I do know what you're saying. You're talking about writing little things like printer drivers.
I'm talking about much larger animals where ring buffers just won't cut it. Like a vocoder VST or a quadruple osc synth with compression and analog modeling.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Only thing that allows Windows to do anything in "realtime" is that machines are far faster than the many minicomputers used for realtime work (Xerox Sigma series, Systems Engineering Labs, Modcomp, Harris, Interdata, etc.). These machines had a variety of hardware features that supported quick context switching (think multiple register sets, multiple memory maps, bit level instructions, etc.), and huge numbers of priority interrupt levels to facilitate realtime processing (at least one machine had 127 levels of priority interrupt). Usually it was a simple matter to use an interrupt to trigger a process to go do something quickly in response to an interrupt.
Once the PC came out, these machines quickly died as eventually so did the VAX. market for realtime work was relegated to the embedded processor work and realtime kernels.
In their infinite wisdom the NT designers didn't allow Interrupts to do ANY significant processing. They handed that processing off to something called the Dispatch Priority Level, a sort of netherworld between the interrupts and the OS.
|
|
|
|
|
All garbage collected languages that I'm familiar with take too big a bite in that they don't let you delete things. The GC has to do all the work.
I'd rather see opportunities to delete objects under programmer control via:
* Stack variables that destruct when you go out of scope
* Destructors in classes
* Ability to 'delete' a pointer
These ideas are not incompatible with GC languages but the features are conspicuously absent.
I'm retired. There's a nap for that...
- Harvey
|
|
|
|
|
That's true, and kind of what i'm looking for, whatever form it takes.
the Boehm collector let you mix, but that was C++ code
there are now true value types (stack allocated) in the latest C#
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
|
I wasn't going to tell him. Anyone that uses Finalizers needs to be dragged into the street and summarily shot.
With witnesses so nobody *ever* makes the same mistake.
There's a special hell where they keep the guy who designed them. It's below building 8 on the microsoft campus.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
I'm told tuples use them too
|
|
|
|
|
Finalizers are kind of mandatory if C# object create native resource through interop. An increasingly rare occurrence those days to be sure, but it still happens.
Also MS Style cop thingy complains if you don't have a finalizer on IDisposable class. I disable that silly warning... But some people chose to follow it.
|
|
|
|
|
I just use dispose.
if you don't dispose your disposable unmanaged resources, you suck at coding.
I won't make the rest of the end developers pay in GC performance for that lack of skill
=D
/the true bastard coder from hell
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
well there are case were using Dispose is not quite practical...
Further if you write a class using unmanaged resource, you can't rely on your user calling Dispose. You can hope they do call Dispose, but it's even better if you can make it work regardless! 
i.e. it's better if your class doesn't memory leak regardless whether whoever use it call Dispose or not. The whole point of .NET is that .NET class don't give headache to whoever uses them! 
|
|
|
|
|
I mean, probably, but I don't usually code for VB developers 
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
you sound like you didn't give how to use unmanaged resource any sort of serious thought! 
to be fair.. in the last 10 years I never had to use unmanaged resource (explicitly) in .NET!
But you have to keep in mind.
1. .NET use a lot of unmanaged resource. But it's done in a lot of nicely encapsulated OS/Utility class. For example WPF use tons of them to render DirectX content. It's also very common in WinForm, all those Bitmap, Cursor, Brush, etc... all wrap unmanaged OS resources.
2. once upon a time, before .NET 3.5, one often had to use unmanaged resource explicitly to use OS class not nicely wrapped. Hence how to properly use them was much more common knowledge back then.
Additionally what has unmanaged resources to do with VB?
If anything, my natural prejudice against VB developers would have me say that VB developer can't properly handle unmanaged resources!
|
|
|
|
|
Actually have given it a lot of thought, and in the end I decided not to use Finalizers.
Here's why, and I think it's justifiable: Win32 process segregation. You will clean all handles on proc exit RIGHT AFTER the GC cleans up it's Finalized objects. Win32 handles what .NET won't, usually at the same time.
There's one exception - remote COM objects. I will clear handles on those, but doing RPC is its own topic, and lifetime considerations are a huge one.
As far as your final sentence, that was rather my point. My audience isn't VB developers. If I was targeting them I'd make my code drool proof. =)
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
At any rate I don't understand your beef against finalizers..
- it avoids memory / resource leaks regardless of whoever use your API. i.e. it makes garbage collection collect your resources, isn't that nice?
- it has no performance impact if you call Dispose explicitly
- it's 3 line of code to implement properly...
therefore I am just completely nonplussed by your... reluctance about them...    
|
|
|
|
|
I just don't have a good enough justification to use because it doesn't prevent resource leaks - win32 does that, as I said.
I've never seen .NET even call finalizers 99% of the time until just before process exit.
Which means your VB developer who is not using anything like using(var brush = ) is still creating a ton of handles that will remain uncollected for the lifetime of the app. And GC has no way of knowing when GDI is out of handles. So it just lets them get eaten, even with your finalizers.
Until your proc exits. At which point win32 cleans up anyway. Now tell me I'm wrong about any of this?
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
codewitch honey crisis wrote: I just don't have a good enough justification to use because it doesn't prevent resource leaks - win32 does that, as I said.
This class is potentially leaking, and Win32 is NOT magically fixing it.
public class Class : IDisposable
{
IntPtr unmanaged;
public Class()
{
unmanaged = Marshal.AllocHGlobal(10);
}
public void Dispose()
{
Marshal.FreeHGlobal(unmanaged);
unmanaged = IntPtr.Zero;
}
}
And this class is not leaking and is nicely garbage collected.
public class Class : IDisposable
{
IntPtr unmanaged;
public Class()
{
unmanaged = Marshal.AllocHGlobal(10);
}
~Class() { Dispose(false); }
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
protected void Dispose(bool disposing)
{
Marshal.FreeHGlobal(unmanaged);
unmanaged = IntPtr.Zero;
}
but the real question is... why do you refuse to do implementation 2? What so complicated or costly about it? Why do you so adamantly want to introduce memory leak? That doesn't make no sense!
BTW bonus implementation with explicit memory pressure
public class Class : IDisposable
{
IntPtr unmanaged;
public Class()
{
unmanaged = Marshal.AllocHGlobal(10);
GC.AddMemoryPressure(10);
}
~Class() { Dispose(false); }
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
protected void Dispose(bool disposing)
{
if (unmanaged != IntPtr.Zero)
{
Marshal.FreeHGlobal(unmanaged);
GC.RemoveMemoryPressure(10);
unmanaged = IntPtr.Zero;
}
}
}
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
