Re: VBForums' new heavy .Net hand
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.
Re: VBForums' new heavy .Net hand
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.
Re: VBForums' new heavy .Net hand
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.
Re: VBForums' new heavy .Net hand
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.
Re: VBForums' new heavy .Net hand
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?
Re: VBForums' new heavy .Net hand
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.
Re: VBForums' new heavy .Net hand
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.
Re: VBForums' new heavy .Net hand
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.
Re: VBForums' new heavy .Net hand
Thank you very much. I'll download the software you have suggested and see if I can get the hang of it.
Re: VBForums' new heavy .Net hand
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.
Re: VBForums' new heavy .Net hand
I'm a little surprised nobody has suggested D.
Re: VBForums' new heavy .Net hand
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.
Re: VBForums' new heavy .Net hand
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.
Re: VBForums' new heavy .Net hand
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.
Re: VBForums' new heavy .Net hand
Re: VBForums' new heavy .Net hand
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..
1 Attachment(s)
Re: VBForums' new heavy .Net hand
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.
Re: VBForums' new heavy .Net hand
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.
Re: VBForums' new heavy .Net hand
Re: VBForums' new heavy .Net hand
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
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.
Re: VBForums' new heavy .Net hand
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.
Re: VBForums' new heavy .Net hand
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
