TITLE: complaints using STL vector (Newsgroup: comp.lang.java.advocacy,comp.lang.c++, 24 Jan 99) FUNGUS: fungus > ...but because of "efficiency" the C++ <'s a fuggin' mess man! > It took me three hours with Bjarnes book to figure out how to put > something in a vector (hint: it's not in the chapter on vectors, that > just has page after page of technical detail telling you "efficient" > vectors can be, and why this is so.) What was the answer? > "push_back()". Yup, read it again: "push_back()". Nothing like having > logical names for things, right? "addElement()" would have been too > simple for a powerful language like C++. KOENIG: Andrew Koenig (ark@research.att.com) A list supports similar operations to a vector, but allows insertion and removal at both ends. So what would you propose to call the operation that adds an element to the front of a list if you use addElement to name the one that adds an element to the back? push_front, push_back, pop_front, and pop_back are entirely reasonable names. And if you had read the introductory chapters, particularly including chapter 3 (``A Tour of the Standard Library'') before jumping ahead to chapter 16, which describes the library containers in detail, you might have wasted less time before finding the statement on page 56 that ``push_back() can be used (reasonably efficiently) to add elements to the end of a vector as well as for a list.'' FUNGUS: > I just spent a day or so writing some code using vectors in C++ and > it's a complete mess. C++ vectors have zero actual functionality, > they're just a storage mechanism, nothing more. No searching, no sorting, > everything has to be done by hand with for() loops. KOENIG: Part of the design of the library is that algorithms, such as searching, that apply to many kinds of data structures are separate so that you don't need an individual search function for vectors, another one for lists, and so on. Nevertheless, those algorithms are there, and the claim that ``everything has to be done by hand with for() loops'' is false. For example, if v is a vector, then sort(v.begin(), v.end()); sorts the elements of v, and find(v.begin(), v.end(), x) returns a vector iterator that refers to the first element of v that is equal to x (or a copy of v.end() if no such element exists). Chapter 3 describes a number of these algorithms. FUNGUS: > The other problem is lack of garbage collection. Should my library > free the contenys of a vector when it gets deleted, or not? If I > do, then any stack based objects in it will crash the system. If I > don't then the onus is on the programmer, he's going to have to clear > out the contents of all the vectors in the data before he can call > my "close()" function. Whoops! His code just got a lot bigger! KOENIG: Your library should not free the contents of a vector when it gets deleted. Instead, you should arrange that the contents behave as if they were values -- that is, that they have copy constructors and destructors that do their own resource management. It is true that garbage collection makes memory management easier, but not all resource management is memory management, and garbage collection does not help in managing non-memory resources. FUNGUS: > Then there's the problem of mixing pointers and stack based objects. > If my vector isn't stack based or global then every access to it > needs four extra punctuation symbols in the source code, eg. > (*v)->push_back(o). Nice and readable, eh? KOENIG: You would make your case more strongly if your example was correct. If v is a vector, you write v.push_back(o). If p is a pointer to a vector, you write either (*p).push_back(o) or p->push_back(0). I see no extra punctuation symbols in the latter example, although I will admit that -> is one character longer than . If you really want to avoid that extra symbol, presumably because you're using the pointer many times, you can temporarily bind a reference to the object as an abbreviation mechanism. FUNGUS: > Compared to the C++ vector, writing a wrapper class in Java to get > type safety seems like a trivial detail. You do it once then forget > it. C++ will happily fill your entire source code with junk, all in > the name of "efficiency". KOENIG: Perhaps you might learn a little more about vectors before labeling them. FUNGUS: > ...and we shouldn't even go into run-time safety, should we? Wouldn't > want to embarrass folks... KOENIG: There is always a tradeoff between run-time safety and efficiency, and efficienty seems to win from the viewpoint of a large fraction of the programming community. I am aware of two companies that tried to market a safe implementation of C++, and they both failed. Apparently people prefer to be able to write applications that run more quickly than those put out by their competition.