• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!
Collapse

You are not logged in or you do not have permission to access this page. This could be due to one of several reasons:

  • You are not logged in. If you are already registered, fill in the form below to log in, or follow the "Sign Up" link to register a new account.
  • You may not have sufficient privileges to access this page. Are you trying to edit someone else's post, access administrative features or some other privileged system?
  • If you are trying to post, the administrator may have disabled your account, or it may be awaiting activation.

Previously on "VB6 - Cobol of the future?"

Collapse

  • DiscoStu
    replied
    I think this may be the nerdiest thread I've ever seen on here.

    Leave a comment:


  • Churchill
    replied
    Originally posted by expat View Post
    No.

    COBOL is fit for purpose because it is reliable in the extreme. It doesn't make your algorithms easy, but it does protect your data.

    It was invented before there was a Microsoft.

    Hmm.
    I was taking the piss!

    And yes, I know you can get "Cobol for .NET"!

    Leave a comment:


  • AtW
    replied
    Originally posted by VectraMan View Post
    What I mean is that I call CreateThread() if I want a thread (which I think is what you do in C#). That's an API call; not sure why anybody thinks functions of the API should be part of the language.
    Well, printf is also an API call. Why not remove it? Obviously the issue with threads in C++ is that there is no standard way to do threads on all flavours of Unix and on Windows I think it is done differently too - Unix itself I think favoured processes rather than threads, at least until recently, as far as I am aware, Linux was piss poor when it came to threads - Unix guys are just too used to processes rather than threads.

    I don't think you can easily implement gargabe collection in C++ easily - can't be arsed to find out exact details, but I think in environment where you can easily take pointers as a matter of routine then garbage collector can free memory block when it might be used later.

    I don't think they should put GC into C++ - it will never be as good as in C# and people who can't deal with leaks should not touch C++ anyway, it's a dieing language for a very small minority of people. I don't feel sorry I no longer use it to be honest - I like C#.

    Leave a comment:


  • VectraMan
    replied
    Originally posted by AtW View Post
    For your information C++ governing body is urgently trying to add standard threading mechanism to it, because we have entered parallel execution code that needs programmer to do the job - having threads is essential for it.
    What I mean is that I call CreateThread() if I want a thread (which I think is what you do in C#). That's an API call; not sure why anybody thinks functions of the API should be part of the language.

    Re: garbage collection: you could implement it in C++ easily enough, but you'd be using your own customized operator new/delete and a custom ptr container class everywhere. You couldn't just do it automatically for everything without changing the code, like you could if it was built into the compiler.

    Which is the point: In C++ you get full control, which is why it's always going to be the best platform where you need full control. Java and C# makes you use this stuff, and although I'll admit that 99% of the time it isn't an issue, as ATW says sometimes the garbage collection gets in the way. I hope they don't try to put it into C++.

    Leave a comment:


  • expat
    replied
    Originally posted by Churchill View Post
    COBOL.NET

    It's the future, I tell you.
    No.

    COBOL is fit for purpose because it is reliable in the extreme. It doesn't make your algorithms easy, but it does protect your data.

    It was invented before there was a Microsoft.

    Hmm.

    Leave a comment:


  • AtW
    replied
    Originally posted by bored View Post
    They're also trying to add garbage collection
    I think they will probably fail with this one - doubt C++ type would accept garbage collection as a concept.

    It seems to work okayish in .NET, but it is a complete bull that there can't be any leaks with garbage collection - there sure can. Also in heavy multithreading situation garbage collector will stop all threads when cleaning up, there is a setting for multithreaded garbage collection but I found it is buggy in .NET 2.0, so I don't use it - had to rewrite part of SKA to heavily reuse memory - suddenly usage of each core increased considerably as GC had less work to do

    Leave a comment:


  • bored
    replied
    Originally posted by AtW View Post
    For your information C++ governing body is urgently trying to add standard threading mechanism to it, because we have entered parallel execution code that needs programmer to do the job - having threads is essential for it.
    They're also trying to add garbage collection - although I believe that in the first iteration they only plan to add/remove some facilitating features of C++ without mandating a standard GC implementation.

    Leave a comment:


  • AtW
    replied
    Originally posted by VectraMan View Post
    Why on earth should a language have a standard threading mechanism?
    Why to have standards at all? Why not have different size of int and long on different systems, it is soooooooo fun to use sizeof() all the time, genious invention of Kernigan and Ritchie! For your information C++ governing body is urgently trying to add standard threading mechanism to it, because we have entered parallel execution code that needs programmer to do the job - having threads is essential for it.


    Surely the issue here is desktop vs. server app. I've never seen any .NET desktop apps, and everybody here has been saying WinForms is carp. Correct me if I'm wrong but .NET is 99% used on the server end spitting out HTML, whereas things actually run on the desktop are more than likely C++ . I doubt that will change.
    WinForms is crap indeed - performance wise. You can still do the job though, just they could have made it better.

    I am mainly developing tools now that have either web front end or just console based stuff that runs for a long time to prepare output (index) that is useful by front end.

    If C++ is used mainly on desktop then I think it's future is going down because a lot of stuff is moved to the web GUI. C++ is just not the RAD language that one can use, I hated spending time debugging C++ app and I still hate sometimes doing it in C#, but I sure as hell debug less weird issues in C# than I was in C++. Sure I was not great in C++, but most people are not great with it.

    Leave a comment:


  • VectraMan
    replied
    Originally posted by AtW View Post
    I don't think there is even standard threading mechanism in C++.
    Why on earth should a language have a standard threading mechanism?

    As far as I am concerned C++ is a legacy and low OS level language, plus games a rewritten in it - it will stay, but 90% of new stuff won't be in C++: .NET or Java, or for web some Ruby or PHP.
    Surely the issue here is desktop vs. server app. I've never seen any .NET desktop apps, and everybody here has been saying WinForms is crap. Correct me if I'm wrong but .NET is 99% used on the server end spitting out HTML, whereas things actually run on the desktop are more than likely C++ . I doubt that will change.

    Leave a comment:


  • Churchill
    replied
    Originally posted by expat View Post
    Insult to COBOL. It's still going strong, because it is fit for purpose.
    COBOL.NET

    It's the future, I tell you.

    Leave a comment:


  • expat
    replied
    VB6 - Cobol of the future?

    Insult to COBOL. It's still going strong, because it is fit for purpose.

    Leave a comment:


  • AtW
    replied
    Originally posted by VectraMan View Post
    No offence, but the argument seems to be "I didn't write very good C++ code, therefore C# is better".
    I don't think I wrote very good C++ and I only started writing pretty good C# recently, however the point here is that I saved a lot of time by using C# rather than C++ and got 95% of performance: these days the art is to do things in parallel to use multiple cores (8 in my primary server), I don't think there is even standard threading mechanism in C++.

    As far as I am concerned C++ is a legacy and low OS level language, plus games a rewritten in it - it will stay, but 90% of new stuff won't be in C++: .NET or Java, or for web some Ruby or PHP.

    Leave a comment:


  • AtW
    replied
    Originally posted by xoggoth View Post
    What a gloriously GEEKY comment atW!. I really must rewrite my apps to make them more complex! The product requires colourful stuff for kids. Much of it is to do with rendering images and there were several things in that area that one had to avoid in VB6.
    You need to switch to using DirectDraw in your apps - this way it should be pretty fast.

    Leave a comment:


  • VectraMan
    replied
    Still keeping track of references, but in a different way. Traditional reference counting is only slow if you add and release references excessively, though I'll admit you do have the circular reference problem which this sort of garbage collection can solve.

    There's no way of knowing that in C++ either. The function can make an explicit cast to discard const. Also, the function can modify the object if it can obtain a non-const reference to it from some other source. If you need an object to be immutable, all its member fields must be declared immutable in the class definition - there is no other way.
    Well, yes you can abuse it, but const_cast should be the exception not the rule. And yes there are other ways around it in some cases, but that's rare, and the language can't help you with everything a programmer might do.

    Still think it's odd that both Java and C# (which were both based on C++) left out a very useful feature.

    Leave a comment:


  • bored
    replied
    Originally posted by VectraMan View Post
    What do they do then? Keep track of the number of references to an object, and when there aren't any more the object is put on a heap somewhere to be deleted. Sounds like reference counting to me.
    http://en.wikipedia.org/wiki/Garbage...ter_science%29

    Not the same thing by far. As I understand it there's no way of knowing that when calling a function an object passed in won't be changed. Which is the point.
    There's no way of knowing that in C++ either. The function can make an explicit cast to discard const. Also, the function can modify the object if it can obtain a non-const reference to it from some other source. If you need an object to be immutable, all its member fields must be declared immutable in the class definition - there is no other way.

    Leave a comment:

Working...
X