netcat posted:

Here's something I thought was kinda strange. The following does not compile:

code:

#include <vector>
#include <iostream>
 
struct foo
{
 int x;
 char name[8];
};
 
 static std::vector<foo> b = {
    { 1, "a" },
    { 2, "b" }
 };
 
int main()
{
    for (auto it = b.begin(); it != b.end(); ++it)
    {
        std::cout << it->name << "\n";
    }
    
    return 0;
}

prog.cpp:13:2: error: could not convert ‘{{1, "a"}, {2, "b"}}’ from ‘<brace-enclosed initializer list>’ to ‘std::vector<foo>’

http://ideone.com/UlCXDN

But if I instead use { 'a', '\0' } when creating the char-arrays, it compiles just fine. Why does it work like that?

rjmccall posted:

If Mat is backed by a heap allocation, then yes, it is likely to perform better if you re-initialize the same allocation every iteration instead of allocating and freeing it each time.

You might also consider not spuriously copying the vectors of points in g and reusing the same vector (or even a fixed-size array) for glyphCorners.

bobua posted:

Actually, I don't think that code will even work, since glyphCorners wouldn't be cleared out at the start of the next loop, right? I need to have only 4 corners for the perspective matrix function to work.

bobua posted:

Updated to this.

Vinterstum posted:

Most likely your Mat class doesn't do any heap allocations, in which case moving them outside of the loop likely doesn't make a difference (should be quick to check).

More importantly though, you never want to return the pointer to a stack variable from a function; as soon as the function exits, the stack frame becomes invalid and any stack allocated objects get destructed.

Either return the std::vector by value (probably ok due to return-value optimization), or pass a reference to an output vector as an argument.

bobua posted:

code:

glyph = Mat::zeros(110,110, CV_8UC3);

bobua posted:

How would I check if something does heap allocations just out of curiosity?

bobua posted:

Not sure if I understand that last part... Are you saying add something like std::vector<Mat>* myVariable to 'fixGlyphs' argument list, then setting myVariable = &glyphImages instead of using return?

bobua posted:

How would I check if something does heap allocations just out of curiosity?

quote:

Not sure if I understand that last part... Are you saying add something like std::vector<Mat>* myVariable to 'fixGlyphs' argument list, then setting myVariable = &glyphImages instead of using return?

rjmccall posted:

I think Mat is heap-backed; among other things, it doesn't seem to have fixed dimensions.

bobua posted:

Okay, I did this before you guys posted, and I'm not getting why it wouldn't work...

Wouldn't MyMat now point to the vector I'm looking for? I was assuming when you passed in pointers to an object, you could modify that object within the function, if not I've made a huge mistake /GOB

Vinterstum posted:

No, in this case you'd be overwriting whatever memory the uninitialized MyMat pointer is pointing to (and likely crash). You need to have an actual object to assign to:

code:

std::vector<Mat> MyMat;
FixGlyphs(...,..., &MyMat);

EDIT: Just to clarify: The above will work, but you're still doing a completely redundant copy as you're still allocating an std::vector on the stack, then copying that into MyMat. Just push your glyphs into "MyMat" directly, rather than going via a temporary vector.

karoshi posted:

Correct. Optimization priority list:
* cache
* cache
* cache

...

Xerophyte posted:

bobua posted:

I tried that, but when I tried to do MyMat.push_back or *MyMat.push_back intellisense says 'expression must have class type'

Vinterstum posted:

Assuming MyMat is is the name of the parameter to FixGlyphs and it's a pointer type, try MyMat->push_back(glyph) or (*MyMat).push_back().

I think at this point I'd really recommend picking up a C++ textbook though, and focus on pointers and stack vs. heap. No offense, but it feels like you're trying to do something a bit over your current C++ level.

ratbert90 posted:

There's entirely too many colons in this thread. As a C programmer that makes me sad.

mobby_6kl posted:

