Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 23 Oct 2011
Offline Last Active Aug 26 2012 08:03 PM

#4973483 Visual Studio 2012 ruined everything

Posted by Triangles-PCT on 26 August 2012 - 09:10 AM

Install vs2012 and fix the problems. D3D is now part of the windows SDK.

#4902624 Calculating Normals From Displacment

Posted by Triangles-PCT on 14 January 2012 - 05:49 AM

Does the spherical coordinates for normal mapping work? Do you have to do point sampling?

Not saying it doesn't work, cause I haven't tried it, but wouldn't bi linear interpolation cause some odd artifacts, since it would take the long route around the sphere if say you had coordinate -1 next to coordinate 1.

#4890577 C++ header only style

Posted by Triangles-PCT on 04 December 2011 - 09:58 PM

I hate the way C++ uses separate interface and implementation files, so I decided to try a little experiment to see if it might be possible to just use headers.

Testing to see if using a header only approach to C++ has any benefits, by this I mean that each project would only have 1 .cpp file, everything else goes in headers.

All tests done with Visual Studio 2010

Code includes use of many templates, STL, boost, and TBB(lots of templates).

LTGC is on for release built, along with comdat folding

/MP is also enabled for all builds, although in header only world it doesn't do much(anything?)

Using CPP files: size: release = 375,296 bytes debug = 1,856,512 bytes
Using header only: size: release = 375,296 bytes debug = 1,856,512 bytes

So using 1 CPP, instead of many, made no difference to exe size

Full Build Times Release:

CPP Header:
1)33.74 1) 18.17
2)33.79 2) 18.02
3)33.48 3) 18.44

Full Build Times Debug:
CPP Header:
1) 24.65 1) 12.47
2) 25.16 2) 12.11
3) 24.80 3) 11.76

Full rebuilds are much faster under header only, and this is with /MP(multithreaded builds) enabled(8 cores) which favors having extra .cpp to split up the work

Partial Rebuild Release:
1)16.18 <-- changed 1 line in 1 cpp
2)25.81 <-- changed 1 line in random .h
3) 13.66 <--- changed 1 line in a different cpp

Can't do partial rebuilds with header only, but full rebuilds with header only are comparable to partial rebuilds with CPP's time wise. Partial rebuilds heavily depend on exactly what was changed

Partial Rebuild Debug
1) 19.06 <-- changed random header by 1 line
2) 3.32 <-- changed a line in 1 cpp
3) 16.62 <-- changed a line in another random .h

The code was all originally written using .cpp/.h combo as traditional C++. To switch to header only I just copied the contents of each .cpp under the contents of the .h and then removed the .cpp from the project.

After I had finished this I only had one compiler error which resulted from two objects which both made use of each other. One by value and one by reference.

I fixed this by splitting the class which used the other by reference into two headers, the .h as it had already existed, and contents of its .cpp moved into a .hpp and included in a header called "circular.hpp" which is then included in the one and only .cpp(main.cpp).

+ could probably also just rename all .cpp to .hpp and add them to circular.hpp or some such which is included in main.cpp, but this keeps those extra files around...

I had expected it to decrease the size of the .exe(or at least change it) since I've heard of other people doing similar things to create more optimized builds, and of course people crying about template bloat. That didn't happen though.

Built times are better in many cases, slower in others. I could see the header only approach not working so well with a giant project as it pretty much results in constant time builds which grow linearly with the # of files.

Of course changing a header in a giant C++ project can result in a nightmare rebuild...

Perhaps the best way would be header only, but split into multiple projects, so that not everything must always be remade?

Overall Header Only:
+faster worst case build times(changing a header)
+simpler build process
+can place code right in the class itself, like in most modern languages
+less files to deal with
+less worrying about forward declaring to avoid excess header includes and PIMPL pattern
+only one translation unit so warnings/errors in headers are seen once(less spam)
+can write functions in header without being forced to "inline" them (normally this results in multiple definitions error but with only one translation unit, no such problem)
+on older compilers that don't have link time code gen, should be more optimal?

-best case build times are slower(changing cpp)
-might not scale too well? not sure here, might be easy to work around this with multiple projects

I think I am going to start doing this with all of my code, and port my existing code over to this approach..

Does anyone have any experience with this, or know of any problems I missed with this approach?

C++ needs a module system:(

#4889215 School? I would not call it that way.

Posted by Triangles-PCT on 30 November 2011 - 04:16 PM

At least your high school has CS classes ... mine had a typing class which used 15 year old computers, and that was canceled after my freshman year.

Most CS teachers suck, but then again lots of programmers suck too.

imo any good programmer learned most of what they know on their own, school is like the first 20%

#4888195 Heap Management

Posted by Triangles-PCT on 27 November 2011 - 02:28 PM

Not sure how much I believe that comment. I've downloaded and tested various so-called fast allocators(Nedmalloc etc.) claiming that they outperform microsofts, and every time I actually tested it, the MS allocator was the fastest.

The OS seemed to matter somewhat here, as MS allocator under XP didn't always win, but under Vista/Windows 7 it fairly well destroyed the others(I believe the default under Vista+ is low frag).