Jeff King <peff@xxxxxxxx> writes: >> The string will always be "dist=" followed by decimal representation of >> a count that fits in "int" anyway, so I actually think use of strbuf is way >> overkill (and formatting it twice also is); the patch as posted should be >> just fine. > > I think you are right, and the patch is the right direction (assuming we > want to do this; I question whether there are enough elements in the > list for us to care about the size, and if there are, we are probably > better off storing the int and formatting the strings on the fly). ;-) > It would be nice if there was some way to abstract the idea of > formatting a buffer directly into a flex-array. That would involve the > double-format you mention, but we could use it in lots of places to make > the code nicer.... > ... > struct name_decoration *r = fmt_flex_array(sizeof(*r), > offsetof(*r, name), > "dist=%d", x); > > which is a little less nice. You could make it nicer with a macro, but > we don't assume variadic macros. <sigh> At first I thought "Yuck. A helper only to format into the flex member that holds a string?", and I tried to change my mind, but I couldn't quite convince myself. At least not yet. Among the flex arrays we use, some are arrays of bools, some others are arrays of object names, and there are many arrays of even more esoteric types. Only a small number of them are "We want a struct with a constant string, and we do not want to do two allocations and to pay an extra dereference cost by using 'const char *'". For them, by the time we allocate a struct, by definition we should have sufficient information to compute how large to make that structure and a printf-format plus its args would be the preferred form of that "sufficient information", I would think. The name "fmt_flex_array()", which stresses too much on the "formatting" side without implying that it is the way to allocate the thing, may be horrible, and I agree with you that without variadic macros the end result may not read very well. Unless we have great many number of places we can use the helper to make the code to create these objects look nicer, I am afraid that the pros-and-cons may not be very favourable. Thanks for an interesting tangent. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html