need to get the type of a variable inside the data structure

[baxy]

Hi i need to get the type of the vector which is inside my structure and ai need to asign it to a variable but i don't quite get how to do it.

#include <iostream>
#include <vector>


using namespace std;

struct K{
	vector<long> f;
};

template <typename Z>
void func (Z &x)
{
// here i would like that my k is of type long as a value inside vector<long> f;
typename Z::typeof(x.f)::value_type  k;
k = x.f[0];


//cout << sizeof(x.f) << " " << sizeof(k)<< " " << x.f[0] << " " << k << "\n";
}


int main (){

 K x;
 x.f.reserve(3);
 x.f[0] = 7;
 x.f[1] = 78;
 x.f[2] = 5;
 func (x);


}

thnx baxy

[Elkvis]

why do you need to know the type? can't you just write overloaded functions for several types, and let the compiler figure it out?

[baxy]

why do you need to know the type? can't you just write overloaded functions for several types, and let the compiler figure it out?

so you are saying that if i have short int and long, uint32_t int32_t ... and i need to iterate over those arrays and then add a number of the same type this would be wrong? the reason i am trying to do this is because i am trying to work with large arrays and if array is small enough to be stored in int vec then why not use it, but if not then i wanna make a switch to long and use the same function to do may processing.

besides if i cannot do this then my functions will always be dependent on the input and then why use templates anyway if i need to write for each type a different function. Right ?

[Elkvis]

perhaps you should look into using templates. but if you don't want to go the template route, you can have multiple functions that take parameters of different types, and the compiler will call the correct one based on the types of the variables passed as parameters.

[oogabooga]

If your compiling as C++11 you can use auto.

auto k = x.f[0];

And you should be using the vector member function resize not reserve for what you're doing in main. Try putting the following just before your func(x) call in main and it'll say 0. Change to resize and it'll say 3.

std::cout<<x.f.size()<<'\n';

[baxy]

And you should be using the vector member function resize not reserve for what you're doing in main. Try putting the following just before your func(x) call in main and it'll say 0. Change to resize and it'll say 3.

std::cout<<x.f.size()<<'\n';

Ups , yes I know, you are right, my mistake

i also found another workaround

typedef typeof(x.f) k;
typename k::value_type l;

a bit redundant but working ...

[Elkvis]

using typeof, typeid, or dynamic_cast is usually a sign of poor program design. maybe you should go into greater detail about what you're trying to do, and someone can offer a better, less fragile solution.

[baxy]

using typeof, typeid, or dynamic_cast is usually a sign of poor program design. maybe you should go into greater detail about what you're trying to do, and someone can offer a better, less fragile solution.

well it is a simple thing i am trying to read a one column data (ints) sometimes these numbers can be stored as 32 bit ints sometimes as 64 bit ints. that is, sometimes thay go up to 2^31, sometimes larger. if they go to 2^31 then why not use that, especially if you are most of the time on the border and want to use a regular 32 bit desktop. so far with my c code i always received good critiques on how small amount of memory it takes. you can call it a bad design but ...

[Elkvis]

perhaps you should consider using a structure then. something like this:

struct DataElement
{
    void* data;
    unsigned char size;
};

depending on the value of the data you want to store, you can dynamically allocate as little as 1 byte, or as many as 8 to store the value, and store the length of the allocated memory region in the size field. you could take it one step further and make it a class with constructors, destructor, getters, setters, and overloaded operators to handle the data more naturally. this approach would require a bit more memory than a simple array of 32-bit integers, especially if it's compiled as a 64-bit program, in which case it would be even less memory efficient than a simple array of 64-bit ints, but on a 32-bit machine it might be a little more efficient than an array of 64-bit integers.

the additional indirection is likely to make it slightly slower though, so keep that in mind, and endianness becomes a factor here as well, so watch out for that.

[oogabooga]

well it is a simple thing i am trying to read a one column data (ints) sometimes these numbers can be stored as 32 bit ints sometimes as 64 bit ints. that is, sometimes thay go up to 2^31, sometimes larger. if they go to 2^31 then why not use that, especially if you are most of the time on the border and want to use a regular 32 bit desktop. so far with my c code i always received good critiques on how small amount of memory it takes. you can call it a bad design but ...

That should be "up to 2^31 - 1".

Critiques from whom?

And Elkvis obviously didn't call using less memory a bad design, just the way you were going about it due to your inexperience.

[Salem]

> but on a 32-bit machine it might be a little more efficient than an array of 64-bit integers.
But due to alignment, the size of DataElement is almost certain to be 64-bits to begin with, and that's before you allocate any memory.

Memory allocation also has a huge overhead for small quantities.
A typical allocator will keep all the allocated/free blocks in a linked list (which will cost say two pointers), and a further word to store the allocation size.
Further still, to minimise the effects of fragmentation, block allocations could be rounded up to multiples of say 16 bytes (even if you only allocate 1 byte).
Additionally, debug versions of malloc also employ guard blocks (and other things) to detect such things as buffer overruns.

