On Tue, Sep 25, 2001 at 02:30:14PM -0700, Mike Bresnahan wrote:
> > > Are they all thread safe?
> >
> > What? _Any_ code can be not thread safe, even a java package you get
> > from somewhere...
>
> Yes, but I've found that a given C++ library is much less likely to be
> thread safe than a given Java library.
Then complain to the library vendor. Or fix it.
And b) Java libraries today are implemented by the same people that
yesterday coded that C++ library. Don't expect miracles.
> Many C++ developers don't want to
> take the performance hit of making everything thread safe. Plus, you often
> have to turn on/off compiler flags to produce thread safe code. For
> example, HP's cfront compiler's exception implementation is not compatible
> with threads. Plus there's no de-facto standard C++ threads implementation.
> There are 4 different implementations that I can think of off the top of my
> head: fake POSIX, real POSIX, Win32, Sun LWP. This leads to mucho
> compatibility problems. Java has simplified this mess by providing threads
> as part of the language, albeit with some costs.
> >
> > Namespaces is a very _STANDARD_ thing. Not Microsoft, not extension.
>
> Yes, but not all C++ compilers implement namespaces
Again, complain to the vendor or switch parforms.
> and hardly anyone uses
> them on the compilers that do. For example, Microsoft still uses name
> prefixing scheme (IDirectX8This, IDirectX8That) when its being nice and the
> rest of the time it polutes the global namespace with all sorts of goop
> (TRUE, FALSE, DWORD, LPDWORD, WORD, ...).
Please do not give/take Microsoft as a source of good code quality and standards.
> > If not compiled with the same compiler (/version) no, for obvious reasons:
> > because vendors do not want to agree on a common ABI, so they can lock
> > you in their "standard".
>
> Vendor lock is something Java hopes to fix.
Hmm.... Read your sentence aloud until the problem is obvious. If not, scroll..
Cheers,
florin
* The solution is
##### # # # #
# # # # ## #
# # # # # #
##### # # # # #
# # # # # #
# # # # # ##
##### ##### # #
--
"If it's not broken, let's fix it till it is."
41A9 2BDE 8E11 F1C5 87A6 03EE 34B3 E075 3B90 DFE4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
Url : http://shadowknight.real-time.com/pipermail/tclug-list/attachments/20010925/a3301ad0/attachment.pgp