VBForums' new heavy .Net hand

Quote:

---

Also I agree with the whole "if it's started in vb6 and help is needed then help them in vb6 or don't try to help at all" notion too. I also recommend all new projects to be started in vb.net (or other newer language) instead of vb6

---

In principle I agree... in practice, not so much... a lot of it is case by case too.. if they are trying to do something in VB6 that would be better in the long run to be done in .NET.... and they aren't going to lose much (benefits out weigh the costs) then what's wrong with a suggestion of switching to .NET?

But just like most of the other points in this thread, a lot of it is case by case. There's no one perfect answer.

dilettante - what's an even bigger shame is the lack of fundamentals that are seemingly to either being taught less and less or not at all.... "let's jump straight into the code" ... more often I see newbies trying to jump into the Olympic diving pool when they have yet to learn how to swim properly. That's the real shame.

-tg

Quote:

---

Originally Posted by Shaggy Hiker

The thing that protects Esposito is that his code is not valuable enough for somebody to go to the effort of pirating. All protection schemes are based on the assumption that anybody who wants to crack a program will evaluate the effort/reward matrix beforehand. It's not a matter of making it impossible, it's just a matter of making it not worth the time, which can be achieved most easily by making the project only suitable for a niche market. ALL of my programs fall into that category, so I can write in anything I want. I can post the source code on line and nobody will steal it.

No language will protect you if your code is valuable. No protection is worthwhile if your code is not.

---

Believe it or not, all of my software used to be cracked when I made use of a registration key to remove the shareware limitations. Then I started to distribute a limited version of my products as shareware that could not be cracked (simply because some of the code to save the data was not included) and since then my sales have increased significantly.

About twenty different Italian software magazines that are distributed at national level have published my applications on several occasions, for a total of more than 300 publications.

The truth is, hackers are ready to crack anything that is downloaded by a lot of users. My software sells quite well not because it is based on some complicated architecture but simply because people need it to release invoices, store their contacts or videotapes etc.

Until recently, software protection was an enormous headache for me and I didn't even use .NET. Anyway, the main reason why I can't switch to .NET is its dependence on the Framework that, as I said, would cause my sales to tumble.

Then you are in a situation where you are creating something valuable enough to steal, and have to concern your self with theft, a situation that few people share.

If I were you, though with my background, I'd be writing solely in C++. Not only will the code be more portable to different platforms (which may matter some day, even if it doesn't matter now), but it will also be in a language that isn't going to change significantly, because nobody truly controls it. Especially with that widget tool mentioned earlier, there really isn't a good reason to choose any other language. You have learned VB6, and found Delphi easy to master, so C++ would be a minor challenge for you.

As for what a new programmer should learn: They should learn some flavor of .NET or C++. The former has a shorter learning curve and broad applicability, while if you learn the latter, the knowledge gained will make the transition to ANY other language (except perhaps for Lisp) relatively easy.

Quote:

---

MS didn't care about the millions of VB programmers who were unwilling to embrace .NET because they developed native applications for the general public and using an indecently huge framework would have meant shooting themselves in the foot.

---

No, they do care, that is why VB.NET exists and that is why they gave you years to transition over. Had they not created the .NET framework, then people would be complaining that it's a stagnant language and just find something that addresses their needs in today's real world. As mentioned (maybe it was another thread), the world of development is always about change.

If the programmers were unwilling to embrace .NET, then is it MS's fault or the programmers' fault? I'd say it's the programmers' fault, because they made a set of misconceived notions about the language (stable, static, stagnant).

What if others started making assumptions about the operating systems? "Oh, we'll never need anything beyond Windows 2000". Or "We'll never need more than 640K of RAM". :p

Think about it... would we have WCF services in VB6 and COM?

Here I go again (JuggaloBrotha being right of course):

Quote:

---

Originally Posted by mendhak

Think about it... would we have WCF services in VB6 and COM?

---

That's a funny one.

Sure we would, in a sense. If VB.Net hadn't killed VB to force itself on the market we'd have a fully modern VB7, 8, 9, etc. over time.

The funny part is that Windows 7 introduces a new WWSAPI and developer tools to provide native code web services that can interoperate with WCF. Why? Simple, two reasons:

• Even Microsoft doesn't use .Net for real products (Office being the canonical example).
• .Net WCF is too danged slow and memory hungry!

There is a thread in this forum where I gave the link to the Channel9 PDC 2008 session on this.

The good news for VB6ers is that though the tools for using WWSAPI are C++ specific, somebody is very likely to create VB6 tools for WWSAPI soon. PocketSOAP's VB6 WSDL Proxy Generator is already darned cose.

