On Wednesday 28 July 2010 08:04:10 Ross Finlayson wrote:
> Specifically, looking at your suggestions:
> - C++ standard library string or custom string class (which one if any)
> - custom command line options parser class
No, ...
because they don't fix bugs, nor do they improve (or even really
change) the code's API
In fact use of std::string instead of char* is both change and improvement of
API. User of library would not need to worry about delete [].
In the future I'll definitely consider switching to using
"std::string" if/when I become sure that it is available - and
efficient - for *all* potential users of our code. Right now,
though, I'm not sure of this.
> Ditto for 'standard' C++ libraries, which might also make
applications too large for some embedded systems.
Standard C++ libraries could sometimes become huge, but there are
techniques to keep final binaries small.
That's too vague. I really want to make sure that this code remains
useful, and usable, for people who are developing small embedded
systems.
But my basic point remains: If people are using the code properly,
then the kinds of changes that you are proposing are just not
important, because they add little new functionality. So please stop
harping on about this.
The more of my time that is wasted dealing with unimportant questions
like this is time that I don't get to spend on adding important new
functionality that will really help people, like, for example:
1/ A new simple RTSP client demo application ("testRTSPClient") that
will give developers a much clearer picture of how to use
"RTSPClient" (as opposed to the code for the "openRTSP" application,
which is complex and has lots of 'bells and whistles' that are
unneeded by most developers).
2/ New test programs (and 'framer' classes) for H.264 video (because
many people seem to be having lots of trouble sending (especially)
and receiving H.264 video.
Both of these things (and a lot more - e.g., stuff that will
eventually lead to support for IPv6) is all on the drawing board, but
keeps getting delayed by distractions...
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
