Vb6 , the Future, and what I have discovered - Page 12-VBForums
Page 12 of 12 FirstFirst ... 29101112
Results 441 to 464 of 464

Thread: Vb6 , the Future, and what I have discovered

  1. #441
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    31,553

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by Schmidt View Post
    Yeah - we had this topic already, so: SCNR (but you guys keep mentioning this alleged "productivity increasing stuff" again and again)...

    Olaf
    Who? I don't want to review this whole thread, but the only recent mention of "productivity increasing stuff" was saying that it was VB6 that was productivity increasing.
    My usual boring signature: Nothing

  2. #442
    PowerPoster
    Join Date
    Jun 2013
    Posts
    3,443

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by Shaggy Hiker View Post
    Who? I don't want to review this whole thread, but the only recent mention of "productivity increasing stuff" was saying that it was VB6 that was productivity increasing.
    Ok, just looking through the last 10 posts, I've already found 3 snippets which don't really suggest to me, that you are convinced that VB6 is sufficient as it is.

    Quote Originally Posted by Sitten Spynne View Post
    ...What I see is a consensus VB6 developers would like to learn a language "exactly like VB6" to the extent that new features should be rejected ...
    The above sounds as if it is a bad thing, that "new features are rejected" - my point being: there are no new features which are worth talking about (language-wise, not library-wise).

    Quote Originally Posted by Niya View Post
    ... better hardware came along and made all of that unnecessary, which is one of the pitfalls of staying too long in outdated tech...
    The above suggesting, that we use "outdated tech" (which is entirely wrong - COM is the base for the new UWP - and "native-compiling" is currently promoted as one of the most important features of the new .NET-core 2.0).
    VB6 already supports all of that, so it's not "outdated tech" (seems to me, that .NETers who currently don't use the new .NET-core 2.0 and don't write UWP-stuff - are using outdated tech).

    Quote Originally Posted by Shaggy Hiker View Post
    ...People are doing some amazing stuff with VB6, but they are doing it by extending the language and really getting into it. The basic stuff is simple....beyond that...is it really?

    And also your quote above suggests the "same old, same old" (VB6 is good only at the "simple things", not with the "complex ones").
    Your statement avove clearly suggests to me, that there is "something out there, something magical" (which can make also the complex things easier).

    You seem to have experienced that "magic" in some tool I guess - so which one ist it?
    And can you give a small example for the "magic" whilst solving a more complex problem?

    Shaggy, I truly don't try to "rile you all up" here - it's just that I so far never came across an example in the last years,
    which truly impressed me (whilst looking at and experimenting with other languages) - I've had the VB6-equivalent immediately in mind for all the new "code-snippets" I've seen.

    Olaf

  3. #443
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    31,553

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by Schmidt View Post
    Ok, just looking through the last 10 posts, I've already found 3 snippets which don't really suggest to me, that you are convinced that VB6 is sufficient as it is.
    If you mean me specifically, then you have misread or misunderstood those posts. I have no opinion one way or another as to the sufficiency of VB6, nor do I care. I used the language a long time ago. I still have programs running in that language. I don't use it now. If I go back to it, I go back to it, and I'd be completely indifferent either way. Until people on this forum started talking about it, I assumed that everybody felt that way.
    My usual boring signature: Nothing

  4. #444
    PowerPoster
    Join Date
    Jun 2013
    Posts
    3,443

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by Shaggy Hiker View Post
    I have no opinion one way or another as to the sufficiency of VB6, nor do I care.
    Then I apparently misunderstood your statement:
    "...they are doing it by extending the language and really getting into it. The basic stuff is simple....beyond that...is it really?"

    That somehow reads, like I wrote already, as if we are *in need* to "extend the language" (to be able to tackle "the advanced stuff").

    I'm fine, when you don't want to explain your statement further -
    but would appreciate a few more comments, how you wanted the thing to be understood...
    <shrug>

    Olaf

  5. #445
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    31,553

    Re: Vb6 , the Future, and what I have discovered

    Yeah, by that definition of extending it, I can see how you read it. You aren't changing the language itself, so it isn't an extension in that regard. I suppose somebody might say that an OCX is an extension, but that isn't what I meant, either.

    When I got into VB5, I had a book that had all the functions (at least it seemed that way, it was pretty massive, but I don't have it any longer). The way things like threading are being done didn't appear to be in the canon of VB6 as envisioned by MS. People then went and worked out how to use VB6 to do multi-threading at a time when MS didn't appear to even acknowledge that it was possible in the language. That's what I meant by extending it: Getting it to do things that MS wasn't stating it could do. I suppose that isn't technically extending the language, as it used features already present, but it did appear to push the bounds that MS had loosely set.

    I meant it as a compliment to those people who are delving into every nook and cranny in the language, nothing else. I suppose that makes it ironic that you took it as you did. Sometimes, the flatness of the written language lets us down.
    My usual boring signature: Nothing

  6. #446
    PowerPoster
    Join Date
    Jun 2013
    Posts
    3,443

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by Shaggy Hiker View Post
    People then went and worked out how to use VB6 to do multi-threading at a time when MS didn't appear to even acknowledge that it was possible in the language.
    That's what I meant by extending it: Getting it to do things that MS wasn't stating it could do.
    JFYI...
    VB6 was built to officially support "save to use threading, without the need to write any synchronization-code"...
    Over those well-known COM-threads, which are fired up with one (or more) Object-Instances that run on it - and then work in so called "Single-Threaded-Apartments" (STAs).
    For better isolation (to better support "synchronizied cross-thread-access"), each of these Threads was using a fully separated (isolated) Memory-Allocator
    (the so called "Thread-Local-Storage" - TLS).

    There even was an official VB6-Demo for that approach, provided by MS (the wellknown "Coffee-example"):
    https://msdn.microsoft.com/en-us/lib...(v=vs.60).aspx

    Quote Originally Posted by Shaggy Hiker View Post
    I meant it as a compliment to those people who are delving into every nook and cranny in the language, nothing else. I suppose that makes it ironic that you took it as you did.
    I'm not offended, or "enraged" or something - but these are "publically visible threads", read by a lot of people -
    who then form their opinions more on "the gut-feeling" they take with them (after leaving the thread)...
    (which could be an entirely wrong one, when they read too many of those "VB6 == stone-age" comments).

    So I'm not writing "to get something off my chest" personally - I write more for "those guys out there".

    I also have absolutely no "bad feelings" towards .NET ... it's "just another language+platform" (like Java) -
    one which (for my personal taste) has disadvantages (like e.g. the Garbage-Collector), which do not outweigh
    the advantages (as e.g. those inherent in the Garbage-Collector ...
    (since it allows "mass-instantiations, followed by mass-destruction" of hundreds of thousands of small class-instances
    *much* faster than VB6 - due to the concepts and interactions of the VM and the GC).

    Olaf

  7. #447
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    31,553

    Re: Vb6 , the Future, and what I have discovered

    I've always been puzzled by the GC stuff. This has never had any noticeable negative impact on any .NET program I have ever seen. I realize that it would have a potentially devastating impact on real time games, but I wouldn't think that would be even the top reason not to use a managed language for that type of program. When it comes to LOB applications, which is all I write, I would think it likely that the GC NEVER runs during the operation of the program, which is pretty efficient.
    My usual boring signature: Nothing

  8. #448
    PowerPoster
    Join Date
    Jun 2013
    Posts
    3,443

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by Shaggy Hiker View Post
    I've always been puzzled by the GC stuff. This has never had any noticeable negative impact on any .NET program I have ever seen.
    If you deal with it correctly - or don't use "loads of class-instances" (where a GC-run might kick-in later, at an inconvenient time),
    then it won't (have a negative impact).

    It's perhaps not that often, that you encounter such scenarios "at App-Level" - but when you are a "Library-Author" (who wraps C-Dlls) -
    then "destroy-order" is important (e.g. when you'd wrap the flat GDI-API or the SQLite-API behind .NET-Classes).

    In these cases you cannot "blindly trust" the GC with disposing your GDI-hPen-ClassInstance or your GDI-hDC-ClassInstance
    in the right order (with regards to the "Handle-freeing").

    Olaf

  9. #449
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    3,638

    Re: Vb6 , the Future, and what I have discovered

    Pfff, geez. I'm particularly slow at times.

    As I was re-reading through a couple of things in this thread, I just "got" Shaggy's pun in post #403. Geez, I took him literally and started a discussion on code volume metric. LMAO.
    Any software I post in these forums written by me is provided “AS IS” without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. Please understand that I’ve been programming since the mid-1970s and still have some of that code. My contemporary VB6 project is approaching 1,000 modules. In addition, I have a “VB6 random code folder” that is overflowing. I’ve been at this long enough to truly not know with absolute certainty from whence every single line of my code has come, with much of it coming from programmers under my employ who signed intellectual property transfers. I have not deliberately attempted to remove any licenses and/or attributions from any software. If someone finds that I have inadvertently done so, I sincerely apologize, and, upon notice and reasonable proof, will re-attach those licenses and/or attributions. To all, peace and happiness.

  10. #450
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    5,621

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by Schmidt View Post
    In these cases you cannot "blindly trust" the GC with disposing your GDI-hPen-ClassInstance or your GDI-hDC-ClassInstance
    in the right order (with regards to the "Handle-freeing").
    You're not supposed to rely on the GC to free OS resources like GDI objects and file handles. The correct way to handle this is to wrap these OS objects in a managed object and implement the IDisposable interface and a finalizer. The Dispose method of the IDisposable interface is meant to be used to explicitly free unmanged resources.

    And if you're coding against the raw Win32 API without wrappers then the GC has no relevance. You would be using the same patterns as anyone using the Win32 API in any other language or runtime. IE, you would be freeing things explicitly, eg. CloseHandle, DeleteObject etc.
    Last edited by Niya; Feb 14th, 2018 at 10:01 AM.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena


    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. -jmcilhinney

  11. #451
    PowerPoster
    Join Date
    Jun 2013
    Posts
    3,443

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by Niya View Post
    You're not supposed to rely on the GC to free OS resources like GDI objects and file handles. The correct way to handle this is to wrap these OS objects in a managed object and implement the IDisposable interface and a finalizer. The Dispose method of the IDisposable interface is meant to be used to explicitly free unmanged resources.
    Sure - you will have to know (and think) about that - and correctly implement your wrapper-stuff with that.
    And as a convenience, there's even the "Using"-Block you could apply, which does the "disposing" automatically at the end of the Using-block.

    So, when you are using a "Wrapper-Class for a flat-API" from the .NET-framework
    (like e.g. the httpClient - which wraps Socket-APIs and -Handles underneath) you could do this:
    Code:
    using(var client = new HttpClient()) {
        //do something with http client
    }
    Am I right?

    Olaf

  12. #452
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,452

    Re: Vb6 , the Future, and what I have discovered

    Hahaha you picked, perhaps by luck, the absolute worst example and I want to beat someone at Microsoft with a club for it.

    NORMALLY you would be right. The onus is on a .NET developer to check if the types she creates implement IDisposable, and if so a using block is a good way to safely manage them. Otherwise, it's the dev's job to make sure Dispose() gets called on it at some time. It's sort of like they reintroduced us to malloc() and free(), don't get me started on how much I hate the IDisposable pattern.

    OK, but HttpClient is weird. The object itself hides the fact that most of its state is static, so if you create 100 HttpClient objects, they're all sharing the same internal state objects, with some infrastructure to keep everything straight.

    But because it's this weird half-static half-instance kind of object, that means calling Dispose() in it is really bad. There are some bits of information related to the socket states it was managing that aren't static, but could be, so it's not safe for Dispose() to try and actually clean them up: it's better for it to let them time out and die on their own. BUT. This means if you're creating bunches of HttpClient objects, doing one thing with them, then Disposing like a good developer, you end up with a ton of sockets just hanging out in a state where nobody can do anything with them until they time out, because if an instance didn't explicitly open that socket it's too afraid to terminate it. Bleh.

    So you're supposed to make just one HttpClient object and use that for everything. What happens then is if you're using it heavily and it starts to notice sockets backing up, it goes ahead and cleans itself up. Since it's the only one around apparently it can do that, I don't know. This isn't even in the documentation, you have to follow smart people on Twitter and find out via blogs.

    By analogy with COM:

    It's like MS decided to make AddRef() for this object set up a lot of instance-local stuff, but also store some things in a static context that'll be shared by multiple instances. So then they made Release() get rid of the instance-local stuff, but only the static stuff that has ONLY been touched by this object. So if you call AddRef() twice, some percentage of your static state can't be cleaned up by Release(). That percentage gets bigger every time you call AddRef(). The only solution is to only ever request one instance, and only call AddRef() once, even if you're using it in multiple places.

    Thanks, Microsoft. I want to stress again: this is NOT normal IDisposable logic, and as far as I know this is the only type in the framework with this specific behavior. EVERY other time MS wanted us to just use one instance of an object, they made the whole object static (which makes it behave like a Module, really.) Or they implemented the Singleton pattern. But they messed up HttpClient really badly!
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

  13. #453
    PowerPoster
    Join Date
    Jun 2013
    Posts
    3,443

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by Sitten Spynne View Post
    Hahaha you picked, perhaps by luck, the absolute worst example and I want to beat someone at Microsoft with a club for it.
    Nah, not by luck (you should know me in the meantime <g>)...

    Because I was going to post this here in reply:
    https://aspnetmonsters.com/2016/08/2...tpclientwrong/

    But you beat me to it (and thanks for giving a bit more background-info, which the above link also sheds some light on).

    That said - the question remains, why MS "****ed up" in this case?
    (could be, that it was "a C++ team, more familiar with COM" who wrote the C# wrapper)

    The COM-implementation of WinHttp does not show such a weird behaviour.

    Olaf

  14. #454
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,452

    Re: Vb6 , the Future, and what I have discovered

    I don't know why HttpClient displays this particular behavior. There are a couple of other ways to go about making HTTP requests in .NET that are older and clunkier but behave like you'd expect. I think what happened based on some vague statements I've seen is all of the old things use some particular COM/WinAPI stack, but HttpClient uses some newer stack that showed up sometime in the Win7/8 timeframe. I'm suspicious something about that stack is related to WinRT/Metro/UWP/whatever they call it next year, because they could have just added new members to the older types if the only goal was "bring new asynchronous patterns to the HTTP experience". So they probably designed the initial implementation for some super-limited environment like Windows Phone and didn't think the implications all the way through? I don't know, and we'll probably never get the story.

    I experienced something similar once when I was the person wrapping a C API. There was a callback I had to provide a delegate to, but the API was bad and didn't have a method to tell it to stop calling the callback. If you called Dispose(), this was OK, because I went about freeing the handle. Unfortunately I was having to write an object that referenced the object that held the handle. This is where it gets tricky.

    If you call Dispose() on my outer object, everything's peachy. I Dispose() the inner object, and it frees its handle, and everyone's happy. If you forget to call Dispose() on my outer object, we get into the Twilight Zone. That means, at some point, the Garbage Collector's going to destroy my outer object. I had a Finalizer, which is like an emergency "you forgot to call Dispose()" hatch. HOWEVER, in this case it's very, very pathological. Let's say the GC decides to destroy my outer object first. An important rule of finalizers is "do not touch other .NET objects you reference, for the order of finalization is non-deterministic". That means the only thing it's safe to touch is your unmanaged handles, since the GC won't mess with them. At "the end of the program", when everything is closing, all finalizers are going to get called, but you don't know what order. It's a mess.

    So, I can't dispose the inner object because I'm worried it might not really exist anymore. That made the finalizer for the outer object mostly useless, but it had some other things to do that were worth doing. Now, what if that inner object isn't dead yet? Remember that callback? The unmanaged object's out there, and it decides to call the callback. That calls a method on the inner object. That causes it to raise an event, which the outer object was subscribed to. What's an event in .NET? A delegate call. So it tries to call the event handler on the outer object... which has been destroyed by the GC... and... oh no. App crash time.

    You can't detect that case. It's supposed to not be able to happen. "What if the GC collected a thing I reference?" can only happen during finalization, and that's why they urge you to not write finalizers. So when you try to touch a pointer to an object the GC has already collected, it's WORSE than a null reference. You can detect a null reference and avoid it. Even TRYING to see if this object is null will crash you.

    I wrote code for "not-programmer" customers. Forgetting to call Dispose() is what they do best. I forget why, but there were very good reasons at the time why I couldn't collapse the inner and outer object into one object, thus making it safe to free the handle. I think, today, with 8 years more experience, I'd tell my boss his pretty architecture had to go to make the code safer. But that particular type was shared by a ton of code and we were very worried about making breaking changes. Writing APIs does that to you.

    So I had to make a compromise, break the rule, and try calling Dispose() on the inner object. It meant when my users forgot to call Dispose(), 99% of the time nothing bad happened and they didn't leak memory. 1% of the time, it crashed, and we heavily bolded the documentation that told them to use Dispose(). And if they closed the application without proper Dispose() logic, it crashed 100% of the time, real amazing how consistent it was. Neat trick though: an app crash during shutdown is completely silent, it doesn't raise a dialog or even hit the Event Log.

    So help me, if someone designs a VB7 and puts something like the Disposable pattern in it, the club-beating I mentioned before will also be reserved for that person. It is the most awful aspect of .NET and only works if the C/COM APIs you are consuming follow very good rules. Luckily for us, the GDI stuff follows those rules.
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

  15. #455
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    5,621

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by Schmidt View Post
    So, when you are using a "Wrapper-Class for a flat-API" from the .NET-framework
    (like e.g. the httpClient - which wraps Socket-APIs and -Handles underneath) you could do this:
    Code:
    using(var client = new HttpClient()) {
        //do something with http client
    }
    Am I right?

    Olaf
    Yes:-
    vbnet Code:
    1. '
    2.         Using b As New SolidBrush(Color.Blue)
    3.             DoBrushStuff(b)
    4.         End Using

    Using blocks are implemented by the compilers of both VB.Net and C#. The MSIL code emitted by the VB.Net compiler for the above would be equivalent to writing this:-
    vbnet Code:
    1. '
    2.         Dim b As New SolidBrush(Color.Blue)
    3.  
    4.         Try
    5.             DoBrushStuff(b)
    6.  
    7.             'Finally blocks will ALWAYS execute
    8.             'before the current method returns.
    9.         Finally
    10.             If TypeOf b Is IDisposable Then
    11.                 DirectCast(b, IDisposable).Dispose()
    12.             End If
    13.         End Try

    The two main things are the check for IDisposable interface and the finally block. The IDisposable check is pretty straightforward. It ensures that it's safe to use Using blocks with objects that don't implement the IDisposable interface. The finally block makes it possible to return from the current procedure from within the Using block without having to worry about the object not being disposed:-
    vbnet Code:
    1. '
    2.         Using b As New SolidBrush(Color.Blue)
    3.             DoBrushStuff(b)
    4.  
    5.             'The compiler wraps the Dispose call within a Finally block
    6.             'so Dispose will be called even if we return from inside the block
    7.             Return
    8.  
    9.         End Using

    I noticed you used C# in your example. In case you're more comfortable with that language here is the equivalent code in C#:-
    Code:
                using (SolidBrush b = new SolidBrush(Color.Blue))
                {
                    DoBrushStuff(b);
                }
    Code:
                SolidBrush b = new SolidBrush(Color.Blue);
    
                try
                {
                    DoBrushStuff(b);
                }
    
                finally
                {
                    if (b is IDisposable)
                    {
                        ((IDisposable)b).Dispose();
                    }
                
                }
    EDIT:

    I forgot to mention that I took some liberties with those examples. For instance there might be some null checking going on and the check for the IDisposable interface could be done by the compiler itself instead of emitting code to do it at run time.

    However, for the purposes of understanding what a Using block really is, it is sufficient. These minor differences wouldn't change the behavior of Using blocks in any significant way so there is no need to be precise. Besides, the minor details could theoretically change between compiler versions but the core ideas would remain the same.
    Last edited by Niya; Feb 16th, 2018 at 01:56 PM.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena


    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. -jmcilhinney

  16. #456
    PowerPoster
    Join Date
    Jun 2013
    Posts
    3,443

    Re: Vb6 , the Future, and what I have discovered

    So, when you are using a "Wrapper-Class for a flat-API" from the .NET-framework
    (like e.g. the httpClient - which wraps Socket-APIs and -Handles underneath) you could do this:
    Code:
    using(var client = new HttpClient()) {
        //do something with http client
    }
    Am I right?


    Quote Originally Posted by Niya View Post
    Yes...
    You missed the point I was trying to make Niya (I know already how the using-Block works).

    Sitten already catched the ball quite nicely above, ending with:
    "So help me, if someone designs a VB7 and puts something like the Disposable pattern in it, the club-beating I mentioned before will also be reserved for that person."

    A language (or compiler), which organizes its "automated Memory-deallocations - and destructor-calling" without having to resort
    to a separated (parallel running) GC-instance, is IMO better off (because the whole IDisposable-mess can be avoided from the get go).

    Olaf

  17. #457
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    5,621

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by Schmidt View Post
    You missed the point I was trying to make Niya (I know already how the using-Block works).

    Sitten already catched the ball quite nicely above, ending with:
    "So help me, if someone designs a VB7 and puts something like the Disposable pattern in it, the club-beating I mentioned before will also be reserved for that person."

    A language (or compiler), which organizes its "automated Memory-deallocations - and destructor-calling" without having to resort
    to a separated (parallel running) GC-instance, is IMO better off (because the whole IDisposable-mess can be avoided from the get go).

    Olaf
    Well you got me there. I'm with Sitten on this. I'm not too fond of the IDisposable pattern either. The problem I run into quite often is the finalizer running on it's own thread which causes all kinds of chaos when dealing with complicated destruction scenarios. There are so many things you just can't do in a finalizer. I can't recall specifics off hand but I do remember writing classes in the past that had tricky disposal needs and I had to go to war with the finalizer to make them work.

    However, I still prefer the mark and sweep garbage collector over COM's reference counting strategy, the biggest reason being circular references. This one caused me a few headaches in VB6. I tend to write a lot of classes that work that way. Mark and sweep garbage collectors don't require that you care about circular references but reference counting garbage collectors do. It's not a deal breaker for me though. I can work with both types just fine. I just like mark and sweep better.

    As for alternatives for the IDisposable pattern that can work with a mark and sweep collector like the CLR's, I'll let smarter people than me ponder on that. These things aren't really a big deal for me. I'll work with whatever I got.

    It might sound strange but of all memory management strategies, I find manual management, like you would do in C(malloc/free etc) or the Win32 API(GlobalAlloc, HeapAlloc, HeapFree etc) to be the most appealing. It's an outdated mode of thinking, I know but there is something about having full control that makes it attractive to me.
    Last edited by Niya; Feb 16th, 2018 at 09:13 PM.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena


    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. -jmcilhinney

  18. #458
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,452

    Re: Vb6 , the Future, and what I have discovered

    I don't mean to imply that I don't like garbage collection. IDisposable and finalizers are a bad way to have a GC deal with unmanaged code.

    The really good garbage collected languages I use don't have a concept of finalizers, or if they do I haven't ever used it. If you use them to deal with unmanaged things, the onus is on you to keep track of your scope/references and manually call cleanup when it's time. As far as I can tell, this is pretty much how VB6 does it. It doesn't know what an HWND is, it just knows you asked for a Long from an API call. Let that Long fall out of scope and it's gone. The end. In a lot of languages, garbage collection works like that, it's just instead of "gone" happening immediately after going out of scope, it happens "at some point when the GC decides on it".

    So in the end, .NET has the same rules as a language without a GC: if you need to clean up, do so before dropping your last reference to the thing. They tried to give you an escape hatch if your user forgets. Turns out in very complex scenarios, that makes bigger problems than memory leaks. Lesson learned: follow the rules. Sometimes we can't follow those rules, because we have to use some cruddy third-party API that doesn't follow them itself.

    That's not the GC's fault. You can't tell me there haven't been some "interesting" VB6 threads about some vendor-provided COM object that does stupid things that require not following VB6's rules to make it happy. Careless programmers create interesting problems. Then they sell those interesting problems to businesses who have no other choice. That's the "fun" of enterprise development.

    Obj-C lets you opt in to reference-counted garbage collection, most people do unless they have good reason to believe they can outperform it. Part of the Obj-C API design assumes you use an MVC pattern. Views and ViewControllers always have a circular reference to each other. So how's that work? Obj-C has a 'weak' keyword. If you use that as part of your variable declaration, then the variable does NOT add a reference to the reference count. This means you have to be a little more careful about checking for Nil, but that's always "a rule" so I reference previous statements about following them. As far as I can tell, finalization is deterministic in Obj-C.

    .NET has a concept of a WeakReference, but no language makes it a keyword. I think this is because the .NET GC already detects and deals with circular references. That means WeakReference tends to get used for special-cases. It's not a good idea for handling unmanaged things, anyway.

    So don't get me wrong. I like the idea of a GC and many successful modern languages are built with one. You can overtax them and it can become a burden, but computers today are very powerful and we've learned a lot about GC design. Things that used to cause the .NET GC to display visible performance problems are now almost invisible due to both. There are issues like boxing and unboxing that used to be murder for us and now the costs are so trivial we do them without concern. It's not a bad idea to have a GC. Especially since most of your tasks don't involve you directly using unmanaged resources.

    But boy howdy, if you need to work with unmanaged resources, you want determinism. As a developer, you need to have a really good understanding about how and when your stuff gets destroyed. .NET Standard 2.0 allows you to write your own GC and compile that into your programs. I don't doubt we'll see a more deterministic GC by 2019.
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

  19. #459
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,452

    Re: Vb6 , the Future, and what I have discovered

    Also this etch-a-sketch machine was a microcontroller running .NET in 2009. Way earlier than I remembered.
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

  20. #460
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    31,553

    Re: Vb6 , the Future, and what I have discovered

    That's pretty cool, but didn't you post it in the wrong thread?
    My usual boring signature: Nothing

  21. #461
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,452

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by Shaggy Hiker View Post
    That's pretty cool, but didn't you post it in the wrong thread?
    I... actually don't know. I think a page or so ago dilettante said something about microcontrollers and there was a bit of discussion about it. There's about 3 different threads with the same kind of stuff going on in them. I swear I looked back and it was there? But it was in between mugs of coffee in the morning so maybe I messed up.

    Anyway, that video crossed my view as I was digging through some really old bookmarks and I honestly didn't think stuff like this was happening until 2013 or later.
    Last edited by Sitten Spynne; Feb 17th, 2018 at 09:10 PM.
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

  22. #462
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    31,553

    Re: Vb6 , the Future, and what I have discovered

    Yeah, I'm not about to go searching through the various threads, either. I was thinking this made more sense in the thread about things written in .NET, but now that you mention it, I do remember that microcontroller post, and it doesn't seem likely that it was in the other thread.
    My usual boring signature: Nothing

  23. #463
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    5,621

    Re: Vb6 , the Future, and what I have discovered

    Sitten's post was in reference to this post, from a page ago.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena


    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. -jmcilhinney

  24. #464
    PowerPoster
    Join Date
    Jun 2013
    Posts
    3,443

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by Sitten Spynne View Post
    So in the end, .NET has the same rules as a language without a GC:
    - if you need to clean up, do so before dropping your last reference to the thing.
    No - and that's exactly what I'm trying to explain the whole time...

    When you have a Class-System which is build around RefCounting, then:
    - no GC is needed at all
    - Memory-Cleanups will happen immediately when Class-Instances go out of scope
    - the User of such a Class will have *no* obligation to call a dedicated Cleanup-Routine (to free Class-internal Handles)

    Please look at the following (working) VB6-example (which is using the "old GDI-wrapper-Classes of the RC5"):
    Code:
    Option Explicit
    
    Private Sub Form_Click()
      Dim DIB As cDIB, DC As cDC 'define two Class-Variables with local scope
      
      Set DIB = New_c.DIB(320, 240) 'create the DIB-instance (using a Constructor)
          DIB.Fill vbYellow 'ensure a BackGround-Fill on the complete DIB-area
         
      Set DC = New_c.DC(DIB) 'create a DC-instance (using the Constructor, to select the DIB)
          DC.DrawGradient vbGreen, vbBlue, 0, 0, DIB.dx, 28, True 'draw a Gradient at the top
          DC.SetFont "Times New Roman", 32, True, True, vbRed 'select a Font (bold, italic, red)
          DC.DrawText "Hello World", 0, 0, DIB.dx, DIB.dy, vbCenter, True 'centered Text-Out
          
      Set Me.Picture = DIB.Picture 'flip what was drawn on the DIB to the Form-Picture
    End Sub '<- at this point, the local ClassInstances are dead, and everything (memory, and handles) were destroyed properly already
    Producing this output:


    The above will show no "GDI-Handle-leaking" - and also no "Memory-leaking" (no matter how fast or often you Click on that Form) -
    instead the User can be absolutely sure, that when he leaves the SubRoutine, everything is as it was before (Memory and HandleCount-wise).

    That's how things can work with COM-based "RefCounting wrapper-classes for Flat-APIs".
    (with no obligation on the user of such Wrapper-classes, to call any extra-cleanup-methods).

    With a GC-based system, you cannot acccomplish the same thing (with the same guarantees for "immediateness").

    Olaf

Page 12 of 12 FirstFirst ... 29101112

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Featured


Click Here to Expand Forum to Full Width