Absolutely. And the next step in the evolution was - wait for it - VB.NET.

I am aware of WWSAPI, but WCF being 'slow'? Please, carpenters and tools ;). WWSAPI was created for different reasons. I appreciate you trying to attribute reasons to them but that's a human tendency to make assumptions. None of those reasons are true, they are cynical speculation. All companies make decisions and the decisions are made for a good reason. It's only someone who disagrees that would say otherwise.

To illustrate it further, I generally do it for Apple based products and technologies, simply because I do not like them.

Now, of course someone could even write a wrapper for WWSAPI or WCF for VB6, but I'm going to use a more robust solution - WCF itself - for my web services, I don't actually plan to wait a few years for Win7 adoption to get my web services out. WCF works very well, of that I can assure you. That graph of course is to be expected. It is native code. But then some context would help. Was it netTcp or wsHttp?

Actually WWSAPI will be back-ported to Vista and XP in a matter of months according to that PDC presenter. ;)

The chart was for HTTP as labeled. The TCP chart from the same presentation shows WWSAPI at around 32,000 operations/second vs. 19,000 for WCF.

Even more interesting was RPC over TCP on the same chart at 77,000 ops/sec. And of course good old DCOM works over RPC. :D

Then there are the even more pronounced differences shown in the memory and CPU cycles consumption comparisons.

I always enjoy the classic Performance comparison of DCOM, CORBA and Web service as well. :p

Quote:

---

Originally Posted by mendhak

No, they do care, that is why VB.NET exists and that is why they gave you years to transition over. Had they not created the .NET framework, then people would be complaining that it's a stagnant language and just find something that addresses their needs in today's real world. As mentioned (maybe it was another thread), the world of development is always about change.

---

If VB6 users had wanted to develop in byte code and depend on a cumbersome virtual machine, they would have switched to Java at least ten years before Microsoft released .NET.

Quote:

---

Originally Posted by dilettante

Actually WWSAPI will be back-ported to Vista and XP in a matter of months according to that PDC presenter. ;)

The chart was for HTTP as labeled. The TCP chart from the same presentation shows WWSAPI at around 32,000 operations/second vs. 19,000 for WCF.

Even more interesting was RPC over TCP on the same chart at 77,000 ops/sec. And of course good old DCOM works over RPC. :D

Then there are the even more pronounced differences shown in the memory and CPU cycles consumption comparisons.

I always enjoy the classic Performance comparison of DCOM, CORBA and Web service as well. :p

---

But can I see where you got it from? I want to read up on it. I probably won't use it, since the performance benefits won't outweigh the maintenance efforts involved, but I should know first.

@esposito: See my comment about cynical speculation.

Quote:

---

Originally Posted by mendhak

But can I see where you got it from? I want to read up on it. I probably won't use it, since the performance benefits won't outweigh the maintenance efforts involved, but I should know first.

---

Of course. Start with Building web services in native C/C++ code – PDC 2008 talk slide deck and demos. The slides contain some of the simpler performance comparisons.

It probably won't help much if you program in .Net though. P/Invoke marshalling overhead will probably cancel much of the benefit.

Quote:

---

Originally Posted by esposito

If VB6 users had wanted to develop in byte code and depend on a cumbersome virtual machine, they would have switched to Java at least ten years before Microsoft released .NET.

---

The first version of .NET was 2002. Ten years prior to that was 1992. Java? That was released in 1995, so VB6 programmers certainly wouldn't be switching in 1992, though that is not the point. The point is that we are working in a field that has ZERO continuity and ZERO stability. If anybody looks back over their careers, if they have any age to them, they can remember all kinds of mini-milestones. There is no mainstream language in use today that is the same as it was 10 years ago, and that includes C++ and C. After all, ANSI-C, the most stable, standardized, language that is in widespread use, got a new revision in 1999, after which it took a little while for the compilers to catch up. By 1997, ANSI-C++ was out, but there were few, if any, fully standard compliant compilers by 2000.

VBx had a long run (though VB6 had a run of only a few years between release and .NET), but that run was only about 7 years, since modern VBx was the leading VB only from VB4 (around 1995) through 2002 when .NET came out (it's still around now, but then, so is COBOL).

Dwell on the past if you will, as you have demonstrated a need for something other than .NET, but keep in mind that you work in a field where you become a fossilized niche player if you stick with a technology for ten years. You came of age in VBx and resent its demise, but had you started in an older language like C, you would STILL have seen it change radically. You need certain things in a language, and it sounds like you've found them. As for me, I have wandered around, and am happier with .NET than with any other language I have used. I have no resentment about change, even as it is threatening to clobber me at the moment (I haven't done web development, yet).

