On Wed, Oct 12, 2011 at 11:12 AM, Ivan Shmakov <i...@gray.siamics.net> wrote: > >> Given some way to construct a sqlite3_value wrapping object, I > >> could instead rely on sqlite3_bind_value () alone, thus > >> eliminating the necessity of type specifiers in the interface. > > > Well, a hypothetical API that constructs sqlite3_value from raw data > > would have to take the type specifier anyway, wouldn't it? You would > > just be moving the same logic to another place. > > Yes. But this still may make code clearer, and, occasionally, > also more concise. Consider, e. g.: > > sqlite3_value *a > = sqlite3_int64_value (1); > assert (a != 0); > sqlite3_value *b > = sqlite3_text_value (-1, "qux"); > sqlite3_value *c > = sqlite3_blob_value (blob_size, blob); > assert (b != 0); > int r; > r = db_triv_exec_bound (db, sql_1, a, b, 0); > assert (r == SQLITE_OK); > r = db_triv_exec_bound (db, sql_2, b, c, 0); > assert (r == SQLITE_OK); > r = db_triv_exec_bound (db, sql_3, c, a, 0); > assert (r == SQLITE_OK); > sqlite3_value_free (a); > sqlite3_value_free (b); > sqlite3_value_free (c);
You can do absolutely the same thing but use your_own_value* instead of sqlite3_value*. Why stick with SQLite's internal data structures? Pavel _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
