Re: [boost] Re: Re: Re: char[] support in Boost.Range
Anyway, that wasn't my point. My point was that it is really easy to get the array behavior if you want it.
The only part missing is direct support in the range library to trigger array behavior for range arguments, say as_array().
It seems strange to need to force the more basic behaviour of an unconstrainted array of chars with zero cost for establishing the bounds, and default to higher level behaviour implying a delimiter and a linear cost to calculate the bounds. Some of this depends on what you perceive as the common case, but the differing behaviour between char[N] and MyType[N] presents a lack of uniformity that could hurt generic code developers and confuse users. Dan ___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
"dan marsden" <danmarsden@yahoo.co.uk> wrote in message news:20050517202600.13327.qmail@web25106.mail.ukl.yahoo.com... |> Anyway, that wasn't my point. My point was that | > it is really easy to get the array behavior if you | > want it. | > | > The only part missing is direct support in the range | > library | > to trigger array behavior for range arguments, say | > as_array(). | | It seems strange to need to force the more basic | behaviour of an unconstrainted array of chars with | zero cost for establishing the bounds, and default to | higher level behaviour implying a delimiter and a | linear cost to calculate the bounds. | | Some of this depends on what you perceive as the | common case, but the differing behaviour between | char[N] and MyType[N] presents a lack of uniformity | that could hurt generic code developers and confuse | users. I'm not much interested in using naked arrays my-self, with the exception of literals. Would it be ok with people if const char[N] was the only special case? (Afterall, that type is not much use as a buffer) -Thorsten
"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:
Would it be ok with people if const char[N] was the only special case?
No.
(Afterall, that type is not much use as a buffer)
char buffer1[1000]; char buffer2[1000]; template <class Range1, class Range2> void copy(Range1 const& src, Range2& dst) { // ... range operations here // note that if Range1 was char[N] it will be treated as a string } // ... copy(buffer1, buffer2); -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:ufywlzgsa.fsf@boost-consulting.com... | "Thorsten Ottosen" <nesotto@cs.auc.dk> writes: | | > Would it be ok with people if const char[N] was the only | > special case? | | No. | | > (Afterall, that type is not much use as a buffer) | | char buffer1[1000]; | char buffer2[1000]; boost::array<char,1000> buffer1; boost::array<char,1000> buffer2; ? | template <class Range1, class Range2> | void copy(Range1 const& src, Range2& dst) | { | // ... range operations here | // note that if Range1 was char[N] it will be treated as a string anyway, it seems I'm the only person with my view so I guess we should let experience/authority win for once :-) -Thorsten
"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:ufywlzgsa.fsf@boost-consulting.com... | "Thorsten Ottosen" <nesotto@cs.auc.dk> writes: | | > Would it be ok with people if const char[N] was the only | > special case? | | No. | | > (Afterall, that type is not much use as a buffer) | | char buffer1[1000]; | char buffer2[1000];
boost::array<char,1000> buffer1; boost::array<char,1000> buffer2;
?
| template <class Range1, class Range2> | void copy(Range1 const& src, Range2& dst) | { | // ... range operations here | // note that if Range1 was char[N] it will be treated as a string
anyway, it seems I'm the only person with my view so I guess we should let experience/authority win for once :-)
Thank you. For what it's worth, that my other disagreement with you revolves around the same principle: that it's important to be able to treat types uniformly. Cheers, -- Dave Abrahams Boost Consulting www.boost-consulting.com
On May 17, 2005, at 3:39 PM, Thorsten Ottosen wrote:
"dan marsden" <danmarsden@yahoo.co.uk> wrote in message news:20050517202600.13327.qmail@web25106.mail.ukl.yahoo.com... | It seems strange to need to force the more basic | behaviour of an unconstrainted array of chars with | zero cost for establishing the bounds, and default to | higher level behaviour implying a delimiter and a | linear cost to calculate the bounds. | | Some of this depends on what you perceive as the | common case, but the differing behaviour between | char[N] and MyType[N] presents a lack of uniformity | that could hurt generic code developers and confuse | users.
I'm not much interested in using naked arrays my-self, with the exception of literals.
But many other users are. You're writing the library for them, too, aren't you?
Would it be ok with people if const char[N] was the only special case?
That's even worse :) Special cases cause problems in generic code. It doesn't mean that special cases can't ever be used, but that they should be considered very, very carefully. In this particular context, I don't think that the special case is a good idea, for two reasons: (1) Users have expressed a need for the normal behavior. (2) Users have expressed a need to do what the special case does, but in instances where the special case wouldn't be triggered. So the special case isn't always useful and doesn't cover all of the cases it needs to. It sounds like a separate facility is in order. Doug
participants (1)
-
dan marsden -
David Abrahams -
Doug Gregor -
Thorsten Ottosen