Looks a newbie question, but this function is called many times, to be honest thousands of time per-second, so an optimization is CRUCIAL in here. What would be the best method?
struct CHOLDELEM
{
DWORD dwColor[3], dwItemId[3];
int nPos[3], nLength[3];
CItemElem* pItem[3];
CHOLDELEM()
{
for( int i=0; i<=3; i++ )
{
dwColor[i] = dwItemId[i] = 0;
nPos[i] = nLength[i] = 0;
pItem[i] = NULL;
}
}
};
or with memsets?
memset( dwColor, 0, sizeof( dwColor ) );
or another method.
As long as you are interested in zero initialization only, you can simply do
CHOLDELEM() : dwColor(), dwItemId(), nPos(), nLength(), pItem()
{}
(no C++11 necessary).
However, you might want to take a look at the code your compiler generates for it. If it is not optimal somehow, then a better idea might be to keep your struct a POD (no constructor) and initialize it "from outside" when you declare objects of that type
CHOLDELEM c = {};
If your compiler can handle C++11 initializers, then you can set the array values in the constructor initializer list:
CHOLDELEM() :
dwColor{0}, dwItemId{0}, nPos{0}, nLength{0}, pItem{nullptr}
{ }
Then the compiler will generate (pretty optimal) code to handle that.
I would probably use the memset approach, but I would definitely want to make sure that it doesn't break when more complex data members are added to CHOLDELEM:
#include <type_traits>
// ...
CHOLDELEM()
{
static_assert(std::is_trivially_copyable<CHOLDELEM>::value,
"It is no longer safe to use memset!");
memset(this, 0, sizeof *this);
}
By the way, CHOLDELEM is a terrible name. Why don't you rename it to ElementHolder or something?
Related
Sorry for the atrocious title.
The scenario is that I have a configuration system in my program, that needs to able to hold values of all types. These values (configurants) need to be held in a homogenous container.
For example: (this is pseudo-code, I'm not sure how this would actually look)
configurant i(64);
configurant b(true);
configurant f(128.f);
configurant custom(Color(255, 255, 255));
vector<configurant> confs;
confs.emplace_back(i);
confs.emplace_back(b);
confs.emplace_back(f);
confs.emplace_back(custom);
// some form of accessing the vector with proper configurant type here:
// casting?
Like I said, I don't know how this system would look in practice. I know that a statement like
auto color = confs.at(3).rgb();
is generally not possible in C++, but is there something I could do with templated metaprogramming to try and get as close as possible to this solution?
(perhaps the configurants could be mapped with their type? but this would not be a compile time operation)
I'm looking to create a system that is storable homogeneously, immediately accessible (not stored on the heap) and that evaluates the validity of operations at compile time.
Open to any suggestions.
And before the comments come in, I've experimented with std::any/std::any_cast, std::variant, the visitor pattern, and other things of that nature. I'm not looking to use any of those systems.
EDIT To avoid confusion, there are N configurants: it is not a statically sized group of configurants. More configurants would be added by the user of this interface.
EDIT 2 Additional example of desired usage
class foo {
configurant enabled;
configurant bar;
public:
foo() {
this->enabled = configurant(true);
this->bar = configurant(5);
}
void body() {
if(this->enabled) {
std::cout << (this->bar < 100) << "\n";
}
}
// It also needs to be kept in mind that these configurant classes
// cannot be templated (directly, at least), since they need to be stored in
// a homogeneous container.
};
Because of this requirement
"that evaluates the validity of operations at compile time.",
this means that your example
auto color = confs.at(3).rgb();
will only work with the index 3 known at compile time
(why not 2 or 4?).
This index is not very relevant/useful in this situation.
May be should you simply consider a structure providing
the required data with a proper name instead of a
compile-time index?
struct Confs
{
configurant<int> i;
configurant<bool> b;
configurant<float> f;
configurant<Color> custom;
};
...
Confs confs{64, true, 128.f, Color(255, 255, 255)};
auto color = confs.custom.rgb();
Something like this could rely on a compile-time index
but I don't really see the benefit over a named member.
auto confs=std::make_tuple(64, true, 128.0f, Color{255, 255, 255});
auto color = std::get<3>(confs).rgb();
Context: I'm trying to memoize an object of a template class. Right now, the class is a deeply nested data structure full of unique pointers, and so doesn't have a copy constructor (and so would be impossible to cache, as far as I know). However, in the future, I would like to allow memoization if a copy constructor is available. I tried the following code:
// some function here... {
static std::unordered_map<State, Result> cache;
return [c, ToValue](State state) {
if (cache.find(state) != cache.end()) {
std::cout << "retrieving Literal from cache\n";
if (std::is_copy_constructible<Result>::value) {
return cache[state];
}
}
// calculate and return a Result
This code doesn't compile because Result doesn't have a copy constructor. Is there any way to get around this? Google is being quite unhelpful.
I'm presuming the error you are getting is that return cache[state]; cannot be compiled when the object is not copy-constructible. To fix that you can write:
if constexpr (std::is_copy_constructible<Result>::value) {
return cache[state];
}
If you are still having trouble then post a MCVE that has the error.
As others have commented, the question is rather ill-defined and a bit confused, but do you need to actually copy an object in order to cache it?
Actually, no. You can use std::shared_ptr to share ownership of the object between the creator, any consumers, and the cache. If nothing else, this is much more efficient if your object is a complex one. It will also work for any type of object, copyable or not.
Example (I'm going to use the word Key rather than State, for what I hope are obvious reasons).
Given these declarations:
class MyKey
{
// ....
};
class MyCacheableObject
{
// Constructor
MyCacheableObject (int a, int b, int c) { ... }
// ...
};
static std::unordered_map<MyKey, std::shared_ptr<MyCacheableObject>> cache; // or std::map
You can do this (please note that there are other ways to make a std::shared_ptr, see here):
std::shared_ptr<MyCacheableObject> CreateCacheableObject (int a, int b, int c)
{
return std::make_shared<MyCacheableObject> (MyCacheableObject (a, b, c));
}
And then, assuming you have a key you plan to use to retrieve the object from the cache later on, you can do:
MyKey someKey = ...;
std::shared_ptr<MyCacheableObject> newObject = CreateCacheableObject (1, 2, 3);
// ... setup / use `newObject` in whatever way is appropriate to your use-case
cache [someKey] = newObject;
And you can of course retrieve the object from the cache (if it's in there) via:
auto retrievedObject = cache.find (someKey)
if (retrievedObject != cache.end())
...
So this question is not about whether an object is copyable at all. It's about (shared) ownership and std::shared_ptr takes care of all that for you, you don't really have to think about it. Oy vay.
There's a live demo, to show that this all compiles, here.
How did Boost implement Tuple before C++11 and Variadic Templates?
In other words:
Is it possible to implement a Variadic Templates class or function by not using built-in Variadic Templates feature in C++11?
Boost had a limit for the size of the tuple. As in most real-world scenarios you don't need more than 10 elements, you won't mind this limitation. As a library maintainer, I guess, the world became much simpler with variadic templates. No more macro hacks...
Here is an insightful discussion about the size limit of Boost tuple and its implementation:
boost tuple: increasing maximum number of elements
To answer your second question: No, it is not possible. At least not for an unlimited number of elements.
There are 2 common use cases I've seen, as a library developer, for variadic templates. You can build a work around for both.
Case 1: Function objects
std::function<> and lambdas are very nice, but even c++11 only gives you a fairly basic set of things you can do with them "out of the box". To implement really cool things and utilities on top of them, you need to support variadic templates because std::function can be used with any normal function signature.
Workaround:
A recursive call using std::bind is your friend. It IS less efficient than real variadic templates (and some tricks like perfect forwarding probably won't work), but it'll work okay for modest #s of template arguments until you port to c++11.
Case 2: Ordinary classes
Sometimes you need an ordinary class to manage generic std::function<>s (see above) or expose an API like "printf". Workarounds here come down to details and what each API of the class is doing.
APIs that merely manipulate variadic template data but don't need to store it can run as recursive calls. You need to write them so that they "consume" one argument at a time, and stop when they run out of arguments.
APIs (including constructors) that need to STORE variadic template data are harder- you're screwed if the types are really unlimited and could be anything. BUT, if they're always going to be primitives that map deterministically to binary, you can do it. Just write a "Serialize" call taking all the types you support, then use it to serialize the entire set into a binary buffer and build a vector of "type info" data you use to fetch & set them. Its actually a better solution than std::tuple in terms of memory and performance in the special cases its available.
Here's the "serialize tuple" trick:
// MemoryBuffer: A basic byte buffer w/ its size
class MemoryBuffer {
private:
void* buffer;
int size;
int currentSeekPt;
protected:
void ResizeBuffer() {
int newSz = size << 1; // Multiply by 2
void* newBuf = calloc( newSz, 1); // Make sure it is zeroed
memcpy( newBuf, buffer, target->size);
free( buffer);
size = newSz;
buffer = newBuf;
}
public:
MemoryBuffer(int initSize)
: buffer(0), size(initSize), currentSeekPt(0)
{
buffer = calloc( size, 1);
}
~MemoryBuffer() {
if(buffer) {
free( buffer);
}
}
// Add data to buffer
bool AddData(const void* data, int dataSz) {
if(!data || !dataSz) return false;
if(dataSz + currentSeekPt > size) { // resize to hold data
ResizeBuffer();
}
memcpy( buffer, data, dataSz);
return true;
}
void* GetDataPtr() const { return buffer; }
int GetSeekOffset() const { return currentSeekPt; }
int GetTotalSize() const { return size; }
};
struct BinaryTypeInfo {
std::type_info type; // RTTI type_info struct. You can use an "enum"
// instead- code will be faster, but harder to maintain.
ui64 bufferOffset; // Lets me "jump" into the buffer to
}
// Versions of "Serialize" for all 'tuple' data types I support
template<typename BASIC>
bool Serialize(BASIC data, MemoryBuffer* target,
std::vector<BinaryTypeInfo>& types)
{
// Handle boneheads
if(!target) return false;
// Setup our type info structure
BinaryTypeInfo info;
info.type = typeid(data);
info.bufferOffset = target->GetSeekOffset();
int binarySz = sizeof(data);
void* binaryVersion = malloc( binarySz);
if(!binaryVersion) return false;
memcpy( binaryVersion, &data, binarySz); // Data type must support this
if(!target->AddData( binaryVersion, binarySz)) {
free( binaryVersion);
return false;
}
free( binaryVersion);
// Populate type vector
types.push_back( info);
return true;
}
This is just a quick & dirty version; you'd hide the real thing better and probably combine the pieces into 1 reusable class. Note that you need a special version of Serialize() if you wish to handle std::string and more complex types.
Question is in bold below :
This works fine:
void process_batch(
string_vector & v
)
{
training_entry te;
entry_vector sv;
assert(sv.size() == 0);
...
}
However, this causes the assert to fail :
void process_batch(
string_vector & v
)
{
entry_vector sv;
training_entry te;
assert(sv.size() == 0);
...
}
Now I know this issue isn't shrink wrapped, so I'll restrict my question to this: what conditions could cause such a problem ? Specifically: variable initialization getting damaged dependant on appearance order in the stack frame. There are no malloc's or free's in my code, and no unsafe functions like strcpy, memcpy etc... it's modern c++. Compilers used: gcc and clang.
For brevity here are the type's
struct line_string
{
boost::uint32_t line_no;
std::string line;
};
typedef std::vector<boost::uint32_t> line_vector;
typedef std::vector<line_vector> entry_vector;
typedef std::vector<line_string> string_vector;
struct training_body
{
boost::uint32_t url_id;
bool relevant;
};
struct training_entry
{
boost::uint32_t session_id;
boost::uint32_t region_id;
std::vector< training_body> urls;
};
p.s., I am in no way saying that there is a issue in the compiler, it's probably my code. But since I am templatizing some code I wrote a long time ago, the issue has me completely stumped, I don't know where to look to find the problem.
edit
followed nim's suggestion and went through the following loop
shrink wrap the code to what I have shown here, compile and test, no problem.
#if 0 #endif to shrink wrap the main program.
remove headers till it compiles in shrink wrapped form.
remove library links till compiles in shrink wrapped form.
Solution: removing link to protocol buffers gets rid of the problem
The C++ standard guarantees that the following assertion will succeed:
std::vector<anything> Default;
//in your case anything is line_vector and Default is sv
assert(Default.size() == 0);
So, either you're not telling the whole story or you have a broken STL implementation.
OR: You have undefined behavior in your code. The C++ standard gives no guarantees about the behavior of a program which has a construct leading to UB, even prior to reaching that construct.
The usual case for this when one of the created objects writes beyond
its end in the constructor. And the most frequent reason this happens
in code I've seen is that object files have been compiled with different
versions of the header; e.g. at some point in time, you added (or
removed) a data member of one of the classes, and didn't recompile all
of the files which use it.
What might cause the sort of problem you see is a user-defined type with a misbehaving constructor;
class BrokenType {
public:
int i;
BrokenType() { this[1].i = 9999; } // Bug!
};
void process_batch(
string_vector & v
)
{
training_entry te;
BrokenType b; // bug in BrokenType shows up as assert fail in std::vector
entry_vector sv;
assert(sv.size() < 100);
...
}
Do you have the right version of the Boost libaries suited for your platform? (64 bit/32 bit)? I'm asking since the entry_vector object seems to be have a couple of member variables of type boost::uint32_t. I'm not sure what could be the behaviour if your executable is built for one platform and the boost library loaded is of another platform.
I saw someone writing code like this , in a C++ class:
int foo ( int dummy )
{
this->dummy = dummy;
}
Shall we use code like that , will it cause problems ?
I tried to compile something like this , it seems to be worked.
#update:
I posted this mostly about the name dummy , and the internal variable this->dummy , and if it's problem causing
That's perfectly fine for a member function, other than you're missing a return statement. dummy will shadow the member variable and so you use this-> to refer to member.
int foo ( int dummy )
{
this->dummy = dummy; // set member to argument
return this->dummy;
}
Don't do this for things more complex than a simple set function, as it's confusing.
int foo ( int dummy ) // Bad practise! Rename this param as the function isn't a setter
{
this->dummy = dummy * 2 + 1;
return this->dummy;
}
There is nothing wrong with doing that perse. It can get confusing though if you use dummy assuming it is coming from the class but its actually coming from the parameter.
IMO, its better to use something to denote it is a class member. Some people use simply mDummy, other m_Dummy, others just write dummy_.
Its up to you what you prefer but most of all you should be consistent.
The code is not fine. The function is defined as returning an int but there is no return statement. The compiler might only give a warning about this, but the function calling foo might expect it to return a valid value, which it doesn't, and bad stuff might happen.
You have to do it this way if you're passing a parameter with the same name as the member variable.
But it might be a better practice to avoid a hidden (member-)variable by using different names. There's different coding styles, some would use dummy_, some would use mDummy or other ways to name member variables. This makes your code less confusing.
Well there is nothing wrong with your use, but the code needs to return an int as its an int function :)
Dummy variable in your current class is assigned to the passed int, however do remember they are different but now pointing to the same thing, therefore its better to give it a different name as its in a different.
You could however loose precision under certain variable types.
#include <stddef.h>
typedef struct intlist {
int size;
int i[1];
} intlist;
intlist *
makeintlist (int size)
{
intlist *ilp = malloc (offsetof (intlist, i[size])); /* not C++ */
ilp->size = size;
return ilp;
}
member variable size is allocated to size
That will work.
Don't do it, it's confusing!