What I find strange about the whole thing is, as Billy Hollies mentioned in an article before (him being a major VB evangelist), The CLR was originally designed for VB (before .nets inception). Obviously as they refined it more it actually became a common language runtime.

Tell me if VBx had not changed to VB.NET but still used a framework and became VB7 with the "Visual Framework" would you still give out? I would argue that many VB6 developers would have moved with heads held high and smugly looked down at java developers and their "inferior" framework. Actually on java, I dont think many developers would move to java as quickly as you think. Java has had more "what its used for" changes than any other language. At least VB in every form stayed true to its goal RAD WIN development.

Quote:

---

Originally Posted by DeanMc

Tell me if VBx had not changed to VB.NET but still used a framework and became VB7 with the "Visual Framework" would you still give out? I would argue that many VB6 developers would have moved with heads held high and smugly looked down at java developers and their "inferior" framework.

---

Possibly, I was unable to emphasize strongly enough the two reasons why I had to drop the idea of switching to .NET. Well, they are (1) byte code and (2) Framework size. It is not a question of looking down on Java developers: to be honest, I couldn't care less about them. All I care is that, if I used .NET, my sales would surely take a dive.

I agree. I think you've done sufficient research to back up that statement. However, your case appears to be fairly unique, so it would hardly be valid to consider yourself a typical VB6 user. I suspect that I am a more typical user, as I work in an organization producing programs for internal use with no sales consideration. For me, .NET is an excellent thing, and I have no desire to ever go back to VB6. I don't even like maintaining the things I wrote there, because the IDE is so inferior.

You've made the right choice for your situation, but your situation is atypical. MS made the decision to abandon your segment of the world, as far as VB is concerned. They have not totally abandoned the segment that needs to compile to native code, as VS C++ is a pretty good C++ compiler, but your segment consists of the group that need to compile to native code, or something near to that, but who does not want to use C/C++. That's a small group, and it doesn't surprise me that MS abandoned them. They were focused heavily on the web and the threat posed by Java, as you yourself noted several posts back. Interestingly, there WAS another version of VB6 in the works, which was terminated in favor of .NET for the explicit reason that they wanted to put all their wood behind one arrow. Therefore, the decision wasn't exactly one of omission, in that they knew that they abandoned one segment in favor of a different direction. The same could be said by the programming community in general. In time, Delphi, .NET, and even C/C++ will all fade away. Unfortunately, when it comes to programming languages, a phrase such as "in time", which usually suggests a long time off, probably means less than ten years.

Quote:

---

Originally Posted by Shaggy Hiker

VS C++ is a pretty good C++ compiler

---

VS C++ is not a compiler.

Sorry, I didn't want to point this out but was forced to... by the voices... in my head... I'll stop...

Quote:

---

Originally Posted by Shaggy Hiker

In time, Delphi, .NET, and even C/C++ will all fade away. Unfortunately, when it comes to programming languages, a phrase such as "in time", which usually suggests a long time off, probably means less than ten years.

---

C/C++ will never fade away. Delphi? Possibly. .Net? Probably but not C / C++.

C is about 37 years old. C++ is about 26 years old. Since their creation both languages have undergone some major changes to keep them fresh but their purpose has remained the same: for high performance, low level, typically for driver creation and other performance important areas, C is king. Where you need high performance but a higher degree of architecture, C++ is still king. This hasn't changed in decades and I can't see it ever changing.

In our current hardware architecture you need a few things to develop an operating system: you need ASM for the boot loader (there is no way you can do this in C, as far as I know (at least not the important bits)). Then you need to write the kernel, drivers, etc which is typically done via C/C++.

If we are to truly drop C and C++ at some point, what will we replace it with for embedded systems and operating systems? Surely you can't go with a language tied to any framework (regardless of C#'s standardization; I haven't seen a set of libraries and a compiler for C# that is .Net or Mono independent) so C# and Java is out (at least for the core pieces of the OS).

C++0X (or maybe it should be called C++1X at this point) will refresh C++ and keep it in line with many technological improvements other languages are undergoing including dynamic types and even LINQ. Once the standard is finalized it'll still take several years before all of the features are well integrated into current compilers and tested.

I can see Delphia fading away. I can see .Net fading away. I can't see low level languages such as C or C++ ever fading away as we'd have to replace them with basically the same thing: a low level, high performance language. Do we replace it with D? Ha!

Quote:

---

Originally Posted by Shaggy Hiker

You've made the right choice for your situation, but your situation is atypical. MS made the decision to abandon your segment of the world, as far as VB is concerned.

---