Alright, thanks! The acceleration structure of course comes first, the whole talk about cache basically started from trying to explain the performance difference between two processors. I was thinking of using an octree as I'm familiar with quadtrees, but what could be better here, a kd-tree perhaps?

astr0man posted:

I feel the same way buddy

ratbert90 posted:

Why can't people just use enums and call it good? Just ignore the vast libraries that make life easy for you in C++!

Xerophyte posted:

Not that cache isn't important, but you implement an acceleration structure so that you can render a scene with a million triangles by doing collision tests with 4 triangles and 25 planes per trace. Less thrashing the cache is a nice side effect but in optimization its a far distant second to just improving the algorithmic efficiency of the intersection search. This is also why the most significant potential improvement after implementing an octree is implementing something faster than an octree -- octrees build fast but traverse (comparably, it's still an exponential improvement over nothing) slow.

As for actually helping the cache cohere, the main thing to bear in mind is that packing data into minimal space matters. Rays will either cohere or not depending on the scene (usually not, in path tracing at least) and not much can be done about that. However, using an octree that takes 8 bytes of storage per node instead of 32 bytes means fitting 4 times as much of it in cache and that makes cache hits during traversal correspondingly more likely. This is also why texture compression (or at least not storing all textures as HDR floats because now you can) is still relevant when working with 40 GB of RAM on a render cluster rather than what happens to be available on some guy's GPU.

_{Aside: we actually have a couple of billion-triangle scenes that take up 40 GB of RAM at work. Industrial design people: they really like their tiny details.}

SAHChandler posted:

Use enums for everything!

code:

enum class which {
  one,
  two,
  three
}

void cxx11_owns (which) { }

int main () {
  cxx11_owns(which::one);
}

Wait a second.

ratbert90 posted:

Why can't people just use enums and call it good? Just ignore the vast libraries that make life easy for you in C++!

MrMoo posted:

That's why Google added sqlite3_close_v2() .

Ephphatha posted:

I was using enums, then I needed to associate a string with an enum value for human readable file I/O...

<snip>

(If anyone knows of a better way I'm all ears)

That Turkey Story posted:

Just have to_string and from_string functions for the enum and/or overload stream extraction and insertion operators -- no need for a separate type to encapsulate it. Also, old-style exception specifications are deprecated, use noexcept specifications instead.

hooah posted:

I'm having more problems similar to ones I had before. Making a new class "student", with private data my_name, my_qualityPoints, and my_credits. Most of the errors I'm getting are while MSVC is compiling student.cpp. The first is "iostream(10): error C2143: syntax error : missing ';' before 'namespace'". I get four "syntax : identifier 'my_credits'" errors when referencing my_credits in the following function header (but not in other locations):

code:

string student::standing() const
{
	if my_credits>=90.0
		return "Senior";
	if my_credits>=60.0
		return "Junior";
	if my_credits>=30.0
		return "Sophomore";
	if my_credits<30.0
		return "Freshman";
}

The last error comes when compiling the test driver program, and it's saying it can't find a header file again. I've made sure I only have one copy of the relevant .h and .cpp files for this particular header, and they're included in the project.

Any help with any of these?

hooah posted:

Edit: Turns out I had the wrong grid.cpp file File locating is apparently going to be the bane of my existence with coding.

BirdOfPlay posted:

Also,


Umm, how do and why would you have multiple copies of the same file floating around? this is something that you should correct.

Jabor posted:

You're probably going to get a bunch of false positives from stuff that's lazy-initialized but is essentially supposed to persist for the life of the process.

One thing you could try is to run the test once, take a snapshot, and then run the test again and take another snapshot - anything new in between those two snapshots is more likely to be an actual leak than just lazy initialization or whatever.

Rocko Bonaparte posted:

I assume you mean I could diff a snapshot between a run I thought was okay versus a later one for the sake of nailing down regressions. I can't imagine if I was running the test for the first time that I'd necessarily nail any leaks that already happened. I'm just trying to understand the implications of what you wrote. I guess it confirms what I suspected; one can normally expect little bits and pieces like that.