VB6 - Cobol of the future?

[bored]

Maybe if you're an amateur ;-)

Actually I do see the benefits to all this managed stuff (and you can do .NET in C++ so it's not a language argument). But it is ironic to be talking about one interpreted script language giving better performance than another interpreted script language when you could use native code. Does C# have _asm?

It's typical of the Java/.NET apologists that they think C++ means scary void pointers all the time, and therefore can't be used to produce reliable code. I was somewhat shocked to learn that neither Java or C# have const types: a major step backwards in reliability terms IMO.

I developed in C++ for several years before moving to Java and I was very happy when I switched. We are paid to deliver functionality, not to boost our egos by using low-level features and then claiming to be smarter because of it.

By the way, both C# and Java are compiled languages, not interpreted. With the current VMs in many cases the C#/Java program will be faster than the one in C++, unless you spend a significant amount of time optimizing your code.

What are const types? C++ has several overloaded meanings of const, I think all of them are present in Java.

[AtW]

Actually I do see the benefits to all this managed stuff (and you can do .NET in C++ so it's not a language argument). But it is ironic to be talking about one interpreted script language giving better performance than another interpreted script language when you could use native code. Does C# have _asm?

I have coded a lot in C/C++ and assembly, and I know how painful debugging for memory leaks and crashes is - very bad. I have now coded in C# solid for almost 4 years and I can say certainly that it saved me at least 2 times timewise. Yet performance is excellent (if you are not stupid).

I actually rewrote one tight loop thing from C# into assembly - nice loop I thought, all in registers, great stuff, but I did get big speed up - turned out I was already disk bound because my C# code was fast enough!

You can call DLLs from C# very easily - so you can write in ASM if you want, but you can use pointers too selectively - this makes it easier to debug, other than that managed code in .NET is very good.

Naturally some libraries are carp - WinForms for example is very poor speedwise, maybe they fixed it in .NET 3.5, I have not tried it.

Oh one more - C#/.NET is not interpreted - bytecode generated by compiler (which is pretty good - I looked at disassembly of code) maps very nicely to x86 architecture, this was one of the things .NET people got better because they knew their primary target, unlike Java people who had to target Sparcs as well as other architectures.

Conclusion: Java sucks, .NET rocks.

Milan.

[AtW]

To give it its carppy due, I did some testing of memory and found no leaks in VB.net. Or at least not that the memory thingy told me about anyway.

Word of the wise - if you have not come across with memory leaks in .NET then you are not writing complex enough applications.

HTH

[xoggoth]

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.

[Churchill]

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.

Yeah, VB for a start!!!

[VectraMan]

No offence, but the argument seems to be "I didn't write very good C++ code, therefore C# is better".

Lots of badly written stuff in C++ for sure (like the thing I'm working on now), but reference counting is not something unique to things like Java and C#. It can easily be done in C++, indeed it's at the core of the way COM works, and gives you the same kind of memory leak protection that you get with Java and C#. It's not hard to implement garbage collection either. The difference is you can choose what technique to use, unlike in Java and C# when you're largely stuck with the one they've given you.

But anyway...

What are const types? C++ has several overloaded meanings of const, I think all of them are present in Java.

In C++ you can specify an object as having a const type, which makes it essentially read only. Member functions are marked as const (which can't change their members), and only const functions can be called on a const object. You can't assign a const reference to a non-const reference, so the const-ness follows through the system.

Quick example:

class Object
{
    void Set(int);
    int Get(void) const;
};

void function(const Object& obj)
{
   obj.Get();       // okay
   obj.Set(1);     // compile error

}

It gives you an extra level of type safety at compile time. A big big omission from Java and C#, and a slightly curious one too for languages that claim to be safer. Much like public, protected and private it helps you track down problems by limiting the number of places where data can be changed, and forces you to think about when and where data is changed and hopefully get it right in the first place.*

Try putting "Java const" and "C# const" into google and you'll find loads of complaints and arguments about it.


*Of course this being C++ you can fudge it by casting away constness. You can also have "mutable" members that can be changed on const objects.

[bored]

Lots of badly written stuff in C++ for sure (like the thing I'm working on now), but reference counting is not something unique to things like Java and C#.

Java and C# do not have reference counting (at least as long as you do not use COM). Reference counting is horribly slow and often causes memory leaks. Garbage collection is faster than malloc()/new, and you can't implement it in C++ unless the compiler supports it.

The Java analogue of the "const" keyword is "final", perhaps that is the reason why you were unable to Google it.

[VectraMan]

Java and C# do not have reference counting (at least as long as you do not use COM). Reference counting is horribly slow and often causes memory leaks. Garbage collection is faster than malloc()/new, and you can't implement it in C++ unless the compiler supports it.

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.

The Java analogue of the "const" keyword is "final", perhaps that is the reason why you were unable to Google it.

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.

[bored]

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.

[VectraMan]

http://en.wikipedia.org/wiki/Garbage...ter_science%29

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.