John Peterson wrote: > On Thu, Nov 6, 2008 at 3:14 PM, Roy Stogner <[EMAIL PROTECTED]> wrote: >> John Peterson wrote: >> >>> Non-nice methods could be called receive_n or send_receive_n. >> Better than "into_pre_sized_vector", but sounds too cryptic. > > OK, I am all for self-documenting code, but you did also say "terse". > The _n suffix has some precedent in the STL (search_n, copy_n, fill_n) > as well.
Ah, I've never used those before. They're not exactly analogous, but close enough to be meaningful. I take back "too cryptic". >> How about fast_send/fast_receive? That doesn't really describe the meaning >> of the distinction, but it certainly makes clear the reason for it. > > Nah, there are already too many different versions of MPI_Send like > ready send and synchronous send that sound like they could mean > "fast". I don't think fast_send distinguishes itself enough from > those. Okay. >> presized_send - take out "into" and "vector" and my initial ridiculous >> suggestion sounds... less ridiculous, at least. > > This, or preallocated_send would be my preference. Behind send_n, of course > :) I'd prefer presized_send over preallocated_send since it would be clearer that the receiving vector needs to have enough space resized and not just reserved. Hmm... or do we want it to need that? We could just require that capacity() was sufficient, and then we'd resize() to the eventual vector size we receive. Does anyone know which STL vector operations exist reduce capacity()? As far as I know swap() and reserve() are the only ways to do so, but I'd hate to find out that some resize() implementation also "helpfully" reduced capacity for you when we don't want it to. --- Roy ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