Unless the number of 64-bit ints is sparse compared to the number of 32-bit ints in the array, it's going to be hard to efficiently encode the distinction between a 32-bit value and a 64-bit value without burning extra bits just to say 'it's different'.

Perhaps something like this.

uint32 array[LARGE];
uint64 spill[EXTRA];

if ( value <= 0x7FFFFFFF ) {
  array[aIndex++] = value;
} else {
  offset = sIndex | 0x80000000;
  array[aIndex++] = offset;
  spill[sindex++] = value;
}

Basically, use the MSB as the flag, and push anything greater than 0x7FFFFFFF (31 bits) into the spill array.

So when you come to scan array, you test the MSB to see if you should be looking in the spill array, and then mask out the spill array index to get the large value.
Otherwise, you just use the small value directly.

[MutantJohn]

Wait, shouldn't it be 2^32 - 1?

If we had two bits, the largest possible value would be 3 as you'd have 11 which is 2+1 = 2^2 - 1.

If we had three bits, the largest possible value would be 7 as you'd have 111 which is 4+2+1 = 2^3 - 1.

If we had four bits, the largest possible value would be 15 as you'd have 1111 which is 8+4+2+1 = 2^4 - 1.

So then wouldn't the largest possible 32 bit value be 2^32-1 or is one bit dedicated to storing the sign of the number? And that's because you can have negative ints, my bad.

[oogabooga]

Wait, shouldn't it be 2^32 - 1?

I think you figured this out at the end!
Look up Two's complement - Wikipedia, the free encyclopedia to see how it works.
Interestingly, the highest positive number is 2^31-1 but the lowest negative is -2^31.
So there's one more negative number than positive!

[iMalc]

I certainly second Salem's advice, and in fact it can be extended further, to what is known as "Start-Step-Stop coding". In your case, for performance, it's best implemented as Salem described, rather than reading from a byte stream.
Or if you access the values sequentially rather than random access, then for extreme space savings something like Fibonacci Coding is pretty good.

Some useful references:
Variable-Length Codes for Data Compression
Handbook of Data Compression - David Salomon, Giovanni Motta - Google Books
https://en.wikipedia.org/wiki/Variable-length_code
https://en.wikipedia.org/wiki/Univer...a_compression)

Oh what the heck, I've actually done significant research on this topic and implemented a huge number of the coding schemes in existence. Today I'm feeling generous so... http://homepages.ihug.co.nz/~aurora7...versalEncode.h

[phantomotap]

UniversalEncode.h

O_o

You have some strangely tight binding to class implementations for reading/writing.

Have you considered parametric polymorphisms or using the iterator pattern?

Soma

Example (parametric polymorphism):

template <class T>
void outputBit(T & bitWriter, uint bit) {
	bitWriter.outputBit(bit);
}

// ...

template <class T>
void expGolombEncode(uint x, T &bitWriter) {
	++x;
	int l = 0;
	for (uint xx = x; xx > 1; xx>>=1)
		++l;
	for (int i=0; i<l; ++i)
		outputBit(bitWriter, 0);
	for (int i=l; i>=0; --i)
		outputBit(bitWriter, (x >> i) & 1);
}

// ...

Allowing (me, or any other, as a client to only add) a new interface to an existing object:

void
	outputBit
(
    Bitstream & fOut // a class I've already written
  , uint fBit
)
{
    fOut.append(fBit);
}

Instead of (forcing mew to make) a wrapper:

class Wrapper
{
    Wrapper
    (
        Bitstream & fStream
    ):
        mStream(fStream)
    {
    }
    // ...
    void ouputBit
    (
        uint fBit
    )
    {
	    mStream.append(fBit);
    }
    // ...
};

Example (iterator):

template <class T>
void expGolombEncode(uint x, T bitWriter) {
	++x;
	int l = 0;
	for (uint xx = x; xx > 1; xx>>=1)
		++l;
	for (int i=0; i<l; ++i, ++bitWriter)
		*bitWriter = 0;
	for (int i=l; i>=0; --i, ++bitWriter)
		*bitWriter = (x >> i) & 1;
}

// ...

Allowing (me or any other client) to create a new inserter or transform an existing iterator:

// ...
template
<
    typename FInserter
>
class BitInserter
{
    BitInserter
    (
        FInserter fInserter
    );
    // ...
    BitInserter & operator * ();
    BitInserter & operator = 
    (
        uint fBitValue
    );
    BitInserter & operator ++();
    BitInserter & operator ++(int);
    // ...
    typename std::iterator_traits<FType>::value_type mString; // temporary storage
    uint mUsed; // storage used
    FInserter mInserter; // target
    // ...
};
// ...

Granting:

std::vector<unsigned long> s;
expGolombEncode(/*whatever*/, BitInserter(back_inserter(s)));