Yes, I had figured that out. That's the main reason for my lack of trust in them. Here in Italy we have a proverb that goes this way: You can only strike a match once! How could I switch to .NET knowing how much MS care about the developers using their products? They struck my match when they abandoned me and I swear it won't happen again.

Stick with a language that has ANSI backing, and is not tied to any particular company. Sun originally talked about getting ANSI standardization for Java, then pulled back and the whole thing devolved into lawsuits. It may have been related to MS putting out a java compiler in a fashion similar to what they were doing with Visual C++ at the time (not fully standards compliant because the standard was still only in draft form). That irked Sun, which really wanted to continue owning Java, even with the standard.

I believe that Delphi is based on Pascal, but I don't know if Pascal is a standardized language, or if there are any number of flavors out there. If there are flavors, you might as well hold onto something, as the world is going to shift out from under you again at some point in the future.

The only reasonably safe language to work in for what you want is C/C++, as both are ANSI standard languages which are not controlled by any company. Delphi may be more stable than an owned language like VB, but if the user base is small, and it isn't ANSI standard, then it could fade out on you just as easily as mutating. That's life. On the other hand, I can understand not wanting to jump to a third language so soon after switching to a second language, but you jumped from one ice flow to another, just as the first was capcizing under you. Unfortunately, you are still on an ice flow, and hoping that it neither melts nor flips, despite good reasons to think that it will do so. Eventually you will be jumping again. Might as well jump onto something stable, such as C++.

Quote:

---

Originally Posted by DeanMc

What I find strange about the whole thing is, as Billy Hollies mentioned in an article before (him being a major VB evangelist), The CLR was originally designed for VB (before .nets inception). Obviously as they refined it more it actually became a common language runtime.

Tell me if VBx had not changed to VB.NET but still used a framework and became VB7 with the "Visual Framework" would you still give out? I would argue that many VB6 developers would have moved with heads held high and smugly looked down at java developers and their "inferior" framework. Actually on java, I dont think many developers would move to java as quickly as you think. Java has had more "what its used for" changes than any other language. At least VB in every form stayed true to its goal RAD WIN development.

---

multithreading was a huge benefit of .net, but it could probably have been implemented into a new "runtime". Hopefully in the near future, microsoft will do for .net what vb5 did for the runtime: The ability to compile to native code. Let's face it, this isn't the first time basic's been interpreted as it was ran, but now they are calling it a "framework". Besides the honking-big size of it, i fail to see the difference.

On the "huge framework" front, don't forget how modern computers are finally being shipped with 64-bit operating systems now. And the 64-bit framework is twice as large since it also contains the 32-bit one for compatibility.

Quote:

---

Originally Posted by Shaggy Hiker

The only reasonably safe language to work in for what you want is C/C++, as both are ANSI standard languages which are not controlled by any company. Might as well jump onto something stable, such as C++.

---

I have to admit I am quite attracted by C++ as I heard it is not as difficult as one may believe.

Unfortunately, I don't know where to start from. The main questions I have are,

1. How much does it cost?

2. Does it have a form designer which works in a similar way to the VB's one?

3. Do the executables you produce with C++ need any runtime files to work on Windows?

Please note that the only operating system I am interested in is Windows, so I would like to avoid installing any components which are necessary to create software for other platforms.

Any help would be greatly appreciated.

There are many compilers for C++, the cost being from zero upwards. I personally can't advise which are good/bad, as I haven't used it in years (last time was MS VC 5 or 6).

