Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Control Flow

2 (2.2%)

Arrays, Strings, Pointers, and References

8 (9%)

Functions

4 (4.5%)

Basic object-oriented programming

30 (33.7%)

A bit more advanced OOP (Composition, Operator overloading, Inheritance, Virtual Functions)

18 (20.2%)

Templates

8 (9%)

Other (Explain)

4 (4.5%)

Working with files?  (Streams)

15 (16.9%)

Total Members Voted: 89

[eerr]

How big will these material definitions be?

int[3], int[16],int[142]?

[Siquo]

Tough to say already. Not that big, though.
Right now int[6] + float[3], in the future up to perhaps 20. Why?

[eerr]

I was thinking structs at first, but You need objects bro.

Nice, slow, objects.

[eerr]

you're programming in C aren't you.

[Siquo]

Cpp. Nice objects. Me loves em.

Of which I have a question. Are the members of an object/class/struct always guaranteed consecutive in memory? So that even a vector of classes, where the classes only hold floats, can be treated as if it were an array of floats (in memory at least)? That would really save me time in copying the entire thing before passing it to the GPU.

[timmeh]

Cpp. Nice objects. Me loves em.

Of which I have a question. Are the members of an object/class/struct always guaranteed consecutive in memory? So that even a vector of classes, where the classes only hold floats, can be treated as if it were an array of floats (in memory at least)? That would really save me time in copying the entire thing before passing it to the GPU.

There's a good chance I'm wrong here, but from what I understand of the STL containers, they allocate the memory as necessary, so two elements in a vector may not be immediately next to each other, although I'm really not sure about that....  That being said, I do believe that a class with only non-dynamic members (float, int, etc) would have them next to each other in order, since they're declared in order, at the same time... but I wouldn't count on it, since if some portion of the memory is already being used, and the class won't fit entirely in one place, it might split it up....

I'd wait for someone more knowledgeable than me though, if you need a definite answer; because I'm really not sure.

[alway]

Yep, vectors are dynamic. So unless they are uprooting various other variables in memory to make space for new ones, they aren't going to be placed consecutively. I'm no expert on the matter either, but it just makes more sense for at least the dynamic ones to be non-consecutive.

[qwertyuiopas]

The data of a struct will be consecutive. Probably also for a class, though a class probably/will have some extra data of it's own. I don't know if a vector will be suitable, though, as it could easily silently add it's own data before each entry or split them across memory.

You can guarentee the contents of an array of structs, but not much else.

[timmeh]

If all you're trying to do is save time by not copying it, couldn't you just pass a pointer to the class?  If the function is already written to use an array, you could always use a class instead of a struct, and overload the [] operator to access the different bits and piece.  If they're all the same type it should be really easy.

[qwertyuiopas]

The problem, I believe, is that he might be passing it to an external library, so overloading array access probably isn't possible. Furthermore, he is likely passing to a library that is probably compatible with both C and C++, so it must meet C standards, and that is a pure, uncluttered, continuous array of data, best packed in structs.

Either way, passing it to the GPU means that the code will likely(or maybe not?) be someone else's, not compiled by you, and if I understand correctly, operator overloading is a compile-time change to the output.

Yep, vectors are dynamic. So unless they are uprooting various other variables in memory to make space for new ones, they aren't going to be placed consecutively. I'm no expert on the matter either, but it just makes more sense for at least the dynamic ones to be non-consecutive.

Well, there is also the possibility of realloc-like functionality, where it tries to expand in place, and if it can't, tries to relocate the entire thing to remain together. Or, it coulsd silently split into a linked list of arrays and you probably couldn't know. The beauty of encapsulation and external libraries...

[timmeh]

After a quick test, it would seem that simply type-casting a class with just float or just integer values as a pointer to that type:

Code: [Select]

(int*) &IntListThen passing it to a function that wants an array of that type works....  I don't make any guarantees it won't break later, but it seems to work.  That being said, I'm not sure if it'd work at all with vectors or maps....

Code: [Select]

class IntList
{
  IntList(int m1, int m2, int m3) {mem[0]=m1; mem[1]=m2; mem[2]=m3;}
  mem[3];
};

Code: [Select]

void outputInts(int* ints, int arrSize)
{
  for(int i=0; i<arrSize; i++)
  {
    cout << ints[i] << "\n";
  }
}

Code: [Select]

int main()
{
  IntList testList(5,3,7);
  outputInts( (int*)&testList, 3);
}
5
3
7



Works just as well using individual variables rather than an array.  Might just be my being lucky that my computer has enough memory though.

[DrPizza]

I was thinking structs at first, but You need objects bro.

Nice, slow, objects.

structs are "objects". There is no performance difference at all.

[DrPizza]

Cpp. Nice objects. Me loves em.

Of which I have a question. Are the members of an object/class/struct always guaranteed consecutive in memory?

What is this even meant to mean?

structs can have internal padding, i.e. gaps between members and after the final member to ensure alignment is suitable for the platform.
arrays cannot have padding, i.e there are no gaps between array elements
std::vector must use contiguous storage (i.e. an array). It's technically true that the original 1998 specification did not make this demand (although all implementations that anyone would ever use used contiguous storage anyway), but the 2003 revision, and the "some time this decade" revision make contiguous storage mandatory.

So that even a vector of classes, where the classes only hold floats, can be treated as if it were an array of floats (in memory at least)? That would really save me time in copying the entire thing before passing it to the GPU.

Yes, it can, by design. &*vector::begin() is the address of the first element, and can be regarded as an array of vector::size() elements.

[Blacken]

I was thinking structs at first, but You need objects bro.

Nice, slow, objects.

structs are "objects". There is no performance difference at all.

Or, for that matter, internal difference. The only difference is syntactic (defaulting to public rather than private).

[DrPizza]

Problem: World and Material Types.

So, I need a collection of MaterialTypes, that contain data such as texturenumber, density, hardness et cetera, and link those to every object in the world.
Solutions:
- A: A std::map with <integer, MaterialType>, and an int per object
- B: A pointer to the MaterialType per object
- C: Something else?

I really don't want the collection to be a "global", as globals are evil, but I'm not sure how else to do it.
Maybe use solution A, create the collection as a static singleton, with a (static?) pointer to the collection from every object? (AKA: cpp global)
And if the object doesn't know where the collection is, how can I use option B to get a pointer to one of the MaterialTypes?

Singletons are functionally globals, just with slightly easier/more reliable initialization. Don't use them.

Pass it as a parameter to objects that need it.