On approximately 5/14/2004 12:56 AM, came the following characters from
the keyboard of Johan Lindstrom:
At 06:53 2004-05-14, Glenn Linderman wrote:
has a special return value for that case. Win32::GUI's
GetOpenFileName wrapper doesn't really handle the special return
value, and even if it did, it is not the greatest idea to have the
user select his files twice, once causing overflow, and the second
time with a bigger buffer. It would be much better to have a bigger
buffer to start with.
In the spirit of Perl, can't we optimize for the common case, and make
the uncommon case possible?
I'd like to not have to say I don't want a tiny, possibly overflowing
buffer. I'd like to have the enhanced, larger buffer by default (say a
couple of K at least so it never becomes an issue). And if I really need
to go beyond even that, maybe it's time for a new parameter.
"a couple of K" would be 8 times the size of the current buffer. The
current buffer is allocated on the C runtime stack at 256 bytes, and
according to someone, allows "about 18 files" to be selected... so a
couple of K would allow "about 72 files" to be selected. That sounds
like plenty for quite a few cases, but I can imagine very practical
cases where I personally, would like to allow selection of several
hundred files.
So I guess GetOpenFileName users have presently been living with the 256
byte buffer. I haven't heard major complaints... of course most of them
didn't know -multisel => 1 was even an available option, so maybe that
is why.
OK, having said all that, is the point of your post that it would be
nice to avoid the "malloc/free" calls in many cases? (But remember,
this is a user interface function that will soon be waiting for a human
response measured in seconds, whereas the malloc/free are measured in
microseconds.)
Or is the point of your post, that the default allocated buffer should
not be 256 (as it was) but should grow to 2K with this code change? Or
should grow to 2K if -multisel is non-zero (256 being plenty big enough
if -multisel is zero)?
Or is the point of your post, that you don't think the value of
-multisel should be permitted to be different than 0 or 1, that rather
there should be a -resultsbuffersize parameter?
Or have I missed the point of your post?
I'll be glad to tweak my patch to deal with what people believe to be
the common case.
--
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.
