Review:Advanced CORBA Programming with C++ 102
| Advanced CORBA Programming with C++ | |
| author | Michi Henning & Steve Vinoski |
| pages | 1120 |
| publisher | Addison-Wesley |
| rating | 9/10 |
| reviewer | rw2 |
| ISBN | |
| summary | A much anticipated book that lives up to it's promise. |
Waiting
I've been programming in C++ for a long time and started working with distributed applications using RPCs and sockets. When I moved on to CORBA lots of things got much easier. Learning CORBA though, wasn't one of them. There has been a perpetual dearth of good materials to learn from. Through C++ Report I was familiar with Steve Vinoski's writing style and experience base. He is always an easy read. A welcome change in what can sometimes be a twisted topic.Michi Henning doesn't know it, but he answered dozens of questions for me over the years through the archives of his hundreds of Usenet posts on dejanews. In fact, more often than not if I'm looking for information on CORBA I'll add his email address to the authors field and go straight to the authority.
With that in mind, I was quite anxious to see their book, and quite impatient when its date was pushed back a couple times. To say that these two are qualified to write on the subject is a huge understatement. Whether or not they could write a book of the magnitude that they attempted with a consistent level of accuracy and readability was another question.
Great Thud Value
The first thing to know about this book is that it isn't for wimps. Which is to say that at ~1100 pages it will take a bit of effort to haul this puppy around. My laptop bag is going to be very happy to not be porting this tome around once this review is sent off to Hemos. This is one intimidating book to heft as you decide whether or not to buy your copy. For this reason, I suggest buying it through Amazon. By the time you lift it for the first time it will already be paid for and you can get on with the business of learning more about CORBA instead of wondering if you will ever get through it all.Style
Lots of people have a word processor, but these two really lived up to my expectations for an accessable text. Their writing style is non-professorial and never talks down to the reader. It is clear they know their topic like a politician knows a contributor, but they also seem to still enjoy what they do. Many times reading advanced topic books it seems like the author is just waddling through in order to get publicity, a paycheck or a resume item. These guys write on the subject as if they are glad to be working with the stuff.So what's in it for me?
The world of CORBA. Nothing less can tell you what the information in this book is. There is simply nothing else on it's level. Once you start sifting through this one, make sure to check out Steve Vinoski's and Michi Henning's web pages for pointers to even more information.Organization
The book is partitioned into major topic areas with chapters within each. The title of the book announces the intention to focus on advances topics and, while a novice programmer would have trouble with it, a competent C++ programmer with any network experience would have little difficulty jumping in and starting with just this book. That said, it does get deep pretty quickly.The entire book is very example heavy and the first part starts the trend with an introduction to CORBA. They walk through a simple application, presenting only the IDL and code needed to get it to compile and run. After reading this section you still feel like your in deep water then take a step back and get a more introductory book to work through first. Part I is probably sufficient to get experienced programmers up and running though.
Part II focuses on the programmers interface to CORBA, IDL and the C++ mapping. These chapters reveal the flavor of the rest of the book. Highly detailed, yet emminently readable. In particular their intermingling of the technical issues with occasional paragraphs about the workings of the standards committee and the motivations behind the design are quite elucidating. It's one thing to understand the standard, but understanding it's foundation, motivation and direction is very important to becoming one of the greats.
Part III covers the "under the hood" aspects of how CORBA communicates between applications. These chapters are insteresting, but rarely come up in normal programming. The only possible use that comes to mind is perhaps in difficult to diagnose problems between vendors. These chapter provide plenty of background and details to point fingers at the right folks.
Part IV is a look at dynamic CORBA. Dynamic CORBA allows compliant applications to assemble the structures needed to communicate with servers that were unavailable, undeveloped or not even thought of at the time the client was compiled. Like Part III this section is more useful to those with fairly specific needs.
Part V delves back into more commonly used aspects of CORBA, the services. Very few CORBA systems are implemented without the naming service and as the state of the art matures more are using trading and events also. These are all well covered, including a smattering of OMG politics.
Part VI looks superficially like a heavyweight section, but even though it is hidden in the back, it's a gold mine of information. Folks implementing there first systems of any scale should make certain to read this section to assure that they don't go down a path that is difficult to recover from later.
This book is worth the price of admission and then some.
You can pick this book up at Amazon.
Table of contents
- 1) Introduction
- Part I Introduction to CORBA
- 2) An Overview of CORBA
- 3) A Minimal CORBA Application
- Part II Cora CORBA
- 4) The OMG Interface Definition Language
- 5) IDL for a Climate Control System
- 6) Basic IDL-to-C++ Mapping
- 7) Client-Side C++ Mapping
- 8) Developing a Client for the Climate Control System
- 9) Server-Side C++ Mapping
- 10) Developing a Server for the Climate Control System
- 11) The Portable Object Adapter
- 12) Object Life Cycle
- Part III CORBA Mechanisms
- 13) GIOP, IIOP, and IORs
- 14) Implementation Repositories and Binding
- Part IV Dynamic CORBA
- 15) C++ Mapping for Type any
- 16) Type Codes
- 17) Type DynAny
- Part V CORBA Services
- 18) The OMG Naming Service
- 19) The OMG Trading Service
- 20) The OMG Event Service
- Part VI Power CORBA
- 21) Multithreaded Applications
- 22) Performance, Scalability, and Maintainability
Re:C++ (Score:1)
1. C++ is bloated, it has too many features.
No one forces you to use all the features. Features which you do not use do not bloat your code. Even though I personally find almost all of C++ features useful in some way, I do not use 100% of them every time I start a project.
Things such as multiple inheritance (which I find extremely useful especially when it comes to CORBA), operating overloading and what not are there to help simplify your code...
I think this is probably one of the few times people have complained that something has too many features.
2. C++ is missing some features like garbage collection.
C++ is also missing a built-in mail client, a recipe for ice cream, and fourty-two flavors of regex processing.
You want a feature, there are 1000 different sources for them.
The addition of things such as garbage collectors, bounds checkers, etc *would* bloat the executable.
3. C++ is too complicated, I can't understand it
This is probably one of the sillier arguments. Just because you don't undersatnd it doesn't mean no one does. C++ and other languages based from it (Java), are easy to understand and work with once you understand the principals.
If you are used to using languages which are not similar to C++ and provide OO features, then you will be confused.
I just find it stupid that someone would consider using an underdeveloped, nonstandard, and completely unsupported language because they don't like the way C++ code looks and they don't understand how it works.
These are the same people who write new SMTP servers from scratch because they didn't like the configuration file format of existing ones.
--
Re:C++ (Score:2)
C++ itself is a fine language. It's been proven that above about 50k lines of code, C++ is far more efficient to work in than C and simply easier to understand.
What really bugs me are the people who say C++ is complex because it features things like operator overloading. This always struck me as funny, just because a feature exists doesn't mean you have to use it.
And C++ is well accepted. BeOS uses it as it's primary application development language as does Windows. Until recently C++ was horrible to develop for under Unix because of the poor compiler support, but Egcs has changed that.
Now I don't want to start a language war, but really... is there any real reason why C++ is a bad language or is it because you simply don't understand it?
--
If ObjC is dead, so is MacOS X (Score:1)
It's still a very viable alternative, and recieved a major blood tranfusion with Mac OS X.
Re:Its history. (Score:1)
Hiding implementation details (Score:1)
class SomeImplementation;
class SomeInterface
{
SomeImplementation *imp_ptr;
public:
void method1();
etc...
};
It's a slight pain because programmer needs to instantiate SomeImplementation in SomeInterface constructor and then pass all methods onwards:
void SomeInterface::method1()
{
imp_ptr->method1();
}
etc
It's only worth doing on classes that provide interface between major modules (eg between one programmers area of responsibility and anothers) - but worth it since implementation changes never require recompilation of client modules.
Not Surprising [systems vs. applications] (Score:1)
X is bigger than Linux.
GIMP is bigger than the Standard C Library.
Why should it surprise you that a CORBA book is bigger than a book on fundamental algorithms?
PS: I have both books and they are both great.
Heartily recommended, follows standards (Score:1)
As an aside, I recommend TAO as an ORB to go along with the book. If you don't need multithreading then MICO would also be a good choice.
Re:I ordered this book through fatbrain.com (Score:1)
The CORBA Random Number Server (Score:1)
Re:C++ (Score:1)
> programming language is an extremely difficult
> thing to do because the CORBA bindings for
> things like C try to emulate OOP.
I disagree. Once you understand the C bindings,
they are just as easy as the C++ bindings.
> C++ itself is a fine language. It's been proven
> that above about 50k lines of code, C++ is far
> more efficient to work in than C and simply
> easier to understand.
It's been proven that 9 out of 10 statistics are
drawn out of thin air and are worth the paper they
are printed on. NT is written in C++, Linux is
written in C. I'll leave it to the reader to
decide how valid this "proof" is.
Re:C Bindings are archaic and byzantine! (Score:1)
such great free ORBs? ORBit supports C, and even
among C++ ORBs, TAO is probably the best ORB
out there, and it's free, too.
CORBA vendors are about as important as compiler
vendors these days.
CORBA vs. simpler things (Score:1)
The whole CORBA thing feels too complex for the simple tasks its trying to accomplished.
Just the fact that the book reviewed here is 1100 pages, tells me that something is not right. After all Knuth's "Fundental Algorithms" is only about 600 pages. And the content of Knuth's book is much deeper. :-)
Re:CORBA vs. simpler things - here's one reason (Score:1)
I don't know. The Web seems to work fine with HTML and http. If CORBA made such a tremendous difference why are there no CORBA servers on the Internet?
Re:...the Hell? (Score:1)
- Write and exchange general-purpose documents in IDL format
- Implement a desktop environment using XML and HTTP
I would not want to think about the first, but the second is a quite interesting proposition. If every object on your desktop has a URL then maybe you could get to your desktop from any machine on the internet.
Anyway, have you heard of WIDL? [w3.org] Take a look...Keep in mind that nearly every machine connected to the Internet has a web server.
Re:CORBA vs. simpler things - here's one reason (Score:1)
OK. I stand corrected...(but can I write code that runs on my computer that calls the CORBA services on CNN.com?)
Re:...the Hell? (Score:1)
Would it be useful for broad in-process use? (no)
Explicit is not always bad. Especially when you have to debug. :-)
For the second point, you are saying that for communication within a single address space http/XML is overkill. Right?
But isn't CORBA also? Even if the remote call gets "reduced" to standard call for performance reasons, it's still seems like a lot tedious work for the programmer.
And, I suppose my challenge still stands: could you implement something like Berlin, completely replacing CORBA and C++ with WIDL(XML)/HTTP and your language of choice?
Too bad I already made plans for this weekend... ;-)
In the future there will be more networked devices, most of which will talk http, so the idea of a UI based on http/XML is not so far fetched. I'll probably look different than today's desktops and I have no idea what it might be like...
Re:Huh? (Score:2)
When you pass a message to a program it can do any complex task you want. Only the app code will be more explicit (i.e. you will see that you are doing a network operation, rather than pretend that it's a function call).
A Web server is a simpler thing that exposes an interface to the network (http/XML) and various programs can communicate with it using messages that are readable by humans (to an extend).
Why not imbed an http interface into an app and use it along with XML for message formatting for communications.
Just the fact that you need IDL is wrong. IDL is completely backwards. You describe your interface in IDL, then compile it to generate code that describes the interface in your favorite language - the same information in two places. Shouldn't the interface be generated from your sources so that it exists in just one place?
What exactly do you use CORBA for in Berlin? D-n-D?
I second the 9/10 rating (Score:1)
CORBA, and how to work with it in a real-world
environment.
There are easily a dozen crappy books out there
that give you the worthless "manager-level"
overview of CORBA technologies, but I have yet to
see one that provides the important details you
need to actually get a CORBA client and server to
get together and do something useful.
If you want to program CORBA, buy this book!
...the Hell? (Score:1)
> interchange format, but lets face it, IDL's days
> are numbered given the amount of work going into
> XML.
... XML is an interchange format, IDL is an interface definition format. Two entirely different problem domains... where are you getting these strange ideas from? CORBA/IIOP, for which IDL is generally used for defining object interfaces, is not there to replace XML/HTTP, it's there to transparently glue applications together out of objects scattered across a (potentially) heterogeneous LAN or (less frequently) WAN.
That's quite different from the enforced (and explicit) client/server split enforced by XML/HTTP "applications" (if you can call them that). Which is not to say that XML/HTTP is going anywhere either; it's very very good for document interchange... just, I don't see how it's really any use for implementation-independent distributed execution, which is what CORBA/IIOP addresses...
Now, as for IDL, you can probably define an XML DTD for interface definitions, but it'd be almost by necessity be trivially transformable into IDL anyway, and quite useless for document exchange.
My challenge to you:
- Write and exchange general-purpose documents in IDL format
- Implement a desktop environment using XML and HTTP
When you have done these things (IF you can find a way to do these things), you will understand what each of these standards are meant to do, and what they are not meant to do.
---
Uh, they're not in competition... (Score:1)
---
Re:...the Hell? (Score:1)
> the second is a quite interesting proposition.
> If every object on your desktop has a URL then
> maybe you could get to your desktop from any
> machine on the internet.
URLs don't imply either XML/HTML or HTTP, though.
Nor do I think you could do a particularly useful desktop via XML/HTML alone without a supporting technology such as CORBA or COM getting involved somewhere.
> Anyway, have you heard of WIDL? Take a
> look...Keep in mind that nearly every machine
> connected to the Internet has a web server.
Looks interesting. And useful. However, it also enforces an explicit client/server model. You get RMI, but the "remote" is always very explicit.
Would it be useful for broad in-process use? (no)
Again, I don't see it as competing with CORBA; the two just aren't quite in the same problem space, although there is obviously some overlap. (where the overlap occurs, for many applications I probably would choose WIDL)
And, I suppose my challenge still stands: could you implement something like Berlin, completely replacing CORBA and C++ with WIDL(XML)/HTTP and your language of choice?
If so, would it be practical?
---
Re:Huh? (Score:1)
When you pass a message to a program it can do any complex task you want. Only the app code will be more explicit (i.e. you will see that you are doing a network operation, rather than pretend that it's a function call).
Indeed. Except that something like WIDL _forces_ you to draw the in-process/out-of-process lines at design/compile time, without giving you flexibility to redraw them later. I think.
A Web server is a simpler thing that exposes an interface to the network (http/XML) and various programs can communicate with it using messages that are readable by humans (to an extend).
That is very true. The value of human-readable (text) protocols are often highly underestimated.
Why not imbed an http interface into an app and use it along with XML for message formatting for communications.
You're talking about replacing IIOP with XML over HTTP... depending on what you're doing, that's a massive amount of overhead compared to the same thing done with IIOP. Absolutely incredibly massive. (for some things, like I think the intended applications of WIDL, the RMI calls aren't going to be that frequent, so you can afford it)
Just the fact that you need IDL is wrong. IDL is completely backwards. You describe your interface in IDL, then compile it to generate code that describes the interface in your favorite language - the same information in two places.
Mmm... yes and no; what it actually generates is a partial implementation of that interface. That being said, IDL's way of doing things still does strike me as kind of funky.
Shouldn't the interface be generated from your sources so that it exists in just one place?
I could provide an analogy, like "Shouldn't the object code be generated from your sources so that [your code] exists in one place? [As opposed to generating assembly and then assembling that to the object code.]". I think that's mainly a property of the way most build environments and compiler frontends are set up. If the compiler frontend would take IDL directly, that step would be hidden too.
I'll have to think about this some more; there is an additional component of having the interface and implementation split into separate source files. (but, is that a bad thing?)
What exactly do you use CORBA for in Berlin? D-n-D?
It's pretty pervasive, actually. Used for quite literally everything. Everything. Have a look at the design documents; I think they do a better job than I can at explaining it.
---
Re:...the Hell? (Score:1)
---
Huh? (Score:2)
Is there any good reason to use CORBA instead of simpler things, like http protocol and (let's say) XML?
XML is a static data format (yes, XSL adds some rather interesting "intelligent" transformation capabilities, but even so). Similarly, HTTP is a (relatively) simple (mostly) unidirectional data transfer protocol. I really don't understand how either can be compared to a distributed object model. Their uses, capabilities and so forth are entirely different.
The whole CORBA thing feels too complex for the simple tasks its trying to acomplished.
What simple tasks? CORBA is not primarily a standard for document interchange, it's a standard for allowing distributed objects to communicate to implement arbitrary functionalities (which may or may not have anything to do with documents, as such). Although, I wouldn't be very inclined to use it for most web stuff, if that's what you mean.
In any case, the uses to which CORBA is most successfuly put are certainly not simple -- take the Berlin project, for example. I really don't see how XML and HTTP would be suitable for implementing a desktop environment.
---
Re:C++ (Score:1)
Re:C++ (Score:1)
There are several reasons why C++ is a bad language. People not understanding it is one of them, oddly enough. When a language becomes complex enough that someone who has read the standard reference work has trouble reading other people's well written code, you know you have a bad language. Its that simple.
Other reasons why C++ is bad: The handling of templates is just plain wrong. Do proper generic types or do nothing. Operator overloading makes code hard to read, especially when the set of operators is fixed (as in C++). There are legal constructs whose behaviour is undefined. There is no real support for garbage collection, whatever Stroustrup may claim. The standard libraries are template obsessed and hopelessly incomplete. It is pass by value, which is inappropriate for an OO language. Compilers differ massively in even fairly simple things. Multiple inheritance is usually unnecessary and the C++ form of it is overcomplicated
To pick you up on two specifics: It is never sufficient to say "you just don't understand it". If it is that hard to understand, it sucks.
Similarly, language features that are brain-damaged cannot be compensated for just by not using them. Other people, including your colleagues, will use them, and you will have to deal with their code.
Re:C++ (Score:1)
Firstly, I should stress that I'm a Java programmer, and while I have some affection for some "completely unsupported languages" I'd use C++ ahead of them for pragmatic reasons. You replied to my post by repeating exactly the points I thought I'd just dealt with. So I'll repeat myself as well.
1. Featuritis. C++'s feature-overload is not bad because it bloats the code - they managed to avoid that. Its bad because it makes the code hard to read and the language complicated. C++ bares no relation to any other object orriented language, least of all Java, whose design is quite sane, at any level other than syntax. The designers have headed off in a distinctly odd direction, whose value is very dubious.
You can keep saying "you don't understand it, you're just STUPID" as much as you like, but it won't make C++ better. The point is that I have to understand the complexities of every single spaced-out language feature, from templates to pass by value to inadequate operator overloading and their wacky implementations in every single compiler before I can be sure of understanding someone else's code. None of that contributes one bit to the work of programming. Its just cruft. It makes it hard to reuse code and hard to organise project teams.
C++'s design violates the "worse is better" principle. They just keep throwing more stuff in, in the hope of making it into a usable language, and it just never works, because the problem is it was hopelessly ill-conceived to start with. Languages are like applications - they should do something and do it well. C++ tries to be all things to all people and does none of them well. "There is more than one way to do it" is all well and good for Perl, but for systems languages it doesn't cut the mustard.
2. Missing features C++ claims to be an object orriented language for large-scale projects. Compared with C, I won't deny that, but compared with anything else it is laughable. Its not viable to rely on programmer competence or diligence or the SW engineering process to prevent memory leaks, pointer errors, fencepost errors or any of the other problems that dog C++ developers. The only way to fix these things is to build features into the language that make them impossible.
Re:C++ (Score:1)
I guess all the C++ code I wrote in the last 10 years is not viable then. I will instruct the financial companies and telcos who use it daily to throw it all out immediately.
Maybe 'not viable' was a bit extreme (not to mention vague), but you cannot suggest (as a previous poster did) that C++ plus a bit of discipline and a copy of purify is as good as a language which is inherently proof against many of the errors C++ programmers produce so regularly. Did I say it was impossible to write decent C++ ? I've used purify, and I've written plenty of C++. There are other things you can do to make it a saner development language as well as using Purify. The point is that you shoudln't have to. If the language had been designed better, none of this cruft would be necessary. I won't suggest you made the wrong language choice (not 10 years ago at least) or that your employers should chuck the code out, but its possible they could have saved a lot of time and money.
Face it - some people know how to design code and some people (regardless of language) will never know.
That will always be true, with the caveat that most of the issues WRT to C++ primarily concern implementation and reuse, although they do affect design. Tracking garbage, for instance, is nothing to with OO design, but warps the construction of many C++ programs beyond all recognition.
The industry as a whole has to accomodate lower quality programmers though. Not everyone can afford to hire geniuses and recognising them is notoriously difficult. C++ hinders the necessary compromise by making it possible for those who are going to write bad code to do that much more damage.
Whether competence is measured by ability to wrestle C++ to the ground is another matter entirely.
Re: Why I don't like C++ (Score:1)
decide not to use the entire language (eg. leave out the operator overloading), but that is likely to give longer and less efficient solutions, which defies the point of using C++ in the first place: having very fast, compiled OOP programs.
* The language lacks features that make it difficult to reuse code: for example
- garbage collection
- interfaces/signatures
- standardised libraries--almost every C++ program I've seen comes with its own list, array
and string classes.
* Any reasonably big project is going to have
extra infrastructure (an embedded language, a component/module architecture, etc.). Using C++ pushes this point somewhat into the future. But when this point is reached, you have more code to convert, and you also have to deal with the messy semantics of C++ which will be in your class structure.
Why CORBA and XML are the same. (Score:1)
As was pointed out by many other people, in one sense, comparisons between XML and CORBA are somewhat silly since they address two very different problem domains.
In another sense, comparing them reveals a fairly deep insight into what's really going on with these two technologies. Both CORBA and XML, are, in a broad sense, attempts to address the problem of messaging (getting two different programs that don't have anything to do with one another to communicate (pass data back and forth when they don't share any address space) properly).
In my opinion, there are two axis on which one can judge a messaging technology. One is efficiency, and the other is coupling.
For example, one common method that people used to use to write programs that had to talk to one another was to directly dump program data memory (write structs) into whatever data stream you were using to communicate with. This is off the scale on the coupling axis, but has the advantage of being generally very efficient. Because the coupling between programs that communicate this way is so high (it's so high that two programs sharing a common code base, but compiled for different architectures may not be able to communicate) this approach is usually dismissed.
XML is very, very low on the coupling scale. There's even a standard describing high semantic content meta data that's used to describe the messages being exchanged. On the other hand, it's also very low on the efficiency scale. You have to translate all of your data to a structured framework of textual tags with largely textual content. This makes XML suitable only for applications in which low coupling is at a premium. Long term archival storage, or transmitting data across the net between diverse, unrelated parties are two examples of such applications.
CORBA has higher coupling. The two programs have to agree on the function call interfaces that will be used to communicate. It's also more efficient. The data is translated to a binary form that's negotiated between the parties so that there's a minimum CPU time cost in the translation. So CORBA occupies sort of a middle of the road strategy. It's perfect for things like GNOME, where you can count on all the applications using the same toolkit, but not necessarily running on the same architecture.
I think CORBA's coupling is too high though. Also, it's reliance on a function call style model encourages the development of messaging protocols that are highly inefficient due to excessive round trip messages. I'm currently working on a somewhat different architecture that concentrates heavily on having a machine independent way of describing the content of an efficiently encoded message which I will call CDL (Common Data Language). The semantic coupling implied by CORBA's function call model would be absent because the architecture wouldn't describe the messages in terms of function calls, but merely in terms of the data to be exchanged. This pushes it much closer to XML on the coupling axis.
Anway, this is a topic with a lot of subtleties, and one that I'm very interested in. If any of you want to talk about messaging and messaging architectures, I'd welcome the exchange of ideas.
If anybody wants to help me build this thing, I'd also very much appreciate it. Be warned that it's written in C++, and I'm NOT going to do it in C. C's expressive power has been long eclipsed by C++, and it's high time that people stopped complaining about how complicated it is and actually learned something new. The Open Source community's penchant for simplicity is laudable, but C++'s power is well worth the complexity.
A more basic text? (Score:1)
The review says its an excellent book (as did Amazon) but mentions that a more basic introduction could be good - does anyone have a real recomendation for a companion text to this for the CORBA virgin.
I want the depth this book promises but I've yet to see a good basic introductory text go to waste.
Tom
Re:duh (Score:1)
Besides I have always got on better with advanced text books than basic ones, give me a language reference over a "learn xxx in 21 days" any day.
In my experiance, advanced text books tend to mean for people who have a solid programming background. Just right now I'm under a lot of time pressure.
Tom
Why CORBA? (Score:1)
Re:How does it compare with the "Martian" book? (Score:1)
The Martian book is littered with errors and
inconsitencies and the code is all but useless as
anything but a basic reference. Though, like the "Martian" book, it covers POA, which is nice since
pretty much none of the other books do.
"Advanced..." is really good if you're looking for
in-depth info on CORBA and the COS specifications.
-tim
Implementing an ORB (Score:1)
Is this book something for me?
Does anyone have any links och suggestions for books?
Thanks
Stroustrup says that C++ bindings are primitive. (Score:1)
What do you think?
Re:Why CORBA? (Score:1)
Re:Stroustrup says that C++ bindings are primitive (Score:1)
However, a mapping as you describe would be perfect. Though I won't be holding my breath. Till then, the wisest thing to do is keeping your book as the CORBA-with-C++ guide.
Re:C++ (Score:1)
it got 9 and not 10 points.
It also shows how much C++ complicates things
because of the missing garbage collector and
how complicated it is to use dynamic
invocation with this static language.
I ordered this book through fatbrain.com (Score:1)
I've got a feeling someone could learn CORBA from this book, but please don't hold me to that.
It's certainly worth the money AND the size of the book (good thing slashdot's reviewer isn't a drummer -- he'd get tired of carrying around his drum kit all the time).
Apples and oranges (Score:1)
XML is a good way for applications to exchange data, but it is not a great way for applications to call other application's code in a language independent way. Aside from all the network stuff (which many see as the raison d'etre of CORBA), CORBA and COM are good at providing a language independent interface to shared libraries and applications. That's why Gnome and KDE are using CORBA to provide OLE style linking and embedding, and sharing of common modules. XML doesn't even begin to address this sort of thing.
--------------------------------------
Re: Why I don't like C++ (Score:1)
1. C++ does not include garbage collection for efficiency reasons. However, if you want it, libraries supporting garbage collection are available (Great Circle, for example).
2. A pure virtual class is an interface.
3. What where you smoking when you said that C++ has no standardized libraries!!??? Have you used C++ in the last few years? Check out something called "The Standard C++ Library," part of the ISO C++ standard, and included with every modern C++ compiler. It has standard classes for strings, lists, vectors, i/o, etc.
---------------------------------------------
Sad but true (Score:1)
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
Honest book (Score:1)
It is a great book!
Re:CORBA vs. simpler things - here's one reason (Score:1)
Re:Why CORBA's C++ mapping is crude (Score:1)
Keep in mind that the CORBA types and standard C++ types are performing different work behind the scenes. They each meet a different set of requirements. Standard C++ types are not proxies and perform no reference counting duties like their CORBA counterparts.
Abstracting away reference counting would limit the utility of distributed objects.
Re:Why CORBA's C++ mapping is crude (Score:1)
- STL was not completely standardized
- STL was not available for all platforms
- ANSI C++ compilers were not available on all platforms
- C++ Exceptions were not supported by all C++ compilers
The above reasons more than anything else are why the C++ mapping is so clunky. Now that it's being used commercially, the probability that it'll be changed to "clean" it up is just about nil.
There is, however, an effort happening to come up with another C++ mapping which uses STL containers, strings, etc.