Microsoft invited to comment on C++
-
What us VC++ developers it reassurement on the feature of VC++, maybe Chris could ask somebody from the Microsoft Languages Unit to comment on VC++. Lets face it Mike Blasczak left the MFC/VC++ in March 1999, he left the team becase the team and project was being wound down - Is this true. I known B eikM (Mike Blasczak) is now working on the SQL Server team. Microsoft better answer soon or they will lose alot of Windows gurus. The future looks bleak, so Microsoft what have you got to say on the subject?
-
What us VC++ developers it reassurement on the feature of VC++, maybe Chris could ask somebody from the Microsoft Languages Unit to comment on VC++. Lets face it Mike Blasczak left the MFC/VC++ in March 1999, he left the team becase the team and project was being wound down - Is this true. I known B eikM (Mike Blasczak) is now working on the SQL Server team. Microsoft better answer soon or they will lose alot of Windows gurus. The future looks bleak, so Microsoft what have you got to say on the subject?
-
The facts... MFC has reached its life time expectancy, we are know that and we've got to live with, like it or not. ATL is the only library that seems to have been expanded on with CImage, CString etc. much of development is going to be limited to Business Objects and server side components. The only framework to build GUI applications seems to with the .NET framework. Now if I'm a manager and I need to build a large GUI based application, I going to use VB right? What is the point of using managed C++, C++ programmers don't come cheap - I dont :) And why use a complex language when you can use a far simpler language like VB to build the GUI and components right? So VC++ is now limited to a few uses, Microsoft haven't come out and said, "whoa your all wrong! we're not shelving VC++, we've got plans and they are...". I would be comforting to know what direction Microsoft are taking with VC++. I'm not trying to incite a war, I'm just trying to clarify the future of VC++, because I'm finding it hard to see where it fits in future windows development.
-
The facts... MFC has reached its life time expectancy, we are know that and we've got to live with, like it or not. ATL is the only library that seems to have been expanded on with CImage, CString etc. much of development is going to be limited to Business Objects and server side components. The only framework to build GUI applications seems to with the .NET framework. Now if I'm a manager and I need to build a large GUI based application, I going to use VB right? What is the point of using managed C++, C++ programmers don't come cheap - I dont :) And why use a complex language when you can use a far simpler language like VB to build the GUI and components right? So VC++ is now limited to a few uses, Microsoft haven't come out and said, "whoa your all wrong! we're not shelving VC++, we've got plans and they are...". I would be comforting to know what direction Microsoft are taking with VC++. I'm not trying to incite a war, I'm just trying to clarify the future of VC++, because I'm finding it hard to see where it fits in future windows development.
-
The facts... MFC has reached its life time expectancy, we are know that and we've got to live with, like it or not. ATL is the only library that seems to have been expanded on with CImage, CString etc. much of development is going to be limited to Business Objects and server side components. The only framework to build GUI applications seems to with the .NET framework. Now if I'm a manager and I need to build a large GUI based application, I going to use VB right? What is the point of using managed C++, C++ programmers don't come cheap - I dont :) And why use a complex language when you can use a far simpler language like VB to build the GUI and components right? So VC++ is now limited to a few uses, Microsoft haven't come out and said, "whoa your all wrong! we're not shelving VC++, we've got plans and they are...". I would be comforting to know what direction Microsoft are taking with VC++. I'm not trying to incite a war, I'm just trying to clarify the future of VC++, because I'm finding it hard to see where it fits in future windows development.
Hello, the codegurus around the world.;) My point is that as long as someone needs MFC application, MFC is alive even though Microsoft focuses more on C#.:rolleyes: Even though Java and C++ became to be used in the market, some company still uses C, Cobol(?) and the other language partly because it wants to save the money. If we just look at PC market by the individual person, we will miss something. However, after the broadband is used among us all in 5 years(?), the stand alone application will not be used among us mainly. Still, we need the back-up desk top application since the broadband may sometimes be failed. I understand that Microsoft focuses more on C# than MFC, and many application will run inside IE. But, we still need the broadband access and its reliability among the PC user in the house.:(( Have a nice day! -Masaaki Onishi-
-
The facts... MFC has reached its life time expectancy, we are know that and we've got to live with, like it or not. ATL is the only library that seems to have been expanded on with CImage, CString etc. much of development is going to be limited to Business Objects and server side components. The only framework to build GUI applications seems to with the .NET framework. Now if I'm a manager and I need to build a large GUI based application, I going to use VB right? What is the point of using managed C++, C++ programmers don't come cheap - I dont :) And why use a complex language when you can use a far simpler language like VB to build the GUI and components right? So VC++ is now limited to a few uses, Microsoft haven't come out and said, "whoa your all wrong! we're not shelving VC++, we've got plans and they are...". I would be comforting to know what direction Microsoft are taking with VC++. I'm not trying to incite a war, I'm just trying to clarify the future of VC++, because I'm finding it hard to see where it fits in future windows development.
> The only framework to build GUI applications seems to with the .NET framework. I don't know of many game companies that are jumping on .NET as the basis of their very GUI application. Most prefer to stay generic as possible for porting to other platforms. > Now if I'm a manager and I need to build a large GUI based application, I going > to use VB right? Well every application is going to need different requirements. One project my old company did for Xerox was a large VB based billing system. They even had to re-write parts of it that were working in VC over to VB, at Xerox's request. so VB might be what you choose. Or VC, or C#, I think it all depends on the applications. I had helped to write a VC app that calculated radiation doses for treating cancer. I wouldn't think you would want to use VB for that. Steve Maier, MCSD
-
> The only framework to build GUI applications seems to with the .NET framework. I don't know of many game companies that are jumping on .NET as the basis of their very GUI application. Most prefer to stay generic as possible for porting to other platforms. > Now if I'm a manager and I need to build a large GUI based application, I going > to use VB right? Well every application is going to need different requirements. One project my old company did for Xerox was a large VB based billing system. They even had to re-write parts of it that were working in VC over to VB, at Xerox's request. so VB might be what you choose. Or VC, or C#, I think it all depends on the applications. I had helped to write a VC app that calculated radiation doses for treating cancer. I wouldn't think you would want to use VB for that. Steve Maier, MCSD
Steve good point :) Senario: I am product manager in charge of developing a new Inhouse system called SystemX SystemX requires database access, serial communications, web access, sexy front ends. SystemX is also a mission critical application. I require this system to be built using OOD, OOP. The highest population of programmers are VB? Do I try and use VB programmers to design and implement the system, is VB the best tool?. I cant use C# (learning curve etc.) VC++ would be the better choice but the timescales are tight. What should I use to develop SystemX? BTW for this exercise assume VS.NET is released. Thoughts please.
-
Steve good point :) Senario: I am product manager in charge of developing a new Inhouse system called SystemX SystemX requires database access, serial communications, web access, sexy front ends. SystemX is also a mission critical application. I require this system to be built using OOD, OOP. The highest population of programmers are VB? Do I try and use VB programmers to design and implement the system, is VB the best tool?. I cant use C# (learning curve etc.) VC++ would be the better choice but the timescales are tight. What should I use to develop SystemX? BTW for this exercise assume VS.NET is released. Thoughts please.
If I was running the project, I'd probable use a combo of Visual Basic and ATL COM components. VB is great for the sexy front end and database work but C++ is better for the system level work. I've found the best way of bringing the two together is via COM objects and ATL makes creating these easier. Michael :-)
-
Steve good point :) Senario: I am product manager in charge of developing a new Inhouse system called SystemX SystemX requires database access, serial communications, web access, sexy front ends. SystemX is also a mission critical application. I require this system to be built using OOD, OOP. The highest population of programmers are VB? Do I try and use VB programmers to design and implement the system, is VB the best tool?. I cant use C# (learning curve etc.) VC++ would be the better choice but the timescales are tight. What should I use to develop SystemX? BTW for this exercise assume VS.NET is released. Thoughts please.
VC++. To justify the language the project should be built with based on the notion that there exists a larger number of programmers available who can code in that language (gee, I wonder why?) is a prescription for disaster. VB interfaces are not "sexy" they are ususally just slow, over blown monstrosities designed by frustrated art school drop outs.
-
Steve good point :) Senario: I am product manager in charge of developing a new Inhouse system called SystemX SystemX requires database access, serial communications, web access, sexy front ends. SystemX is also a mission critical application. I require this system to be built using OOD, OOP. The highest population of programmers are VB? Do I try and use VB programmers to design and implement the system, is VB the best tool?. I cant use C# (learning curve etc.) VC++ would be the better choice but the timescales are tight. What should I use to develop SystemX? BTW for this exercise assume VS.NET is released. Thoughts please.
I do agree with some of the other comments so far, but want to add a few things. First as a manager, you might want to see what your group knows to begin with. If you have all VC developers making them do the project in VB might not go over well. As for VB programmers being the highest population, well that would probably include the web developers that just do VBscripting, the people that know VBA, as well as the VB programers that range from 14 years old to 60+. I have always wondered why people think that VC programming takes alot longer than VB programming. Maybe you can answer that one. The time to draw the dialogs or other windows is the same. With MFC, the IDE can add functions for events on buttons and other controls (just like VB). Where is the increased speed of VB? I am talking about experienced VC and VB programmers might you, not people learning it. Steve Maier, MCSD
-
I do agree with some of the other comments so far, but want to add a few things. First as a manager, you might want to see what your group knows to begin with. If you have all VC developers making them do the project in VB might not go over well. As for VB programmers being the highest population, well that would probably include the web developers that just do VBscripting, the people that know VBA, as well as the VB programers that range from 14 years old to 60+. I have always wondered why people think that VC programming takes alot longer than VB programming. Maybe you can answer that one. The time to draw the dialogs or other windows is the same. With MFC, the IDE can add functions for events on buttons and other controls (just like VB). Where is the increased speed of VB? I am talking about experienced VC and VB programmers might you, not people learning it. Steve Maier, MCSD
-
I do agree with some of the other comments so far, but want to add a few things. First as a manager, you might want to see what your group knows to begin with. If you have all VC developers making them do the project in VB might not go over well. As for VB programmers being the highest population, well that would probably include the web developers that just do VBscripting, the people that know VBA, as well as the VB programers that range from 14 years old to 60+. I have always wondered why people think that VC programming takes alot longer than VB programming. Maybe you can answer that one. The time to draw the dialogs or other windows is the same. With MFC, the IDE can add functions for events on buttons and other controls (just like VB). Where is the increased speed of VB? I am talking about experienced VC and VB programmers might you, not people learning it. Steve Maier, MCSD
>> Where is the increased speed of VB? The key thing that makes the development in VB faster over VC is a new programming paradigm called Component Based Development, or CBD in short. Components in VB are standalone software modules that have two key attributes, called "Property" and "Event". Unlike the VC's C++ class based components, a VB component can be *hooked* to the existing app a lot quicker using these attributes that really drive VB's RAD IDE. Yes, you can visually insert and add event handlers to controls in VC++ too, but that is only limited to controls found in resource-based dialog only, not *any* C++ component. You may need to use 3rd party add-on tool (like RadVC / www.capitolsoft.com) to have that kind of speed in VC++.
-
>> Where is the increased speed of VB? The key thing that makes the development in VB faster over VC is a new programming paradigm called Component Based Development, or CBD in short. Components in VB are standalone software modules that have two key attributes, called "Property" and "Event". Unlike the VC's C++ class based components, a VB component can be *hooked* to the existing app a lot quicker using these attributes that really drive VB's RAD IDE. Yes, you can visually insert and add event handlers to controls in VC++ too, but that is only limited to controls found in resource-based dialog only, not *any* C++ component. You may need to use 3rd party add-on tool (like RadVC / www.capitolsoft.com) to have that kind of speed in VC++.
Are you talking about inhouse VB modules, 3rd party ones, or both? Adding an ActiveX component to a VC app and setting a variable up for it is not that difficult. The original question was about starting an app from scratch, with database, serial, pretty interface, etc..... From those loose requirements the speed of developing a VC program or a VB one might not be that different. It depends on the developer and their experience with each of those things. Steve Maier, MCSD
-
>> Where is the increased speed of VB? The key thing that makes the development in VB faster over VC is a new programming paradigm called Component Based Development, or CBD in short. Components in VB are standalone software modules that have two key attributes, called "Property" and "Event". Unlike the VC's C++ class based components, a VB component can be *hooked* to the existing app a lot quicker using these attributes that really drive VB's RAD IDE. Yes, you can visually insert and add event handlers to controls in VC++ too, but that is only limited to controls found in resource-based dialog only, not *any* C++ component. You may need to use 3rd party add-on tool (like RadVC / www.capitolsoft.com) to have that kind of speed in VC++.
-
Steve good point :) Senario: I am product manager in charge of developing a new Inhouse system called SystemX SystemX requires database access, serial communications, web access, sexy front ends. SystemX is also a mission critical application. I require this system to be built using OOD, OOP. The highest population of programmers are VB? Do I try and use VB programmers to design and implement the system, is VB the best tool?. I cant use C# (learning curve etc.) VC++ would be the better choice but the timescales are tight. What should I use to develop SystemX? BTW for this exercise assume VS.NET is released. Thoughts please.
Tight timescales does not mean you will have the luxury to have a solid design right off the start. You will probably do even more number of quick small changes. VS.NET release does not immediately mean you will have a lot of VB crowd well-conversant with threads, and a lot of C++ programmers well conversant with typed value management or GC. Given all the context, therefore, I would suggest the following: - Initially, a core C++ team does a rapid VC++ dev, without implementation in COM/ATL. IDLs are written and revised, but actual implementation has only C++ interfaces. Database design is modified frequently as needed, with isolated chunks of quick-and-dirty VB/VBS scipts. Get the database design, middleware to database interface, and serial comm right this way. Team will also have hardware net engineers and database designers (guys who had both admin and stored procs and VB experience) right at this stage. As to desktop GUIs: Quick and dirty GUIs, to be thrown away (yes!, esp. *because* it's a tight schedule) can be built in either VB or in VC++ depending on the relative strengths of the people you have already gotten. (I do agree, VB and VC do not differ in terms of development times, as of today.) - As soon as the dependencies, use-cases, multiplicity, and lifetimes of Big Rock object and database tables become clear (with something already running on actual computers), take the core C++ objects into ATL COMponents. Starting with ATL COM may not meet the schedule as the team gets sucked into the gravity field of Singleton/Not, TearOff vs CachedTearOff, use WTL or not, target ATL 7.0 or not, use smart-ptr or not, etc.; and simply has to manage additinonal debugging due to ATL/COM. (You *could* start with ATL/COM, if the leader is competant and strong and the team is "jells well" together). - COM wrapping (componentization) spells out time for the ASP/DHTML folks to come into picture. Scaleability design reviews with COM+ runtime (MTS/MSMQ) and ISAPI dlls etc. to be done at this stage. Load-balancing review and any necessary server redesigns TBD at this stage. Main security strategies to be finalized at this stage. - From now on, COMponent development assumes normal flow (IDL to C++). Number of COM interfaces will expand at this stage. If you have money, you can create pretty pictures (clouds, pipelines, arrows, etc.) at the end of this stage. Sorry UML, but at least thus far, I have never seen a team that could draw pictures before this stage and also deliever a working system in Internet speed. (Also ha
-
What us VC++ developers it reassurement on the feature of VC++, maybe Chris could ask somebody from the Microsoft Languages Unit to comment on VC++. Lets face it Mike Blasczak left the MFC/VC++ in March 1999, he left the team becase the team and project was being wound down - Is this true. I known B eikM (Mike Blasczak) is now working on the SQL Server team. Microsoft better answer soon or they will lose alot of Windows gurus. The future looks bleak, so Microsoft what have you got to say on the subject?
I'm not sure exactly what you're looking for. Your post is very vague about what you are looking for. Microsoft, and especially the VC program managers have been very busy assuring us that VC++ is very important and will stay around. There are literally dozens of threads right here on Code Project from VC program managers talking about this. But even if they were dropping VC as a product today. So what? There are lots of alternatives. Big deal. It's all nothing to get defensive and insecure about.
-
Steve good point :) Senario: I am product manager in charge of developing a new Inhouse system called SystemX SystemX requires database access, serial communications, web access, sexy front ends. SystemX is also a mission critical application. I require this system to be built using OOD, OOP. The highest population of programmers are VB? Do I try and use VB programmers to design and implement the system, is VB the best tool?. I cant use C# (learning curve etc.) VC++ would be the better choice but the timescales are tight. What should I use to develop SystemX? BTW for this exercise assume VS.NET is released. Thoughts please.
I wouldn't want to seem bias (I'm a VC++ developer), but I've worked on many different projects that include VB code. Every project started ok, and managers were very impressed with fluffy interfaces and the speed at which they were developed. However later on down the line, these VB project were eventually ported to VC (additional cost?) due to a number of reasons: 1) The VB programmers we employed were cheaper than VC developers and the quality of code reflected this - This is NOT a generalisation, it's just what we experienced. 2) Performance - especially when high data volumes are involved (database access). 3) Identifying low-level bugs became a nightmare - VB hides as much complexity as possible, which is good until you need to drill down to find out what's gone wrong. However, not everything's jam and cream with VC - It is absolutely imperative to have a solid framework developed for VC before development begins on a large project. A good experienced VC analyst/developer (expensive?) is required for this. It can also be quite frustrating to project team-leaders/management while this foundation framework is developed. In conclusion, does the project need to done quickly, or correctly?
-
I wouldn't want to seem bias (I'm a VC++ developer), but I've worked on many different projects that include VB code. Every project started ok, and managers were very impressed with fluffy interfaces and the speed at which they were developed. However later on down the line, these VB project were eventually ported to VC (additional cost?) due to a number of reasons: 1) The VB programmers we employed were cheaper than VC developers and the quality of code reflected this - This is NOT a generalisation, it's just what we experienced. 2) Performance - especially when high data volumes are involved (database access). 3) Identifying low-level bugs became a nightmare - VB hides as much complexity as possible, which is good until you need to drill down to find out what's gone wrong. However, not everything's jam and cream with VC - It is absolutely imperative to have a solid framework developed for VC before development begins on a large project. A good experienced VC analyst/developer (expensive?) is required for this. It can also be quite frustrating to project team-leaders/management while this foundation framework is developed. In conclusion, does the project need to done quickly, or correctly?
Very good points Alan. I have also seen things similar to what you are talking about, but also that since VB was used the customer moved the project deadline up because it was just VB and it should be easy to do these things. Oh course they also changed what they wanted constantly too, but that could be a complete other thread to discuss. Steve Maier, MCSD
-
What us VC++ developers it reassurement on the feature of VC++, maybe Chris could ask somebody from the Microsoft Languages Unit to comment on VC++. Lets face it Mike Blasczak left the MFC/VC++ in March 1999, he left the team becase the team and project was being wound down - Is this true. I known B eikM (Mike Blasczak) is now working on the SQL Server team. Microsoft better answer soon or they will lose alot of Windows gurus. The future looks bleak, so Microsoft what have you got to say on the subject?
VC++ isn't dead. MFC isn't dead. ATL isn't dead. C++ developers are very important and strategic customers for Microsoft. We will continue to listen and enhance the C++ product for many years to come. Don't forget that every product Microsoft ships is built with Visual C++, many of which heavily use MFC and/or ATL as well. With that, the CLR and C# are great new tools and should be seriously considered for new application development. They're going to be very useful, even if you also have to use C++ as well. Its just another tool in your arsenal to apply to the appropriate problems. Later, Walter Sullivan Lead Program Manager, ATL/MFC