The features vary, but a form-designer/window-creator is common (even on the occasions it isn't built-it, there is usually a fairly easy add-on for it).

Whether or not you need dependencies depends on what compiler you use, and what features you use in the program. Often you will have the code files for those features, so can simply add them to your project (or they are included automatically when you compile).


The downside to using a C based language is that your development will typically take longer - but how much depends on what pre-made features you can make use of.

Quote:

---

Originally Posted by esposito

How could I switch to .NET knowing how much MS care about the developers using their products?

---

They do care, to the point you could hope a company would - which is why they did what they considered to be best for the majority of the user base (and as you have seen, a large percentage of the user base agree with them).

Due to your special circumstances, you did not fit into the majority, and the changes were not good for you - but if I remember correctly, Microsoft put a lot of effort into helping you one on one with the issues you had (but I might be thinking of somebody else they helped). To me, that proves they cared about you too, but weren't able to give you what you wanted (at least not without a huge cost to them, which is unreasonable to ask for).

Quote:

---

Originally Posted by esposito

Unfortunately, I don't know where to start from. The main questions I have are,

1. How much does it cost?

---

Absolutely nothing! MinGW (the Windows port of GCC) is a really good compiler as is the MS C++ compiler. Both can be used via command line completely free.

If you're looking for a good IDE, then Visual C++ Express is also free and works quite well.

Quote:

---

Originally Posted by esposito

2. Does it have a form designer which works in a similar way to the VB's one?

---

Yes and no... it really depends what you're doing. If you're using managed C++ (you're probably not) then it has the same designer. MFC and others, I believe, have rudimentary ones. If you choose to go a different way and use a cross platform framework like wxWidgets, you can download their designer which works really well.

Quote:

---

Originally Posted by esposito

3. Do the executables you produce with C++ need any runtime files to work on Windows?

---

Maybe. All depends on what frameworks you're using.

There is a C++ runtime most applications need but comes installed on basically every Windows version ever so that's not a concern.

If you end up using just the pure Win32 API for your GUI (did it once; not recommended; heh) then no. I think MFC may have some DLLs to package with your application but nothing huge. wxWidgets, I think, compiles via a static library so no DLLs there as well.

Quote:

---

Originally Posted by esposito

Please note that the only operating system I am interested in is Windows, so I would like to avoid installing any components which are necessary to create software for other platforms.

---

Perfectly understandable and while wxWidgets is a cross-platform GUI framework; I still recommend it. It's very easy to use and if you ever want to move your work to another OS, you practically just need to recompile it there :D.

One other point that should be mentioned is that C++ is a huge sprawling mess of a language, even with the standards. You can do things in the STL that will take ALL your time. This is one of the reasons that getting ANSI standard compatible compilers took years for ALL companies. However, at this time, pretty much every compiler is highly compliant with the standard. However, there is still so much in the standard that even MS uses only what they call a "rational subset" of the language internally. Therefore, you don't need to learn the whole thing, you just need to learn that part that gets the job done, then add on bits and pieces as you find the need.

Quote:

---

Originally Posted by Shaggy Hiker

One other point that should be mentioned is that C++ is a huge sprawling mess of a language, even with the standards. You can do things in the STL that will take ALL your time.

---

I'm not sure I understand what you mean. C++ is a very elegant language and far from a "mess".

The language itself, while larger than C and a little larger than C#, isn't that difficult to master and everything is made to work very well together.

The STL is even better. You can use the Algorithms library and apply practically every transformation available to almost all other STL objects. It's very elegant in the way that components can work together and std::vector<T> is an awesome container.

Anything can take up ALL of your time depending on what you're doing so I don't understand where you're coming from.

Quote:

---

Originally Posted by Shaggy Hiker

This is one of the reasons that getting ANSI standard compatible compilers took years for ALL companies.

---

Is there a reason why you're pointing this out? Microsoft was busy working on .Net so left their crufty VC++ 6 out there for so long with mediocre standards support but the other compiler, g++ (MinGW), kept up pretty well. Sure it wasn't instant but it was miles ahead of VC++ 6 and it didn't take them nearly as long.

But in all seriousness, what compiler doesn't take years to complete for any language? It looks to me like MS took years for them to get their C# compiler completed. So I don't understand your point here as well.

Quote:

---

Originally Posted by Shaggy Hiker

However, there is still so much in the standard that even MS uses only what they call a "rational subset" of the language internally.

---

Do you have a link that explains this? It was my understanding that MS' C++ compiler (MinGW is kind of in the same boat too) was very very close to being completely standards compliant with C++98 and that most of the issues stemmed from bugs.

Not trying to say you're wrong; I'm just curious as I haven't heard that before.

The rational subset came from an article, and possibly from my MS relations. I'm not saying the C++ compiler uses a subset, but that MS internally has settled on a subset. The compiler is quite compliant with the full ANSI standard (maybe even 100% compliant, I haven't kept track).

I remember reading articles comparing C++ compilers right after the ANSI standard came out, and for the next few months. No test showed a 100% compliant compiler for a considerable time afterwards, though who led and who lagged didn't seem to follow a pattern. However, this was pre-VC++6, if I remember right. When you get right down to it, not meeting a standard for a few MONTHS after it comes out is really not surprising. We tend to live in the now, and what is not done NOW bothers us, even when we know that we will be able to look back on it a few months later and wonder why we bothered.

There are items in the C++ language, such as RTTI, multiple inheritance, and a few others, which may serve no useful purpose. When these issues were being added to the standard, the debate about them was fairly hot as to whether there was EVER a situation where they were essential, yet they are in the language (even .NET has something like RTTI, though not multiple inheritance).

As for the STL, from what I read, while many pieces are quite nice (and generics are also highly useful in .NET), the whole thing allows for a complexity that makes mastery of it open to only people who dedicate their time to it. There are magazines that publish articles on esoteric STL constructs that create novel algorithm implementations, but do so in a fashion that few people can take the time to work them out.

It's a whole lot of rope. Rope can be very useful for accomplishing all kinds of tasks, but if you have more than you can handle, it can turn into a confusing snarl, even if it accomplishes the task. Increasing complexity is not the goal of programming, yet it appears easier to achieve with the STL than anything else out there. It's useful, but it has more potential to obfuscate than most languages seem to have.

While we are on the subject of C++ I have a quick question :)
When I first started learning VB.NET I got fed up with having to install the framework on every PC I used my apps on (just like others have pointed out) so I thought I would try and learn C++ as this doesnt require a framework. I was then quite confused when I went to built a new C++ app in Visual Studio and it still required the .NET Framework...
I guess this is because its the 'new' version of C++ but what confuses me is this - why is C++.NET any better or more powerful than C#.NET or VB.NET because surely if they all use the same framework then they can all do pretty much the exact same things cant they?

