
On Mon, May 16, 2005 at 12:32:56PM -0700, Eric Niebler wrote:
Pavol Droba wrote:
On Sun, May 15, 2005 at 08:17:15PM -0400, David Abrahams wrote:
"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:
| I'd like to leave it for the discussion. Right now it seems, that | most of the people that entered discussion prefer c-array view. | I would prefer c-string view, but I'm probably biased by the fact | that I'm the author of StringAlgo library.
I prefer the string view too.
I just have one thing to say: vector<bool>.
Pardon me, but somehow I cannot figure out the point here. Can you please explain the me the connection to vector<bool>
vector<bool> creates all kinds of problems because generic code can't make assumptions about the behavior of vector<T>. vector<bool> is widely regarded as a Bad Move. Dave is saying that treating char[] different than, say, int[] is inviting the same sorts of problems. It will make it difficult to deal with T[] in generic code.
I agree with Dave.
I see now what do you mean. I understand this problem and therefor I have suggested a solution that can work regardless to decision taken here. But allow me to mention another similarity. There is well knows 'C' idiom, that char[] is generaly char*. For char* we can only provide c-string handling. Therefor it brings also a confusion if char[] will be threated differently. Yet this is probably no as strong as similarity between generic T[] types. * * * * * * * * * * * But I see, that this discussion is starting to circle around and it is time to stop it. There was no objection to the solution I have proposed, so I take it for granted, that it is acceptable. For the default behaviour, we can favor either syntactic (T[]) or semantic (char*) similarity. Because syntactic similarity is usualy stronger, let's stick with this one. In addition I would suggest to remove direct support for pointer types like char* from the range library and provide it only via as_string() construct to definitely remove any kind of confusion. If there are any complaints/suggestion/comments do not hessitate to bring them on. Best Regards, Pavol.