Ummm is there something about me or is it really true that C++ is being given a could shoulder on this forum. I mean reading the profiles on the roll call thread, I think almost everyone has a VB/.NET background. Am I really alone out here? It would feel
nice to KNOW there are C++ guys out there, and while ur at it why don't we discuss what should and shouldn't be done about MS VC++?
I think there are lots of us c++ heads around, so a C++ topic would go down well. The majority of MS people who are .net people now were c++ people a few years ago etc, and certainly in my group much of our work still requires c/c++ coding. This is no
bad thing imo, though it's hard going back to those dangling pointer issues...
I'm not sure how many guys from the actual c++ compiler team are here, but i'm sure we could get them to join in, if we need them to.
Why don't you get us started compiler...what particular topics would you like to chat about?
I use C++ for the desktop and PHP for the web.
It's too difficult to keep up with the various technologies that come in and out of favor (Win32, MFC, COM, .Net) so in my current project my app is separated into a core lib and a GUI. The lib is written as much as possible in pure, unmanaged C++, even keeping Win32
calls to a minimum. This increases portability and doesn't require many updates when the technology changes.
The GUI will have no restrictions and will use whatever whizbang, platform specific technology is available.
Maybe they're too busy trying to track down dereferenced nulls and unchecked bounds to join this forum.
Complaining about dangling pointer issues is really harsh nowadays what with boost.org supplying a plethora of smart pointers, pointers being de-allocated inside destructors, MFC providing a superb memory dumping interface, CString providing the Format function
so you can kiss goodbye to sprintf bugs, and string vector and list providing superb general purpose containers. Add to this some creativity (using the proxy design pattern and operator overloadng to create your object when the first time you access anything
with ->) and memory doesn't give you any problems at all. It is interesting to note that ALL the recent exploits microsoft got was because of old school C code and not C++ code. And really using .NET isn't a blanket guarentee for end to security headaches.
Case in point: the recent scripting bug which was due to an integer overflow. These kind of bugs can occur in both .NET AND JAVA. Similarly, the data poisoning bugs (sending an apostrophe and go combination in a web form to terminate the current query and
executing your own) are also possible everywhere.
Hmm what do I want to talk about? I wrote a rather lengthy essay in the VisualCPlusPlusFeedback wiki which can be found under the ProductFeedback wiki. You could read it there and add your thoughts there or come back and reply on this thread.
I also want to discuss the mutilation of C++ being done in the name of porting it to .NET. It just isn't the C++ we love and are used to. Whats more, Microsoft has gone on and made it a 'standard' [sic] too. Well I know one thing, I ain't gonna support that
standard. I like C++ just as it is thank you very much.
Also, given the push about the recent Service Oriented Architecture, doesn't it seem that desktop applications are going to shrink in the near future. So just so we know what direction the world is going to, why not tell us all what C++ apps you guys are working
on and how does your company plan to continue them in the future. Do you feel that C++ is slowly going to wane away into obscurity??
The company I worked in uptil last year used MSVC++ to create a back office application for the WRAP account industry. Our clients included Citibank USA, Independence Investments, Eaton Vance etc. The app was a client/server one, bringing data from the database,
performing some calculations and uploading the results again. They ran it on nightly shifts and used the reporting facilities in the morning.
One of the problems with database querying which we had is that both OLEDB and ADO don't support Bulk operations so we had written our own wrappers around native libraries for MSSQL, ORACLE, and Syabse and used those. Also, our product was database agnostic,
we supported ALL RDBMS and the architecture was such that it could easily support a little known Object Oriented database called Vision which is used exclusively in the financial industry.
I agree largely... the team I'm on has a massive amount of legacy code written in C an C++. We don't use smart pointers, though... we found that they created more problems than they fixed. We rely on testing, code review, and tools to find leaks.
I think that despite the development happening in C# and the like, I would still like to program in C and C++. Microsoft should stick to development of that too, and I for one would be quite bummed if MFC and VC++ were to go the way of the dodo.
Generics are cool, but I would like my templates too. Managed code is cooler, but please let me have unmanaged code when I want to.
(Although some might argue that the problems with templates, exception handling and the like are better handled in C#, but thats a whole different ball-game)
I do not want to make this sound like, BSD is dying! - but with everyone and their brother pushing Java and C#, it does sound as if they are trying very hard to convince us developers that C and C++ are dying.
I remember reading somewhere on the
MS Forums that Longhorn internals have in fact been coded in C# - is that supposed to mean something?
I don't think C++ is dying...I can't remember the source, probably Stroustup's site...but I think recent data shows that C++ use is still growing. C# does not trump C++ on features or coolness. It's just a different tool for a different sort of task.
My mantra from the time I started programming was to avoid languages that didn't let me at the hardware. C++ is one of the few relatively higher-level languages which can be used to write a whole operating system. C# and Java fail miserably at that. C++ is
also amazingly elegant as a multi-paradigm language with its focus on type creation. It really is very different from languages like C# and Java in this respect. Further, although C# lets you forget about memory,
resource management is a total pain. Because there are no true destructors, you have to write contortions in your code just to free up file handles, semaphores, etc. You'll have serious problems if your code doesn't do it properly, as the garbage collection
for those objects is very slow (see the documentation on dispose). I find the C++ model easier to deal with, though you do have to think a lot more about resource ownership. (The reason is that an object can free itself up in the destructor. In C# you
have to have using blocks all over, making it the caller's job to deal with it.) C++ also lets you write very smart customized memory allocators that are very fast. And if you compare C# generics and C++ templates in depth, you'll see that they are
not at all the same thing.
That being said, C# and Java are great for many types of applications. They have built-in security features and an amazingly rich library. They are simple enough to whip out some decent applications in a hurry. In general, I say choose the right tool for the
job; no single language is perfect for everything. We use both.
I would not be surprised if new Windows APIs appeared only in managed code. After Win32 Microsoft started making some COM-only APIs. This is Microsoft's next evolution. (From what I have seen so far, though, under every new .Net API is a C/C++, COM, or Win32
API.) I think Microsoft likes to keep us developers scrambling to keep up with all their new APIs to do the same old stuff. It certainly gives them an edge.
Fortunately I think there is good evidence that Microsoft is still investing heavily in C++. VC++7 includes new things like ATL Server for web services, better ISO compliance, and managed code integration. Integrating managed code was a huge task; I don't think
Microsoft would have done it if C++ was "dying".
Unfortunately, Microsoft likely has MFC in maintenance mode, will never officially support Windows Template Library, and wants us to use managed code for the GUI even in C++.
Its really saddening that MFC 4, the basis for the current version, was designed at a time in which C++ itself was in a state of flux. As a result its design isn't as good and, more importantly, as intuitive and easy to grasp as it could have been. I have
a hunch, based on my observation of fellow students in undergraduate computer science, that many of todays VB/Java/.NET programmers had an early fling with MFC, found it too complicated because it requires you to know your way around the base classes if you
want to do any substantial modifications, and switched over. Combine this with the false allegations bandied around on C++ itself being exceedingly complex and you end up with a language that is scorned for just not the right reasons. When I first started
on Java, I was told it is easy to use and doesn't let you shoot yourself in the foot and that it is really and truly 'Object Oriented' from the grounds up. Well when I actually used it I found it lacked the expressiveness that is afforded by C++ what with
lack of pointers and no operator overloading and no templates either. And the Swing architecture and the scoping rules for inner classes and unnamed event handlers are quite cumbersome to deal with. It surprises me then, that so many programmers would flock
to the fold of 'managed code', scared of dangling pointers and not freeing up memory when in modern C++ these are non-issues if you follow standard programming practices. And as it has matured, they have had to add templates and stuff to Java also. The only
issue that remains is security. Managed code can limit what APIs are called by programs but such checks could also be placed in unmanaged APIs.
Anyways, what has got me concerned is that developing core operating system components in C# is going to REQUIRE C++ programmers to do managed code. And that would mean patronizing the mutilitated version of C++ Microsoft is pushing as a 'standard' for CLI.
Also, currently I do not understand to what degree it will affect our ability to use standard C++ and design our programs around it. Would the new API force us to desing our programs around the restricted version? Would you programmers out there accept that?
Also, I would like to hear what others think could be done to improve VC++.
Ok. Just read the C++ CLI Candidate Base Draft, Nov 21, 2003 and got some misconceptions corrected. C++/CLI isn't so much of a mutilitated version as I previously thought. Even so, I have a LOT of question. Any team member out there willing to answer these?
For starters, the draft says C++/CLI is a superset of standard C++ but as far as I understand, multiple inheretence is not supported except for interfaces so technically it can't be called a superset. I have got more questions but is anyone out there listening?
Hi, I'm one of the members of the VC team (Kang Su Gatlin, VC Program Manager), and I'd be happy to answer some questions people might have. I actually work on the back-end (code generation, optimization, and all that other fun stuff), and of course there
are others who focus on things like the language and libraries. I'll answer what I can and defer issues to other members of the team.
Regarding C++/CLI being a superset... any legal C++ program should still compile and be semantically equivalent with a conforming C++/CLI compiler. What does this mean... C++/CLI has added functionality on C++, but hasn't removed or created problems with the
current C++ standard. Folks like Brandon Bray, Herb Sutter, Jeff Peil, etc... went through great pains to make it so.
In particular you ask about multiple inheritence. MI is not supported in the CLI, so managed types don't support multiple inheritence, but all your unmanaged types still do. Does that make sense?
I think you'll see that we've made the managed story quite good, while at the same time given the "native" C++ developer a boatload of goodies as well.
I'd love to hear feedback and to help with questions you may have.
Please fix the
mixed DLL loading problem . It's really a pain that consumers of mixed C++ DLLs have to call a non-standard initializer function. This is especially painful for developers who release libraries for sale.
I say this because one of the more exciting features of Visual C++ is the ability to write some cool low-level code and make it usable from any .Net application. It's unfortunate that the problem requires consumers of your DLL to take special action to initialize
it properly. (I know there are other ways to make your code available, but using a mixed-mode DLL allows you to expose a nice rich interface via .Net.)
Supporting WTL officially would be pretty cool too.
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.