Commit graph

6 commits

Author SHA1 Message Date
Carl Worth
2ce552b5f7 Fix lifetime-maintenance bug with std::string and c_str()
Here's more evidence that C++ is a nightmare to program---or that
I'm smart enough to realize that C++ is more clever than I will
ever be.

Most of my issues with C++ have to do with it hiding things from
me that I'd really like to and expect to be aware of as a C
programmer.

For example, the specific problem here is that there's a
short-lived std::string, from which I just want to copy
the C string. I try to do that on the next line, but before
I can, C++ has already called the destructor on the std::string.

Now, C++ isn't alone in doing garbage collecting like this.
But in a *real* garbage-collecting system, everything would
work that way. For example, here, I'm still holding a pointer
to the C string contents, so if the garbage collector were
aware of that reference, then it might clean up the std::string
container and leave the data I'm still using.

But that's not what we get with C++. Instead, some things are
reference counted and collected, (like the std::string), and
some things just aren't (like the C string it contains). The
end result is that it's very fragile. It forces me to be aware
of the timing of hidden functions. In a "real" system I wouldn't
have to be aware of that timing, and in C the function just
wouldn't be hidden.
2009-10-21 23:20:18 -07:00
Carl Worth
8ad4350fef Add notmuch_message_get_thread_ids function
Along with all of the notmuch_thread_ids_t iterator functions.
Using a consistent idiom seems better here rather than returning
a comma-separated string and forcing the user to parse it.
2009-10-21 15:23:08 -07:00
Carl Worth
6142216132 Move find_prefix function from database.cc to message.cc
It's definitely a better fit there for now, (and can likely
eventually be made static as add_term moves from database
to message as well).
2009-10-21 14:07:40 -07:00
Carl Worth
4ca1492f1b Add destroy functions for results, message, and tags.
None of these are strictly necessary, (everything was leak-free
without them), but notmuch_message_destroy can actually be useful
for when one query has many message results, but only one is needed
to be live at a time.

The destroy functions for results and tags are fairly gratuitous, as
there's unlikely to be any benefit from calling them. But they're all
easy to add, (all of these functions are just wrappers for talloc_free),
and we do so for consistency and completeness.
2009-10-20 22:24:59 -07:00
Carl Worth
f6c7810945 Rename our talloc destructor functions to _destructor.
I want to reserve the _destroy names for some public functions
I'm about to add.
2009-10-20 22:10:07 -07:00
Carl Worth
466a7bbf62 Implement 'notmuch dump'.
This is a fairly big milestone for notmuch. It's our first command
to do anything besides building the index, so it proves we can
actually read valid results out from the index.

It also puts in place almost all of the API and infrastructure we
will need to allow searching of the database.

Finally, with this change we are now using talloc inside of notmuch
which is truly a delight to use. And now that I figured out how
to use C++ objects with talloc allocation, (it requires grotty
parts of C++ such as "placement new" and "explicit destructors"),
we are valgrind-clean for "notmuch dump", (as in "no leaks are
possible").
2009-10-20 21:21:39 -07:00