Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 19 May 2008
Online Last Active Today, 04:52 AM

#5309497 LLVM and visual studio 2013 problems (precompiled headers + windows.h))

Posted by on 05 September 2016 - 04:26 AM

No replies from any llvm users? Pity:( For something that posts good benchmarks over other compilers, it seems that people arent using it much to talk about it.

#5309362 LLVM and visual studio 2013 problems (precompiled headers + windows.h))

Posted by on 04 September 2016 - 01:33 AM

So I'm attempting to convert my project to LLVM(http://llvm.org/builds/) as the compile toolset for visual studio 2013, and I've encountered annoying problems.


One is regarding windows.h:

C:\Program Files (x86)\Windows Kits\8.1\Include\um/oaidl.h(473,30): error : cannot combine with previous 'type-name' declaration specifier

C:\Program Files (x86)\Windows Kits\8.1\Include\um/PropIdl.h(473,30): error : cannot combine with previous 'type-name' declaration specifier


both these errors point to a similar line of code:



I've commented them out for the time being(not advisable since it's a windows sdk file) since I can't find any other answer on this. If someone has a better solution to this it would be great.


The other is regarding precompiled headers, the current toolset isn't translating the precompiled header settings at all. According to http://clang.llvm.org/docs/UsersManual.html#usersmanual-precompiled-headers, you should be able to do it but I'm wondering where to insert that build command within visual studio's build settings.


Also, if you can, please tell me about the current state of llvm-clang on visual studio 2015 at all, and whether it's an actual improvement over microsoft's compile toolset. I might consider upgrading to it.



#5285957 Why learn STL library

Posted by on 08 April 2016 - 10:55 PM

You should learn it because its The Right Way* to write code in C++ -- You should write std::vector almost every time you want dynamic memory, you should write std::unique_ptr every time you have a pointer who's contents are owned by a single entity, you should be using the standard algorithms wherever you can and not writing raw loops, you should be using std::move, and countless other examples.


I'd put that 'Right Way' quote on hold; much of the STL is full of performance dangers that will set you back one day when you're writing production code.



Here's some stl stuff I'd recommend that you should most definitely avoid:

- std::stringstream: known to have performance implications, also has terrible syntax. use snprintf instead (it has better syntax too)

- std::fstream: same as above. use c-style apis fopen, etc instead

- data structures other than std::vector: this is always kind of a newbie trap. using things like std::map over a vector can have a performance impact due to the count of cache misses you get from using that data structure.

- smart_ptr/weak_ref family: I find these to be syntactic sugar that gets in the way of implementing what you really want. One day, you'll find out that there's an allocation smart_ptr makes that kills performance, so you'll need to make an allocator, which is yet more work. Or you might get a crash from incorrect use of the api.

#5280111 Having problems with 3D pipeline

Posted by on 07 March 2016 - 10:53 PM

As you say, world space is too early, I neglected to say that in my toy system the transform from world to camera space is the identity matrix, so they're the same thing really.

Would projection make a poly that is facing away from you warp around so that it could then be facing you or vice versa though? Intuitively I didnt think projection would do that?


It depends on the projection matrix that you provide, but in general if you're using the usual orthogonal/perspective cameras no.


It might help to think about different spaces as different coordinate systems or "different views of perspective" rather than thinking that transforms 'move' or 'rotate' your objects.

First, you have a cube in model space coordinates. When you apply the model to world transform(known by many as the world transform), you get a cube in world space coordinates. The world transform takes the cube in model space to world space. Apply the same logic for the world to camera(known as the view) transform, and the projection transform, which takes the world from view space coordinates to normalized device coordinates(imagine a -1 to 1 box). From that -1 to 1 box you can scale it up to whatever your window size is.


Backface culling can be applied even after projecting the triangle points on your 2d viewport. In fact, since you have only 2d coordinates to bother about, it's much simpler to do backface culling in that 2d space compared to a 3d world space.

#5260058 CMake Made East

Posted by on 01 November 2015 - 09:48 PM

And this is why everyone should just say No to CMake. tongue.png

When you need a generator for you build system generator, the latter has utterly failed at its one job.

Your work is good, I'm not disparaging that! Just the over-hyped pile of garbage that is CMake. smile.png

What would you recommend for this then?