Greystoke
asked on
C++ Builder / Visual C++
I currently use C++ and the OWL. However, I wish to start using either C++ Builder or Visual C++.
Which one is preferable? and are there any books that would be of use?
Further, how easy is it to integrate classes etc.. that have been written in C++ into a Builder or Visual program?? Is this the best way to go about it, or just program direct from the Builder or Visual environment?
Which one is preferable? and are there any books that would be of use?
Further, how easy is it to integrate classes etc.. that have been written in C++ into a Builder or Visual program?? Is this the best way to go about it, or just program direct from the Builder or Visual environment?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Ok, so you suggest VC due to it's popularity and advanced features. However, is the learning curve sufficiently greater for VC to propose Builder, as it uses OWL, as a short term 'stop gap' ? As I only really have a couple of months to implement a basic structure.
Further, a point I am still not totally clear on. Take, for example, the 'Model, View, Controller' architecture - when using Builder or VC, do you still code the Model as a standard C++ program, and then produce the Views and Controller from the Visual environment? Or is it all done from the Visual package?
Further, a point I am still not totally clear on. Take, for example, the 'Model, View, Controller' architecture - when using Builder or VC, do you still code the Model as a standard C++ program, and then produce the Views and Controller from the Visual environment? Or is it all done from the Visual package?
I don't know that experience with OWL will help you to learn VCL on builder faster. (Obviously it helps in using OWL on builder.) I also don't really know how hard it is to learn VCL compared to MFC. But my intuition (well, and a tiny bit of experience) tells me that VCL is harder to learn. It is not as well documented as MFC (and, as I said, there is less support). In addition, another huge advantage to VC that I did not mention is that its on-line help is far superior to BC's. (For a while I was programming only in BC builder but was using VC's help!) VC's help is better in the sense that it is better written (more complete, more clear, more examples etc) and that it is a far better help tool (easier to find things, more powerful searches, more links etc.)
>>As I only really have a couple of months to implement a basic structure
What does your program do? The basic structure of an MFC program is generated in seconds by the wizard, then you customize it from there. ideally, you will spend most of your programming time on non-windows related items and a tiny bit of time interfacing that to MFC. Idealy, but it depends on what you need to get done. Anyways that is probably equally true (or equally untrue) of OWL or VCL.
I;m not clear in your last question. What do you mean by the "Model, View, controller" architecture? I'm not clear on the rest of the question. Perhaps this might help. Do you know that the IDEs (both VC and Builder) simpy create ordinary C++ programs. The "vissual" component is somewhat limited and is really just an "interface" to your source code. For example they have class viewers that "show" you a class and its members and its relations to base classes etc. This is created by parsing the source code. They have features for overiding member functions in a class by selecting the function name from a list. Again the list is created by reading the source code. when you add the function it it just adds it the souce code. You still have to type in the guts to the function as 100% C++. If you want, you coudl just type in the whole function yourself manually and avoid the "visual" interface. Lots of programmers do that in MFC. I don't know about builder.
>>As I only really have a couple of months to implement a basic structure
What does your program do? The basic structure of an MFC program is generated in seconds by the wizard, then you customize it from there. ideally, you will spend most of your programming time on non-windows related items and a tiny bit of time interfacing that to MFC. Idealy, but it depends on what you need to get done. Anyways that is probably equally true (or equally untrue) of OWL or VCL.
I;m not clear in your last question. What do you mean by the "Model, View, controller" architecture? I'm not clear on the rest of the question. Perhaps this might help. Do you know that the IDEs (both VC and Builder) simpy create ordinary C++ programs. The "vissual" component is somewhat limited and is really just an "interface" to your source code. For example they have class viewers that "show" you a class and its members and its relations to base classes etc. This is created by parsing the source code. They have features for overiding member functions in a class by selecting the function name from a list. Again the list is created by reading the source code. when you add the function it it just adds it the souce code. You still have to type in the guts to the function as 100% C++. If you want, you coudl just type in the whole function yourself manually and avoid the "visual" interface. Lots of programmers do that in MFC. I don't know about builder.
I agree with most of what nietod wrote, but except one point:
Since VCL is thicker(lots more) wrap over windows api than MFC..VCL is much much easier to learn.
I would use MFC, there are more resources for it. Its funny, I found myself using BCB and VC help also. That was very irritating.
Since VCL is thicker(lots more) wrap over windows api than MFC..VCL is much much easier to learn.
I would use MFC, there are more resources for it. Its funny, I found myself using BCB and VC help also. That was very irritating.
>> Since VCL is thicker(lots more) wrap over
>> windows api than MFC.
>> VCL is much much easier to learn.
I don't think that is a necessary result of the thicker wrapper. I do think that VCL (at least fundamentally) is a superior wrapper (perhaps less feature rich), but that does not make it easier to learn. That probably means it is easier to use, but not necesarily easier to learn.
>> windows api than MFC.
>> VCL is much much easier to learn.
I don't think that is a necessary result of the thicker wrapper. I do think that VCL (at least fundamentally) is a superior wrapper (perhaps less feature rich), but that does not make it easier to learn. That probably means it is easier to use, but not necesarily easier to learn.
easier to learn? easier to use ?
Please help me understand...what is the difference ?
How do we measure the degree of superiority of a wrapper ? By how much it hides details ? Its documentation ?
Is it not true that the more it hides the easier it is to use ? (I don;t think so, but would like your opinion)
Sounds like I am defending BCB/VCL, but I an MFC fan. But, interesting enough, just about every time I wanted to do something in MFC..it was almost always easier to do it in VCL.
Please help me understand...what is the difference ?
How do we measure the degree of superiority of a wrapper ? By how much it hides details ? Its documentation ?
Is it not true that the more it hides the easier it is to use ? (I don;t think so, but would like your opinion)
Sounds like I am defending BCB/VCL, but I an MFC fan. But, interesting enough, just about every time I wanted to do something in MFC..it was almost always easier to do it in VCL.
Learning is the earlier stage. i.e first you learn something--possibly as you use it--then once you have learned it, you use it.
BCB's VCL has lots of "convenience" features that make it easier to use. but you have to learn about them before you can use them. Since their help is so terrible (in comparisson to VC's) it may be much harder to learn about them.
>> Is it not true that the more it hides the easier it is to use ?
That is oversimplified, but in general that is true. the key word is "encpasulate", not hide. The more encapsulates features to make them reliable, and to provide more convenient interfaces to the feature, the easier. But you can certainly do a poor job of encapsulating. Poor encapsulation might prevent you from accessing certain features you need or it might provide a lot of overhead without providing any additional safety. For example to create a font in windows requires that you send about 15 parameters. No one can remember all these parameters--the are aweful. A good encapsulation will provide an easer interface for creating fonts, one with less parameters and ones that might be easier to memorize and specify. A good encapsulation might also insure that the font is always deleted when no longer needed, so you never get GDI memory leaks. But a bad encapsulation might make it impossible to specify all the variety of font options that the original create font supports. Or it might not inssure that the font is deleted, so it not a safety at all.
>> I wanted to do something in MFC..it was almost
>> always easier to do it in VCL.
You are not the type of "MFC fan" that gets elected as Microsoft's poster boy.
BCB's VCL has lots of "convenience" features that make it easier to use. but you have to learn about them before you can use them. Since their help is so terrible (in comparisson to VC's) it may be much harder to learn about them.
>> Is it not true that the more it hides the easier it is to use ?
That is oversimplified, but in general that is true. the key word is "encpasulate", not hide. The more encapsulates features to make them reliable, and to provide more convenient interfaces to the feature, the easier. But you can certainly do a poor job of encapsulating. Poor encapsulation might prevent you from accessing certain features you need or it might provide a lot of overhead without providing any additional safety. For example to create a font in windows requires that you send about 15 parameters. No one can remember all these parameters--the are aweful. A good encapsulation will provide an easer interface for creating fonts, one with less parameters and ones that might be easier to memorize and specify. A good encapsulation might also insure that the font is always deleted when no longer needed, so you never get GDI memory leaks. But a bad encapsulation might make it impossible to specify all the variety of font options that the original create font supports. Or it might not inssure that the font is deleted, so it not a safety at all.
>> I wanted to do something in MFC..it was almost
>> always easier to do it in VCL.
You are not the type of "MFC fan" that gets elected as Microsoft's poster boy.
>Since their help is so terrible (in >comparisson to VC's) it may be much >harder to learn about them.
Agreed.
>the key word is "encpasulate", not hide
Hmm, correct me if I am wrong, but more than one book mentions the phrase 'information hiding'. In fact, a lot of oop/ooa/ood 'starter/novice/intro books throw this term around a lot.BUT, YES YOU ARE RIGHT...should have used encapsulate.
>You are not the type of "MFC fan" that >gets elected as Microsoft's poster boy
True, but like you(sorry for my assumption) I use the tools that help me the most to get my job done...msoft/symantec/borl
Agreed.
>the key word is "encpasulate", not hide
Hmm, correct me if I am wrong, but more than one book mentions the phrase 'information hiding'. In fact, a lot of oop/ooa/ood 'starter/novice/intro books throw this term around a lot.BUT, YES YOU ARE RIGHT...should have used encapsulate.
>You are not the type of "MFC fan" that >gets elected as Microsoft's poster boy
True, but like you(sorry for my assumption) I use the tools that help me the most to get my job done...msoft/symantec/borl
I've seen "information hding" used on occassion too, but it is not widely used. "encapsulation" is the preferred term. I think it implies more than "information hiding" and it does not have any negative conotations.
>> doubt that you would bend for msoft and preach
>> that their tools are the best..c'mon
I don't! I don't think I am here. I point out that BCB's frame work is in many ways superior to MFC's (its not clear-cut) and easier to use. Apparently didn't mention the fact that BCB is far far faster than VC, I usually mention that too.
For my work I use both BCB and VC on the same source. Two compilers are better at finding mistakes than just one. And the BCB compiler generates the code in less than 1/10th the time of VC. But I need VC for its on-line help and debugger. I don't ever use the BCb help and try to avoid the debugger.
>> doubt that you would bend for msoft and preach
>> that their tools are the best..c'mon
I don't! I don't think I am here. I point out that BCB's frame work is in many ways superior to MFC's (its not clear-cut) and easier to use. Apparently didn't mention the fact that BCB is far far faster than VC, I usually mention that too.
For my work I use both BCB and VC on the same source. Two compilers are better at finding mistakes than just one. And the BCB compiler generates the code in less than 1/10th the time of VC. But I need VC for its on-line help and debugger. I don't ever use the BCb help and try to avoid the debugger.
Why does expert exchange not have a BCB
forum ?
>try to avoid the debugger
why ?
forum ?
>try to avoid the debugger
why ?
There is a delphi forum, that should cover most VCL-specific issues. If you want a BCB forum, you should ask customer service. (I think I would prefer it if it were a VCL in BCB type forum, (like the MFC forum) not a BCB C++ forum.)
I think BCB's debugger is terrible. Until recetly you coudl not see varaibles higher in the call stack which is eesential--since they are usually the source of the problem. It is very hard to "explore" complex objects, ones with pointers or refferences, even simple objects like string classes are hard to view. Until recently they did not have a step out of function option. VC's debugger is just tons easier to use and more powerful. BCB is catching up slowly, but its not there. And BCB doesn't ahve an option to customize function keys--which is really annoying!
I think BCB's debugger is terrible. Until recetly you coudl not see varaibles higher in the call stack which is eesential--since they are usually the source of the problem. It is very hard to "explore" complex objects, ones with pointers or refferences, even simple objects like string classes are hard to view. Until recently they did not have a step out of function option. VC's debugger is just tons easier to use and more powerful. BCB is catching up slowly, but its not there. And BCB doesn't ahve an option to customize function keys--which is really annoying!
ASKER
Further, a point I am still not totally clear on. Take, for example, the 'Model, View, Controller' architecture - when using Builder or VC, do you still code the Model as a standard C++ program, and then produce the Views and Controller from the Visual environment? Or is it all done from the Visual package?