Quote:

---

Originally Posted by Shaggy Hiker

We tend to live in the now, and what is not done NOW bothers us, even when we know that we will be able to look back on it a few months later and wonder why we bothered.

---

You may think we live in the "now" but that's not true. Since C++ is standardized, you knew about it before the compilers were completed. C#, while standardized, wasn't standardized until Microsoft was practically done with the first version of the compiler.

So, really, we don't live in the now. We live in the whenever-companies-want-to-tell-us. Standards just typically happen before implementation but most of Microsoft's standards were done the other way so you had practically no waiting to do.

Quote:

---

Originally Posted by Shaggy Hiker

There are items in the C++ language, such as RTTI, multiple inheritance, and a few others, which may serve no useful purpose. When these issues were being added to the standard, the debate about them was fairly hot as to whether there was EVER a situation where they were essential, yet they are in the language (even .NET has something like RTTI, though not multiple inheritance).

---

I agree there are somethings you'd probably never need. If you don't use them they won't hurt you though. As you said before, just don't learn them. I'd rather a language come with additional items I'll never need just in case I ever find myself in a position when I would actually need it. I do enjoy my multiple inheritance though :) (you occasionally find a good reason to use it though there aren't many and I'm sure it's abused).

Quote:

---

Originally Posted by Shaggy Hiker

As for the STL, from what I read, while many pieces are quite nice (and generics are also highly useful in .NET), the whole thing allows for a complexity that makes mastery of it open to only people who dedicate their time to it. There are magazines that publish articles on esoteric STL constructs that create novel algorithm implementations, but do so in a fashion that few people can take the time to work them out.

It's a whole lot of rope. Rope can be very useful for accomplishing all kinds of tasks, but if you have more than you can handle, it can turn into a confusing snarl, even if it accomplishes the task. Increasing complexity is not the goal of programming, yet it appears easier to achieve with the STL than anything else out there. It's useful, but it has more potential to obfuscate than most languages seem to have.

---

Have you used the STL? It's not very big at all. Take a look here to get an idea for the objects in the STL.

The STL is basically the C++ programmers version of System.Collections.Generics. A good portion of the STL is just dealing with storing data; not very complex at all. I'll admit some of the items in the STL are a little complicated but practically all of them have similar interfaces and are relatively easy to use. I fail to see how it's "a whole lot of rope" and how it increases complexity. If you want to look at the STL like that then the .Net Framework must be a mountain of rope for you since it includes most of what's in the STL, and then a million more things even if you don't include GUI components (since STL does not have any OS specific stuff).

The STL helps programmers efficiently manage collections and exceptions. Many of its interfaces are comparable with .Net's in the collections and exceptions realm. None of this is complicated at all.

Using STL you can make a vector of strings:

Code:

---

vector<string> MyStrings;
MyStrings.push_back("Weee!");

---

Using System.Collections.Generics you can make a list of strings:

Code:

---

List<string> MyStrings = new List<string>();
MyStrings.Add("Weee!");

---

The STL is simple but like all frameworks and libraries it takes time to learn. It doesn't increase any complexity and you don't even need to use it.

The Boost library makes up for many of STL's shortcomings as it's no where near as full featured as many portions of the .Net framework.

Quote:

---

Originally Posted by chris128

I was then quite confused when I went to built a new C++ app in Visual Studio and it still required the .NET Framework...
I guess this is because its the 'new' version of C++ but what confuses me is this - why is C++.NET any better or more powerful than C#.NET or VB.NET because surely if they all use the same framework then they can all do pretty much the exact same things cant they?

---

C++ and Managed C++ are different things.

Managed C++ is C++ with .Net extensions and therefore requires the framework. It's good if you want to port some of your native libraries to managed (less Marshalling hits) but beyond that you wouldn't really want to program in it all the time. C# or VB should be the language of choice for .Net development unless you're porting something and even then it may not be a good fit.

Visual Studio can also do C++ (unmanaged) which does not require the framework. Just be careful with what project types you select when you start coding in C++. The Managed C++ components have better form designers than C++ with MFC, ALT or Win32 so that may be why you stuck with that.

Thanks, everybody, for your professional advice on C++.

I would very much like to start sinking my teeth into actually working with it.

Among the versions of C++ that the Web has to offer, is there anything free that would allow me to get (1) a form designer, possibly as easy as the one you find in VB or Delphi, and (2) a compiler for Win32?

I would very much appreciate it if you told me exactly what I should download (and from where) to be able to compile a Win32 standalone executable.

Right now, my target is to develop the easiest application possible, i.e. a form containing a label and a button, and the caption of the former should change by pressing the latter.

What should I install on my PC to be able to compile such an application? Please consider that I have never used C++ in my life, so make it as simple as possible, if you can.

Thanks again.

Quote:

---

Originally Posted by esposito

I would very much like to start sinking my teeth into actually working with it.

---

YES! We have a convert! Shall we commence the hazing? :D

Quote:

---

Originally Posted by esposito

Among the versions of C++ that the Web has to offer, is there anything free that would allow me to get (1) a form designer, possibly as easy as the one you find in VB or Delphi, and (2) a compiler for Win32?

I would very much appreciate it if you told me exactly what I should download (and from where) to be able to compile a Win32 standalone executable.

---

So for a compiler you have a few choices. For command line you can go with MinGW (I prefer the distribution of MinGW from Nuwen.net has it has boost libraries and other items included). Microsoft's C++ compiler gets installed when you install Visual Studio (not sure what other packages it comes with) and can be used via the command line or from the IDE. Now MS' compiler, last time I checked, typically made slightly smaller binaries than MinGW but both work really well.

As for a form designer... this is a little more difficult in C++ as it's OS agnostic. Having said that you do have some choices.

Microsoft offers their Visual C++ Express 2008 IDE for free. I recommend Visual Studio over all other IDEs as it's just that much better and many times I'll use it, then compile via MinGW in the command line. The only thing with the express edition is that its "form designer" is only with managed C++.

For native C++ you'll need the professional edition or higher but the form designer isn't as full as you'd expect coming from VB6 or .Net. It's much more limited but will work with Win32 and MFC.

Other alternatives include using wxWidgets or Qt for your GUI related work. wxWidgets is nice and open-source but can be a pain to install (at least it used to; looking at it now it looks like you can just download a workable installer!). Then I think you have to download a separate application for the designing aspect (something like wxWidgets Dialog Designer looks good) but there are many flavors). Qt is not entirely open source. They have an open-source licensed and a commercial licensed version but both should work well. These have installers and should include a designer.

