Re: Questions

[David Durham]

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