From -8880950074452523591 X-Google-Language: ENGLISH,ASCII X-Google-Thread: fc772,cda54862ecb4a41f X-Google-Attributes: gidfc772,public X-Google-Thread: f78e5,cda54862ecb4a41f X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2001-08-31 11:35:08 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!denver-snf1.gtei.net!news.gtei.net!namche.sun.com!news2me.EBay.Sun.COM!engnews1.eng.sun.com!taumet!clamage From: kanze@gabi-soft.de (James Kanze) Newsgroups: comp.std.c++,comp.lang.c++.moderated Subject: Re: storage order of inherited classes Date: 31 Aug 2001 18:19:43 GMT Organization: http://groups.google.com/ Lines: 69 Approved: stephen.clamage@sun.com (comp.std.c++) Message-ID: References: NNTP-Posting-Host: taumet.eng.sun.com X-NNTP-Posting-Host: netlab.cs.rpi.edu X-Original-Date: 31 Aug 2001 04:21:46 -0700 X-Submission-Address: c++-submit@netlab.cs.rpi.edu X-Auth: PGPMoose V1.1 PGP comp.lang.c++.moderated iQBVAwUAO4/TRUHMCo9UcraBAQEsFwH+PLwbVAxjXdA4AJV7+i6WF1QxAKgXx0dB ETFogW5+m3EfeIwMq7YROIWD3C7+hbbW6Hjun8RX/72x3Lrsh9tTAg== =7o1f X-Approved-For-Group: hsutter@acm.org comp.lang.c++.moderated Content-Length: 3122 X-Status: $$$$ X-UID: 0000000001 Originator: clamage@taumet Xref: archiver1.google.com comp.std.c++:7266 comp.lang.c++.moderated:25936 plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 999256906 11596 127.0.0.1 (31 Aug 2001 11:21:46 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 31 Aug 2001 11:21:46 GMT Content-Length: 2102 ReSent-Date: Fri, 31 Aug 2001 10:01:48 -0700 (PDT) ReSent-From: Steve Clamage ReSent-To: ReSent-Subject: Re: storage order of inherited classes ReSent-Message-ID: "Gaurav Sareen" wrote in message news:... > > > This IMO is one of the big reasons why java can be "safer" than > > > C++ is that the runtime layout of the classes is fixed. > > Just curious. I can see how this makes Java more portable than > > C++, at least for some definitions of portable, but how does is > > make the language "safer"? > In the sense that you cant look at a compiled class and make sure > its well formed. Can you. I don't think you can look at the layout of a class in either language. > I was talking in terms of the VM being able to do verification of > the byte code, which basically means that it can make sure that the > code is not ill formed, and wont cause some of the unsafe memory > corruption that can happen by executing native code. I agree some of > the java safety comes at the cost of (slow) runtime checks, and even > the above checking while loading may be slow but it sure is safer. This is a totally different issue. It has nothing to do with a fixed runtime layout; it has to do with the fact that a Java .class file typically contains a lot more information than a C++ object or library file. If you prefer, it isn't the runtime layout that is fixed, so much as the fact that the actual hardware level access is only generated at link time, after program verification. This is a two edged sword. It means that dynamically loaded libraries are safer in Java than in C++. But it also means that every class is a separate dynamically loaded library; you can't static link at all. And static linking is safer than any dynamic linking; there's just nothing that can go wrong with it at run-time. In practice, I don't normally use dynamically linked libraries at all in C++, except for a little GUI work. -- James Kanze mailto:kanze@gabi-soft.de Beratung in objektorientierer Datenverarbeitung -- -- Conseils en informatique orient�e objet Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany, T�l.: +49 (0)69 19 86 27 [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ] [ about comp.lang.c++.moderated. First time posters: do this! ] [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.research.att.com/~austern/csc/faq.html ] [ Note that the FAQ URL has changed! Please update your bookmarks. ]