David Sugar wrote:
I tended to keep away from STL and templates in GNU Common C++
because many compilers tend to generate poor code for template
classes and often it swells the size of the resulting executable
unreasonably for the small footprint I wanted. However, it certainly
works well with STL and there are now GNU Common C++ template classes
as well.
Ok... Well, as for my apps, I chose to go with the STL for portability
reasons, the STL should theoretically behave the same across
compilers. Yet it probably remains to be seen. Also, none of my
templates were tree based, all list based, so any sorted inserts took
O(n) although the search time was of course log n. But, thank
goodness, it doesn't look as if CommonC++ is trying to do, much at
all, the same thing that the STL does. The STL, as somewhat awkward
the interface sometimes is, is quite elegant in some areas. I used to
dispise it, but after a few weeks of using it, it's okay... And I
can't say this for other compilers, but for gcc, templates do increase
the code size, but become blazingly fast when compiled with -O2. But,
even without optimizations turned on, I can accept why the template
code is bigger when compilerd, it reWROTE the code for you, for each
type you instantiated it for.
GNU Common C++ has something called a "RWLock" which I believe does
what your reader/writer class does. However, it requires pthread
support for shared locks, and this is not common. It would be useful
if RWLock could fall back to your proposed implimentation for
platforms and targets which do not support this, as currently it
falls back to a far less efficient standard Mutex now.
Oh, okay... I didn't see RWLock in the html docs.... In fact, I'm
surprised that I can't find a link to the html documentation from the
gnu.org website. Is that the official site for CommonC++? (BTW- I
also had a hard time finding where to subscribe to this mailing list
on gnu.org, there's no link on the www page). You say that the
implementation it falls back on is 'far less efficient'... Well, my
implementation never does a spin lock. I looked for the code to
RWLock in my 1.9.5 .tar.gz but could only find a little documentation
containing 'RWLock' no code to look at the implementation of
RWLock??? Is it in another tar ball?
I would find it very useful to have a Path class in GNU Common C++.
If it can provide realpath() validation as well, that would be ideal,
as then it can be used to check reach of filepaths in applications
that may wish to restrict file access to select portions of the
filesystem.
Yes... Well, this does sound useful. How should this be implemented?
I suppose just about every OS should provide some functions which have
these behaviors, but the names and specifics might be different. But
if there is no way of doing what say, realpath(), does on say, win32,
would we resort to implementing it ourself, or just complaining that
this functionality is unimplemented on this platform? Then I think,
except for efficiency, why not always use out own implementations of
these function if we're going to write them anyway...
Your template class sounds like it could be useful in the GNU Common
C++ template library.
Alright, I'll get it ready... I'm in the habit of prefixing all my
template classes with 'T'... Take it off or leave it? I like it
because it makes it stand out in a listing.
And how should I send this? just as an attachment or a patch? I've
never submitted a patch before, but I suppose there are plenty of
little how-tos on this.
-- Davy
David
David Durham wrote:
Hi, I just found this library today in search of something like
it and was pleasently surprised. Because I want to release some
source code soon, I've recently been trying to move away from my
little libraries that I've used for years to more standard stuff.
I've converted one of my projects to the STL now that it is defined
and comes sufficiently well implemented on gcc and other
compilers. I was wondering if CommonC++ uses the STL whereever
possible. I don't guess much of it requires a whole lot of
container-like use, perhaps the persistance stuff. I could find
any classes that dealt with time... maybe I missed it... I saw
dates, but no date/time class. I have one if necessary.
Also, I have a class that is a readers/writers mutex which is
simply wrapped around 2 other mutexes, so it would be simple to
merge into CommonC++. Basically, it allows 1 write lock but
multiple simultaneous read locks. Is there another way of doing
that already in CommonC++?
I also have an idea for a Path class which would have
functionality that, constructed from a string, would have methods of
getting the directory or the filename from it. The implementation
isn't as trivial as finding the last '/', because you have to
correctly handle '.' as the entire path. glibc does have pathname
and dirname, but they comform to the SUSv2 standard, so are not
guarenteed to be on all systems. I suppose you could imagine other
things you could use a Path class for, perhaps breaking the path up
into all the directories components, making sure paths exist,
touching files, etc... If this sounds like a worthy class to
implement for CommonC++, I'd be glad to write it. Currently, I have
an .h file which has dirname, basename and touch functions, but
again, I'm trying to move as much as possible away from these little
implementations which aren't even autoconfiscated.
Lastly, I have a couple of template classes which are used to
create temporary buffers of memory or temporary arrays of object
which get deallocted when the variable goes out of scope. I know
you'd think that auto_ptr in the STL can be used for this, but it
can only (as far as I can tell) be used for a single object, and not
an array of objects. Plus, my template class can auto cast to a
pointer of the type it is instantiated for, or a void * and can be
subscripted all of which auto_ptr doesn't do. -- Davy
_______________________________________________
Bug-commoncpp mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/bug-commoncpp
_______________________________________________
Bug-commoncpp mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/bug-commoncpp