|
Rahithi wrote: VB & VB.NET?
VB6 was not a real language. VB.NET is, sort of.
Rahithi wrote: VB.NET & C#?
VB.NET is loosely typed, and carries a lot of legacy VB garbage ( easily removed, never use the VisualBasic namespace ). C# is strongly typed, is a new language with no legacy stuff, and is subject to an independent standard. IMO, VB.NET exists to make the VB6 crowd happy, C# is meant to be a new and compelling language.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
The Big difference is between VB and VB.NET. If you can, use the latter.
AFAIK VB.NET & C# are functionally equivalent, so it's a matter of taste (I know everyone, here will disagree...).
Bottom line: there very good are VB (VB6 I mean) programmers, while there are very poor C# (and C++) programmers, though this is the exception, not the rule.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
CPallini wrote: (I know everyone, here will disagree...).
That's mostly true. I'd summarise that the stuff C# has that VB does not, I'd prefer over the stuff VB has and C# does not, and that VB contains more dangerous traps for the inexperienced.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Don't let your C++ background drag you down...![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
I don't see that it is. There are ways in which C# is totally different to C++ ( I'd say in almost every way it's more like Java ). I still like C#. I do admit I hate VB.NET for it's awkward syntax, an opinion I hold to from my C++ background, but that's not something I really commented on here - the syntax is a matter of personal preference.
Christian Graus - C++ MVP
'Why don't we jump on a fad that hasn't already been widely discredited ?' - Dilbert
|
|
|
|
|
Christian Graus wrote: I don't see that it is.
Was mainly a joke, don't blame me for that.
Christian Graus wrote: I'd say in almost every way it's more like Java
Christian Graus wrote: I still like C#.
I agree on these.
P.S. C++ it is my background too.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Rahithi wrote: what is the main differences b/w VB & VB.NET?
VB.NET is fully object oriented, while VB6 is not.
VB.NET uses the .NET framework, while VB6 uses it's own runtime library.
VB.NET is still developing further, while all development of VB6 has stopped.
VB.NET is one of the .NET languages, which implies that:
- it uses the fast memory management of .NET, including a garbage collector instead of reference counting.
- it uses a JIT compiler to make the final step of compilation specific for the processor it is running on, instead of compiling for a generic processor.
- it can use all the classes in the .NET framwork, which is far more than the VB6 runtime library.
Rahithi wrote: can any one tell me the difference b/w
VB.NET & C#?
They are just two different languages. As they both use the .NET framework, there is very little difference in what you can do with them.
VB.NET is a bit easier to use than C# on a beginner level, especially if you come from VB6. To write good code on a more advanced level, though, VB.NET requires even more knowledge than C#, as the VB.NET compiler lets you do some pretty stupid things that the C# compiler will warn you about.
---
Year happy = new Year(2007);
|
|
|
|
|
Very good answer, I agree almost completely.
Guffa wrote: it uses the fast memory management of .NET, including a garbage collector instead of reference counting
AFAIK reference counting is COM stuff, not VB6. Furthermore I don't think memory management of .NET is any faster than COM one(maybe I'm wrong...).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
CPallini wrote: AFAIK reference counting is COM stuff
VB6 was almost entirely based on COM. All the reference counting is still there, just hidden under the covers, so to speak. It was very easy for the inexperienced or unaware to create memory leaks in VB6...
|
|
|
|
|
CPallini wrote: AFAIK reference counting is COM stuff, not VB6.
Oh, yes, there is reference counting in VB6. That's how it knows that it can free an object once you removed the last reference to it.
CPallini wrote: Furthermore I don't think memory management of .NET is any faster than COM one(maybe I'm wrong...).
I saw a page with a comparison between different languages not long a go. I posted a link to it in some thread here. If I remember correctly, it showed that allocating objects in .NET was about ten times faster than in VB6.
Update:
I found the thread[^]. I did not remember correctly. Using objects in .NET is about 100 times faster than in VB6.
---
Year happy = new Year(2007);
|
|
|
|
|
Guffa wrote: Oh, yes, there is reference counting in VB6. That's how it knows that it can free an object once you removed the last reference to it.
I agree, however, it's transparent to the VB programmer.
Guffa wrote: I saw a page with a comparison between different languages not long a go. I posted a link to it in some thread here. If I remember correctly, it showed that allocating objects in .NET was about ten times faster than in VB6.
Update:
I found the thread[^]. I did not remember correctly. Using objects in .NET is about 100 times faster than in VB6.
I Know that article and, still, I cannot believe it.
I don't disputate the honesty of the benchmarker, but I simply think that real-life well written C++ code outperforms well written C# code (as it happens for plain C over C++ and assembly over C): Java showed how a Garbage Collector speeds up applications.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
CPallini wrote: Java showed how a Garbage Collector speeds up applications.
How did it do that ?
CPallini wrote: but I simply think that real-life well written C++ code outperforms well written C# code
Why ? Why do your thoughts take precedence over a benchmark ?
Christian Graus - C++ MVP
'Why don't we jump on a fad that hasn't already been widely discredited ?' - Dilbert
|
|
|
|
|
Christian Graus wrote: How did it do that ?
in fact java applications are quite slow.
Christian Graus wrote: Why ? Why do your thoughts take precedence over a benchmark ?
Because C++ gives more control to the programmer. It hasn't a garbage collector, it hasn't a JIT.
Of course my thoughts always take precedence over a benchmark (at least to me!) .
Well, to be honest, I think that even the NET chief designer will NEVER affirm that C# outperforms C++ (I thrust him). It's simply impossible.
I have no benchmark on my side, but logic: assembly gives more control and is, at least in principle, more performant than higher level languages. C# goes along the way of giving less control to the software developer and hence it is inherently less efficient than C++ (of course this does not mean that C++ is better, for instance I know no people programming Windows using assembly...).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
CPallini wrote: in fact java applications are quite slow.
No doubt about it, especially the swing part is slow as hell.
WM.
What about weapons of mass-construction?
"You can always try to smash it with a wrench to fix that. It might actually work" - WillemM
|
|
|
|
|
CPallini wrote: Because C++ gives more control to the programmer. It hasn't a garbage collector, it hasn't a JIT.
It doesn't follow that because it has garbage collection it must be slower. Eiffel has GC but also has C++-level performance.
See this case study.http://eiffel.com/executives/case_studies/axa/study1.html[^]
Here's a quote:
"Initially, AXA Rosenberg software developers questioned Eiffel’s ability to perform as fast as C, because of the tradeoff between garbage-collection and speed. Eiffel proved to be not only 10 times faster than C, but also prevented memory leaks – a classic problem in C and C++ programming."
Kevin
|
|
|
|
|
Kevin McFarlane wrote: It doesn't follow that because it has garbage collection it must be slower. Eiffel has GC but also has C++-level performance.
See this case study.http://eiffel.com/executives/case_studies/axa/study1.html[^]
I don't think that was a serious comparison between C and Eiffel performance.
They made a migration of an heterogenous project (mostly developed using FORTRAN) on a different platform (perhaps having much more performing hardware).
While nobody can question the productivity of such migration, that is (at lest to me) by no means a proof that Eiffel outperforms C.
It only shows that the garbage collector didn't affect too much the performance of their system (and usually GC is a very convenient trade-off between performance and memory-leaks headches).
Please note: of course a GC language usually speeds up code-development, we're not questioning about. The matter of this little debate is which language allows greater executable speed.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
I think there are probably a number of things going on here. Undoubtedly the 10 times performance bit was hyped. But the point was that the C developers' intuition about GC was faulty. I'm told that developers often have poor intuition about performance anyway.
CPallini wrote: They made a migration of an heterogenous project (mostly developed using FORTRAN) on a different platform (perhaps having much more performing hardware).
It's not clear whether what's being compared is just the C bit or the whole thing. But presumably there would have been comparisons of just the C bits.
Incidentally, I've had at least two interviews in recent years where the interviewer told me they'd ported an app. from C++ to C# and obtained a performance increase as a result. The Eiffel example could be illustrating a similar effect. I think what's happening here is that the GC languages may make it easier to create good abstractions, due to the separation of concerns and greater simplicity of the languages. Also, there will the efficiency effect of redesign. For example, no doubt that Fortran/C app. would have been faster had it been redesigned in Fortran/C. My interviewers' C++ apps. would have been faster than the originals had they been redesigned in C++.
In the Eiffel case, going from C to Eiffel could lead to better performance due to more efficient code expression, i.e., code sharing due to multiple inheritance and generics, both of which are heavily used in Eiffel.
A few days ago a very experienced C++ and Java developer friend of mine told me how some years ago he rewrote some code consisting of several pages of C in about 20 lines of C++. What's happening here is probably that the greater abstraction possible by C++ enables more concise thought.
Kevin
|
|
|
|
|
Kevin McFarlane wrote: But the point was that the C developers' intuition about GC was faulty
IMHO this is not true.
On the other hand I agree, on the whole, on the remaining sentences, i.e. dealing with big and complex project, developers find themselves more comfortable using higher level languages and then build up better applications.
Anyway this doesn't mean that the higher level language outperforms the lower level one, because even a very complex application, rewritten in plain C (though, maybe, at unreasonable production cost) by skilled developers, will always outperform the same application written with an higher level language (by comparably skilled developers).
So we can say that for complex projects, high level languages are very effective, since with a relatively cheap effort you can develop good software with good performance.
But when performance really matters (i.e. videogames engines, system programming,...) then nothing really compares with low level languages as C.
Cheers
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Hi
I am trying to programmatically test if the windows firewall is enabled or not.
I guess there is a value for this in the registry but I wanted to ask here for any better solutions to do this test.
Maybe WMI if posible?
Any Thoughts?
Thanks
When people make you see red, be thankful your not colour blind.
|
|
|
|
|
Take a look at the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy key. Two subkeys, Domain and Standard Profile. Under my StandardProfile there's a DWORD called EnableFirewall, 1 if enabled, 0 if disabled.
You might also want to take a look at this[^] article. C++ I know but everyone should get their feet dirty once in a while 
I have no idea what I just said. But my intentions were sincere.
|
|
|
|
|
Hi,
I got the following code in a module, cause I want to b eable to use it in any form necessary. The statIcon is a statusbarpanel .
Public Sub ConnStatusIcon(ByVal ConnState As String)<br />
<br />
Dim RedIcon As New Icon(Application.StartupPath & "\Icons\RedLight.ico")<br />
Dim YellowIcon As New Icon(Application.StartupPath & "\Icons\YellowLight.ico")<br />
Dim GreenIcon As New Icon(Application.StartupPath & "\Icons\GreenLight.ico")<br />
<br />
Dim frmNewMain As New frmMain<br />
<br />
Select Case ConnState<br />
Case "Open"<br />
frmNewMain.statIcon.Icon = RedIcon<br />
Case "Closed"<br />
frmNewMain.statIcon.Icon = GreenIcon<br />
Case Else<br />
frmNewMain.statIcon.Icon = YellowIcon<br />
End Select<br />
MessageBox.Show(ConnState)<br />
<br />
End Sub
But if I use it in for example the load event of the main form like this
ConnStatusIcon(dbConn.State.ToString)
Only the messagebox shows. With the statuspanel nothing happens. If I use the code directly in the load event it works fine. Where am I going wrong?
|
|
|
|
|
SilentBob101 wrote: Dim frmNewMain As New frmMain
This works perfectly. It creates a new instance of frmMain, assuming that such a named class is visible to it. It is reusable only in projects that define this class. It will set properties on this new instance of frmMain. This will have no effect on any other instance of frmMain that may exist, anywhere else in your code. You never show the instance of frmMain you set properties on, so you will never see what you set.
The way to reuse this bit of code is to create a base form class, which you reuse. If you must had a dll that sets the icon ( and it won't work without the icons, so they should then be resources within the dll ), you should be passing the form instance into the dll, so your code can work with the form that is visible.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Ok, this is a little too much for me. I'm just a newbie programmer.
frmMain is my parent MDI form created in design time, it's not a self created class or anything. I know it's a class, just not one I created.
I didn't get to creating dll's yet. It's all self-study, and not much time.
It's got to be something with the way I use frmNewMain or something, I just don't see it. A little more help please?
If I use MessageBox.Show(frmNewMain.Text) it does show the caption text of the form, so that works.
|
|
|
|
|
Like too many people, you've jumped in at the deep end and you're trying to do windows forms programming, when you should be writing console code and learning how object orientation works.
A class is like an object factory. If I create a 'person' class, the idea is to wrap the concept of a person. So, a lot of the time, this means I want more than one 'person' in my code, and I want to wrap that concept, and once I do that, each person is unique. If I have bill and fred in my program, and I rename fred to tom, bill is still bill. In the same way, when you create a new instance of frmMain, you're creating a whole new form. It has nothing to do with the instance of frmMain that called this code, they are two seperate objects. What you're doing is the same as having a house that you want painted, so you buy a new house, and paint that. The old house has nothing to do with what you do the new one.
I assumed this code was in a dll, as you said it was for reuse. If you're a real beginner, I probably shot a whole lot of concepts at you ( like resources ) which made my reply confusing. The core answer is, you need to read about OO. Then, you'll see why this couldn't work. Put this functionality in new class, derived from the base Form class, and derive your form from that. That's how to reuse this code. It could also then go in a dll, quite easily, if you want that in future.
Christian Graus - C++ MVP
'Why don't we jump on a fad that hasn't already been widely discredited ?' - Dilbert
|
|
|
|
|
Does this mean I have to create a hole new form, in a seperate class, and use that as my main MDI form?
Back to chapter 5 it is then 
Translating from English to Dutch doesn't make it any easier either 
--edit--
Turned it in to a function
Public Function ConnStatusIcon(ByVal ConnState As String)<br />
<br />
<br />
Dim RedIcon As New Icon(Application.StartupPath & "\Icons\RedLight.ico")<br />
Dim YellowIcon As New Icon(Application.StartupPath & "\Icons\YellowLight.ico")<br />
Dim GreenIcon As New Icon(Application.StartupPath & "\Icons\GreenLight.ico")<br />
<br />
Dim frmNewMain As New frmMain<br />
<br />
Select Case ConnState<br />
Case "Open"<br />
Return RedIcon<br />
<br />
Case "Closed"<br />
Return GreenIcon<br />
Case Else<br />
Return YellowIcon<br />
End Select<br />
'frmNewMain.statIcon.Parent.Text = "Blablabla"<br />
<br />
End Function
Using statIcon.Icon = ConnStatusIcon(dbConn.State.ToString) where-ever needed.
It's just an excercise, I'll study the rest later.;)
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
