|
C++? Opinions?
So, what does everyone here think of C++?
I really don't want to read through another flamewar :-)
My $.02:
Lots of very useful tools, very good (but not yet complete) libraries, but a very idiosyncratic language. A good C++ programmer has to have an acute awareness of what they're doing and strong discipline to use just the features necessary to get the job done.
It's my favorite language, but I still think it's ugly and can be a pain to use :-)
Lally Singh
Wednesday, December 24, 2003
The thing about C++, is that it's
Æ
Wednesday, December 24, 2003
Pro: Unencumbered language environment w.r.t. licensing. If you use Java or .NET then you are beholden to their creators' potentially changing business and licensing models.
Con: Decrepit development environments. Visual studio is not bad, but we really need to move away from a flat-file translation unit model to something like Java's database model. Right now, a C++ class definition defines both public interface and private implementation details. You can't change the implementation without recompiling anything that depends on the interface. Devices such as the pimpl idiom try to mitigate this, but the development environments should be smart enough to not require this.
I haven't tried Eclipse for C++ development. I'm not sure if it would do anything useful. Anyway, it requires Java so it is legally questionable if I can run it on any of my machines.
Yes, legally questionable. Sun's license grants you the right to use their JDK and JRE for the purpose of development and testing of your own Java applications. It does not explicitly permit you to run other people's applications (presumably all of which ship with a licensed copy of the JRE. Yeah, right.)
David Jones
Wednesday, December 24, 2003
After programming in Python--or any other language that's attempting to be higher-level and more modern--C++ feels very retro and awkward to me.
I'm still shocked that C++ doesn't have any kind of real module system, instead leaning on header files and #include hackery. A module system is 1970s tech, but they're so hard to leave once you've used a language with one: Modula-2, Object Pascal, Oberon, Ada, Python, Perl, etc.
Junkster
Wednesday, December 24, 2003
C/C++ and Java are for programmers who like to write code, lots of code. Every study I've seen comparing them to scripting languages like Python, Perl, or TCL shows about 3-10 times as much code to do the same thing.
http://www.cis.udel.edu/~silber/470STUFF/article.pdf
The other interesting thing you find from those studies is that lines of code per hour and bugs per line of code are roughly the same across all the languages. You do the math on productivity/quality.
Tom Hathaway
Wednesday, December 24, 2003
"You can't change the implementation without recompiling anything that depends on the interface"
I'm not a C++ guy, but doesn't COM take care of this? (And I'm guessing CORBA on the other side of the fence)
Philo
Philo
Wednesday, December 24, 2003
The strengths of C++ are, IMHO, its facilities for generic programming, its static type system, and such maligned attributes as multiple inheritance and deterministic destruction. In a certain context, these features are incredibly important and very very powerful. However, as has been noted by another poster, they have some overhead -- so in certain cases, scripting languages with less 'rigidity' (eg: dynamic typing, dynamic interfaces [message passing over method invocation]) are a better choice.
If you want to analyze the importance of a language with respect to speed of development, there's more than one way to look at it. On the one hand, you'll find lots of problems like generating web pages or defining agent behaviors in video games where a scripting language affords much more flexibility and (in that market) it's important to have that flexibility. In such a circumstance, the scripting language has a tremendous benefit over traditional static languages like C++. But that flexibility comes at a cost, and it's increased variability of behavior in certain circumstances. For example, subtle type coercion issues must be considered, as must message interpretation details and such. You have to be much more rigorous with testing large dynamic programs because huge classes of errors can only be caught by visiting every branch of the code. If you send a message to an object but you misspell the name of the message, you might not find out until that odd edge case where it's really critical (but by then it's too late).
Also, with C++ you're not locked into a particular development paradigm. To some extent this is true with other languages as well, because you can emulate a sort of Turing machine model in Lisp just as well as you might emulate a sort of lambda calculus model in C++. However, it's very important to be able to turn off the garbage collector or force static analysis of code sometimes. It's not just for performance reasons, as some people frequently claim, but it's for simplicity of maintaining the program as well.
K
Wednesday, December 24, 2003
Philo:
Please point me to an implementation of COM for Unix-like systems.
Involving layers of Microsoft proprietary technology is not appropriate for large-scale high-performance databases used in semiconductor chip design.
I am not aiming for application interoperability, just avoiding unnecessary recompilation during development.
David Jones
Wednesday, December 24, 2003
<quote>
You can't change the implementation without recompiling anything that depends on the interface
</quote>
That's wrong. You can't change the class definition w/o recompiling, but as long as you use seperate compilation units, you can change the implementation to your hearts desire and only have to recompile the changed implementation.
<quote>
doesn't COM take care of this
</quote>
It can, but it doesn't have to.
<quote>
Please point me to an implementation of COM for Unix-like systems
</quote>
http://www.mozilla.org/projects/xpcom/
enjoy!
Wednesday, December 24, 2003
"You can't change the implementation without recompiling anything that depends on the interface".
See "Cheshire Cat".
Grumpy Old-Timer
Wednesday, December 24, 2003
"you can change the implementation to your hearts desire and only have to recompile the changed implementation."
Not if the implementation change adds/deletes/changes any private members. Then all client code must recompile.
sgf
Wednesday, December 24, 2003
true dat sgf!
enjoy!
Wednesday, December 24, 2003
"Please point me to an implementation of COM for Unix-like systems."
You could have kept reading to where I mentioned CORBA, or I could point out that *you* mentioned Visual Studio, somewhat setting the stage for a "windows" answer. :-D
"Involving layers of Microsoft proprietary technology is not appropriate for large-scale high-performance databases used in semiconductor chip design."
With all due respect, you're all over the map here.
1) You're *writing* the databases? Or consuming them?
2) Neither "Microsoft" nor "proprietary" by definition excludes "large-scale" or "high-performance"
"I am not aiming for application interoperability, just avoiding unnecessary recompilation during development."
Here we get to the crux of the matter - that the issue may be that COM is too heavy-weight for what you're trying to accomplish, which I can appreciate. I wasn't sure if C++ worked like COM (I thought it did, others have confirmed) - that so long as you isolate the interface, you are free to change the implementation without recompiling consumers of the interface.
Sorry to have muddied the waters. :-)
Philo
Philo
Wednesday, December 24, 2003
This is veering off topic, but COM's pretty simple, and I believe fully specified. (At least for Windows--it's a binary system so might be hard to specify across all Unixes.)
Basically take the Vtable similar to what C++ objects have, make sure it's a particular format (it just happens to match what the Microsoft compilers produce for C++, but can be tweaked with either compiler setting or generated C structs), and load the vtables at runtime with a known method call, using some specfic rules about refcounting to manage object lifetimes.
mb
Wednesday, December 24, 2003
> doesn't COM take care of this?
Not really any better than you can do in straight C++. Usually, you define a COM interface in an idl, and then implement it in a (C++) class. Client code only has to be recompiled when the interface changes. If you do the analogous thing, ie define the interface in an abstract C++ class, you get the same benefit.
Brian
Wednesday, December 24, 2003
Tom-
"C/C++ and Java are for programmers who like to write code, lots of code. Every study I've seen comparing them to scripting languages like Python, Perl, or TCL shows about 3-10 times as much code to do the same thing."
That may be the case, but when you are writting or doing console game development, Python, Perl or TCL just don't cut it due to performance issues and low level control. I am sure embedded system programmers with realtime requirements are probably in the same boat here.
Even C looks like a good solution in these domains.
- Raist
Raist3d
Thursday, December 25, 2003
Philo,
COM and C++ aren't words that go well together. It may be that I'm just clueless about it, but in the past I've found COM interfaces to be a major pain in the tail when accessed from C++.
Fortunately it is a language blessed with utility libraries to handle nearly any task you can think of. This goes a long way to avoid the need for COM. This falls down, of course, when you need to explicitly use COM objects like MS-Office documents.
Clay Dowling
Friday, December 26, 2003
Clay,
COM was built on C++, I find them to play very well together. If you grok abstract base classes and dynamic loading, that's really all there is to it.
Friday, December 26, 2003
COM at it's heart is really just a set of C++ coding conventions. You can do COM style programming in straight C++ without a single API call. Go to a bookstore or library and read Chapter 1 of "Essential COM" by Don Box. He explains this better than anyone else.
The complications in using COM arise from three factors:
1) The idea of location transparency - being able to do an inprocess, cross process, or cross network call without the client needing to code differently implies constraints on the programming model. For example, this is the reason that COM methods can only use the return values for error codes; the networking stack needs a standard place to put failure information. Useful in DCOM, it gets in the way when you're using DLL's.
2) Performance. A large class of COM infrastructure is all about optimization. Apartments. The free-threaded marshaller. The Global Interface Table. Aggregation. The rules of QueryInterface.
3) Visual Basic. Microsoft handed over the architecture of COM to the VB team at one point, and we've all been paying the price for that ever since. Type libraries, automation, and that VB programmers don't understand what a GUID is are all artifacts of this. This one is particularly galling to me, because if the VB people had just thought outside their tiny little box for half an hour, most of the pain of automation would just be gone. But they didn't, and as a result each and every COM object will be implementing IDispatch until the end of time.
Chris Tavares
Friday, December 26, 2003
Chris,
"Essential COM" was my first introduction to COM programming. Unfortunately it's the constant implementation of IDispatch that gives me a pain in the tucas. It's been several years since I last looked at COM; my first experience really put me off, although I was very inexperienced at C and C++ programming at the time. Now I spend my days writing Win32 apps without the benefit of MFC, so it might not bother me as much.
Clay Dowling
Monday, December 29, 2003
 Recent Topics
Fog Creek Home
|