So you have quite a few choices. It's too bad there isn't a good one like the form designer used in .Net but there are many alternatives to get the job done.

Quote:

---

Originally Posted by esposito

Right now, my target is to develop the easiest application possible, i.e. a form containing a label and a button, and the caption of the former should change by pressing the latter.

---

MFC, wxWidgets or Qt will probably be your best bet. You can do what you request via Win32 API but... well, it's not as easy since it's basically the lowest level you can go before duplicate drawing code, heh.

Thank you very much. I'll download the software you have suggested and see if I can get the hang of it.

Sure thing. Also, feel free to do some of your own research. While C++ is my favorite language, due to my career I've only been able to focus on C# for the past 5 years and only did 1 short term C++ project in the past 3 years so there may be even better GUI tools out there.

I'm a little surprised nobody has suggested D.

Quote:

---

Originally Posted by dilettante

I'm a little surprised nobody has suggested D.

---

I'm surprised someone actually mentioned D.

D was modeled from C++ yet it stomps all over it like crazy people running into Wal-Mart to save $20 on a Plasma TV. It's not standardized. It uses Garbage Collection rather than C++'s RAII goodness (I hate garbage collection but that's another debate on another thread at another time).

D is poorly supported. They have a library (kind of like C++'s STL) called Phobos but since it wasn't very good, a new one was created called Tango. Now you have two standard libraries and both now have incompatibilities with each other and both are being maintained. That's messy. D also has issues with DLLs and worse operator overloading than C++.

There are few compilers out there. There are no IDEs that I could find (but, of course, editors like emacs support it). It's not even standardized; one company owns it.

Well I meant that D seems to always creep into these discussions sooner or later. It has some fascinating advantages though a few warts for sure. Two "standard" libraries isn't bad as new-language evolution goes at this still early stage. Both main compilers (isn't there a 3rd now?) rely on the GCC back end don't they?

Basic IDEs, beyond just editors but not much, can be found as add-ins for both Eclipse and Zeus.

I never used it except to play around with, but I think it takes C in a cleaner direction than C++, Java, or C# did. To really know that you'd have to "live with it" a while though and I haven't ventured there.

I'd put it far ahead of things like FreeBASIC though. At least it can be used with COM on Windows, something even .Net has to do in many places to accomplish real work without reinventing every wheel.

However there is no question it is an eccentric language, with even a smaller user base than Ruby.

Quote:

---

Originally Posted by dilettante

Well I meant that D seems to always creep into these discussions sooner or later.

---

Let's see....it hadn't crept in until YOU mentioned it. Seems like a self-fulfilling prophesy.:wave:


I actually left C++ back in the early days of the STL, so I can't say I have ever really used it. My impressions are not just dated, but nothing more than first impressions.

Got me there!

Quote:

---

Originally Posted by Kasracer

For native C++ you'll need the professional edition or higher but the form designer isn't as full as you'd expect coming from VB6 or .Net. It's much more limited but will work with Win32 and MFC.

---

So how would you actually go about making a NATIVE C++ application (ie one that could run on any windows 2000/XP/Vista machine with no prereqs) with Visual Studio 2008? Everytime I have tried to make one it just wants to use the .NET framework all the time. To be honest I havent tried that much though as the lack of a form designer in the express C++ edition made me quit before I had even started..

Quote:

---

Originally Posted by chris128

So how would you actually go about making a NATIVE C++ application (ie one that could run on any windows 2000/XP/Vista machine with no prereqs) with Visual Studio 2008? Everytime I have tried to make one it just wants to use the .NET framework all the time. To be honest I havent tried that much though as the lack of a form designer in the express C++ edition made me quit before I had even started..

---

You have to choose the correct project first. Any CLR projects will require the .Net framework so basically choose anything else. If you want zero prerequisites then you'll probably want to create either a Win32 or empty project and build using just the Win32 API. Not very pretty but doable.

Using limited DLLs for your release you can use something like MFC (which requires 1 DLL, I believe, and is fairly small though backwards compatibility with other MFC versions can be a *****), ALT, wxWidgets and Qt all produce small dependencies that don't require "installation", just that they are kept in the program's directory.

wxWidgets, however, can be compiled via a static library I believe so you may not need to include anything additional with those.

Attached is a screenshot of all of my project types for C++. Just don't choose anything in the CLR category.

Are those dependencies just dll files, or are they something else. I don't consider a dll to be in the same category as the CLR, because there are sound reasons to break many differnet kinds of programs into dlls, and there is no real advantage to a monolithic executable in those cases.

Don't forget your runtime:

Microsoft Visual C++ 2005 Redistributable Package (x86)

Determining Which DLLs to Redistribute

Quote:

---

Originally Posted by Shaggy Hiker

Are those dependencies just dll files, or are they something else. I don't consider a dll to be in the same category as the CLR, because there are sound reasons to break many differnet kinds of programs into dlls, and there is no real advantage to a monolithic executable in those cases.

---

Just DLLs. I'm not sure of any requiring installation like a framework. The redistributable basically installs all of the items you could need to central locations but you don't have to use it.

Quote:

---

Originally Posted by dilettante

Don't forget your runtime:

Microsoft Visual C++ 2005 Redistributable Package (x86)

Determining Which DLLs to Redistribute

---

Good link for finding the correct DLLs. Typically you won't have any issues with the C++ runtime as it's installed on all versions of Windows so you really only run into an issue if you're on a much newer version.

Thankfully you can use all of these DLLs locally and not cause any issues with other applications :).

Fyi, the redistributable includes basically everything including ATL, MFC, etc so you don't need to use the entire thing.

I think those runtime libraries are only preinstalled in XP SP3, Vista, and later unless you've installed another application that put them in place. Each version of Visual C++ has its own runtimes.

There is also:

Quote:

---

Visual C++ files can be redistributed using either the provided Redistributable Merge Modules, or the Visual C++ Redistributable Package, or by deploying specific Visual C++ assemblies as private side-by-side assemblies in the application local folder.

---

Which means "don't just plop them in the EXE's folder." You can do this, but you're supposed to use an isolation manifest.

Correction:

Good news! The assemblies from the Visual C++ 2005 Redist package already have assembly manifests as internal resources so on WinXP or later that's all you need to do! Just put them into a bin folder under the EXE folder.

As I look all of it over I can't see why you couldn't just "plop" them into the EXE folder, though it seems to be discouraged.

How to: Deploy using XCopy