Re: The plus plus

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Les Mikesell wrote:
On Sat, 2006-11-11 at 12:10, Andy Green wrote:

I've just always thought of data and code as very different things
and both likely to contain their own sort of flaws. If you have
a bug in a function library you may be able to work around it.  How
do you deal with a flaw in a class where the only way to access
the data in an object is broken?

Well, in a FOSS library you just fix the problem in the library and that's the end of it. In the extreme case you have to make some kind of ugly workaround, the object is in the end a struct in memory that has a pointer to it, you can get what you need at one offset or another from the object pointer.

Can you provide a date for the time people started making this
claim and also the time that you considered the STL impementations

Not sure which claim you mean; on the first it has always been the case that having the source empowers you to fix things directly. Interestingly enough even MSFT gave the sources for MFC back in the 1990s, it was not liberally licensed though. But it did give this assurance you could fix yourself out of their trouble if you had to, and also enabled debgging into their libs. Sort of early acceptance by MSFT of the upside of giving sources.

On the second again objects have always been fancy structs in memory, the compiler does most of the typing grunt work. If you have a pointer to the start of the object and some dirty crisis workaround is needed you can get an ugly, norportable pointer to the member you need, private or not, with an offset to the object base pointer. But such nastiness won't be needed if you have the sources for the lib which would be the case for stlport for example.

for GNU and MS to be more reliable than something you would
code by hand in C?  My opinion is probably outdated and based
on needing some old versions of stlport embedded in our CVS
repository for some historical reason or other.

I should think anyone implementing the STL felt that it was immediately as or "more reliable than something you would code by hand in C" with some justification, since they sat down and coded it by hand in C++.

Anyway it's the language features that I wanted to suggest give the payoff, what to pick out of the library is a whole other consideration. Basically if you find your C is full of structs, especially ones composed of other structs and pointers to allocated memory and functions, making the relatively small move to having the structs as classes and leveraging the language features there will probably make your code more readable, scalable, deterministic and reliable at little cost to source bloat (may even reduce it), code size or execution time.

-Andy

--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux