Print

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

[miauw62]

you can just pass the size as a parameter, or make a struct/basic class to pass all the values and data together. There's a lot you can do before considering templatizing all your functions for basic stuff.

2D arrays are passed as type array[]

• , which is fixed at compiletime. You can just do this "manually" with a 1D array to make it act like a 2D array, but that's not ideal either.

[Reelya]

The best solution is what I said earlier. Make a minimal wrapper class that just has a data pointer, x and y size, a constructor to make the data, destructor to free the memory, and an [] operator which takes x and y parameters, and returns a reference. You might want to make the data type itself a template though, so that the code can be reused for different data types.

There's no need to templatize the function that the array is passed to, and that would mean you couldn't change the size of the array at runtime, since template parameters need to be constants. By wrapping the data in a simple class, you get the ability to pass around arbitrary-sized 2D arrays.

[Gentlefish]

you can just pass the size as a parameter, or make a struct/basic class to pass all the values and data together. There's a lot you can do before considering templatizing all your functions for basic stuff.

2D arrays are passed as

Code: [Select]

type array[][x], which is fixed at compiletime. You can just do this "manually" with a 1D array to make it act like a 2D array, but that's not ideal either.

There you go. Today I learned a neat BBC line!

[alway]

Added a second graphics tutorial code thing here: https://github.com/jalway/tut2
Actual OpenGL in this one, though you can hardly tell the difference. It's 3D rendering, with the object in question generated in the shader, like with the previous one. Unfortunately, the 3D transformation matrices are mostly unexplained (I figured they were covered in one of the other tutorials being put together, but they don't seem to be, so that will be addressed in future stuff), but there's a variety of interesting tidbits in the vertex shader. Again, feedback's always welcome on these, since the end goal is to subject students and such to them.

[miauw62]

The best solution is what I said earlier. Make a minimal wrapper class that just has a data pointer, x and y size, a constructor to make the data, destructor to free the memory, and an [] operator which takes x and y parameters, and returns a reference. You might want to make the data type itself a template though, so that the code can be reused for different data types.

There's no need to templatize the function that the array is passed to, and that would mean you couldn't change the size of the array at runtime, since template parameters need to be constants. By wrapping the data in a simple class, you get the ability to pass around arbitrary-sized 2D arrays.

Once you have implemented what you said, how different is it from a vector<vector<>>? (especially if you use push_back() sparingly)
I guess you could also have a function to change XY coords into the position on the array, (array[function(X, Y, Xsize, Ysize)]), although the size would still be fixed on compiletime.
But yeah you're right about the function templates.

[Reelya]

It's a hell of a lot different from a vector<vector>. With a vector of vectors you have to do a lot more work to get the context right of it being a 2D array, for loops (either explicit or implicit) to size all the inner vectors and everything.

The code for a simple custom 2D array wrapper is just this:

Code: [Select]

template <class T> class grid
{
    T *data;
public:
    int sizex, sizey;

    grid(int _sizex, int _sizey) : sizex(_sizex), sizey(_sizey)
    {
        data = new T[sizex * sizey];
    }

    ~grid() { delete [] data; }

    T &operator[](int x, int y) { return data[x + sizex * y]; }
}

// usage:
grid<char> charArray2D(20,20);

There you go, a fully encapsulated 2D array that can be sized at runtime, and passed as a single parameter, no bullshit or complexity. It's templatized, but the actual code is so minimal that it won't really bloat much if you make 2D arrays of different types. You can add optional bounds-checking inside the class, but have the advantage of being able to turn it off for higher speed, if you've sufficiently debugged the rest of your program.

with vector<vector> it's already instantiating two copies of the vector class and everything that goes with it, (vector<thing> and vector<vector<thing>>) including cloning the iterator types. Then, accessing the vector is a matter of chaining the calls through the methods of the two separate vector classes, so that's more runtime overhead.

[miauw62]

Fair enough. I do as I said, though, "pure" 2D arrays are butt.

E:
what was i thinking when i wrote "i do as i said"

[MorleyDev]

The 'single vector' approach also minimises cache misses when iterating through a grid. Vectors are continuous blocks of memory, but there vectors in a vector-of-vectors will be dotted around the heap, so iterating causes cache misses (this is why std::list is slower to iterate) 

Arguing like this may seem like a premature optimisation, but using a single vector like above is also a simpler and cleaner solution than using a vector of vectors (when the size of the grid doesn't need to change after it's been created). It's a recurring trend I've noticed in software that most of the time, the simplest/cleanest solution is also the one most likely to be the one that is efficient enough. Especially with the current state of the optimisations compilers can make nowadays.

[Reelya]

Hiding things behind wrappers can be a good idea, especially if "premature optimization" is under debate. Wrap the quick and dirty method up behind a wrapper class or function. This gives you the best isolation of client-side and implementation-side code. Ideally, the client code shouldn't know whether it's implemented my way, or by a vector of vectors.

If you're using a library, designing your code to use wrappers from the start can be a very good idea. Rather than including the .h file for the library everywhere, include it in a .cpp file, then give that .cpp file a .h file which contains functions that pass calls to the library. Presto, you've isolated library calls to that one .cpp file, which helps if you want to change to a new library later. With this approach thinking something like "We support OpenGL but wouldn't it be good to support Direct3D too?" goes from nearly impossible to quite achievable. Compare that to a situation where you have raw OpenGL calls scattered amongst dozen of places in the progam. The "straightforward" solution to that would be to put if/then or #ifdefs around every single library call in every cpp file.

[alway]

Taking a free 20x speedup isn't premature optimization, that's simply not being daft. Aside from that, a vector of vectors isn't an nxn grid. It's n arrays of lengths o,p,q,r,s,t... etc; after all, each element of the vector of vectors is itself a vector, which could be anything.

And yes, simpler code is usually better code. If your code is doing less... then that means your code is doing less. Which is obviously a good thing in terms of performance.

However, I would warn somewhat about wrapper classes. I recommend doing without them initially, and only introducing them after you've used the systems enough that the patterns of use become obvious to you. It's really easy to put a wrapper around something which partially obscures the implementation details which would have helped you if you put things into wrappers when still in the 'planning what to code' phase.

[Gatleos]

Did someone say 2D Arrays?

I made that a while back. I was actually going to post it here for advice on improving it. It's the first time I've made a custom iterator or elaborate template class like that, so I'm sure I messed something up.

Also 2D+ c-style arrays are evil never use them

[TheDarkStar]

Is there a way to use operator overloading to change what repeated brackets refer to? For example, this:

void main()
{
//blah blah blah
2DVector 2DListOfStuff;
OutVariable = 2DListOfStuff[4][5];
//output and then do other stuff
}

where 2DListOfStuff is a class that stores a single vector that holds all the values and then the [] (or [][] or whatever) operator is overloaded to access specific parts of the array. Could it work?

[Reelya]

my last post overloads [] to take x and y values, i.e. "grid[x,y]".

repeated brackets could be emulated by overloading the first bracket to do the row, and the second bracket return the column. It's definitely do-able, and can work in parallel to the two-parameter version. But you probably want the first value to be "x" and the second value to be "y", so you want a column-centric grid rather than row-centric like normal if you want that. Usually I have a row-centric grid and put 'y' as the outside loop. This is better for caching memory reads, you want your reads to follow the flow of the data. But with a column-centric grid, i.e. [X][Y], you want to loop X as the outer variable, and Y as the inner variable.

Adapting my previous code, it would work like this

T *operator[](int x) { return &data[x * sizey]; }

This returns a 'T" pointer, pointing at the memory location of the top of the requested column. Then, a second [] is used to look up the cell in that column, using c++'s normal pointer dereferencing. I modified my code below so that it will now work with either [X,Y] or [X][Y] addressing.

Spoiler (click to show/hide)

Code: [Select]

template <class T> class grid
{
    T *data;
public:
    int sizex, sizey;

    grid(int _sizex, int _sizey) : sizex(_sizex), sizey(_sizey)
    {
        data = new T[sizex * sizey];
    }

    ~grid() { delete [] data; }

    T &operator[](int x, int y) { return data[x * sizey + y]; }

    T *operator[](int x) { return &data[x * sizey]; }
}

// usage:
grid<char> charArray2D(20,20);


[Skyrunner]

C++17 to have modules! Hype :v

[Putnam]

haha FUCK header files

parallel algorithms (incl. parallel versions of some of the STL)
Simplify core language use, especially as it relates to the STL and concurrency, and address major sources of errors.

maybe people will stop whining to Toady about multi-threading :V