on the one that doesnt work i get the following error:
error C2440: 'static_cast' : cannot convert from 'drone::scene::StateReadWriteBuffer::Assoc' to 'std::map<_Kty,_Ty> &'
but i dont see what the differance is between the two?
how do i fix this?
here is the full source

Share this post

Link to post

Share on other sites

"but i dont see what the differance is between the two?"I think inherit_linearly does something like that:class root{}class a: public root,t0{}class b: public a,t1{}class c: public b,t2{}...and returns last in sequence. You cant inherit from all at once in template.

"if u have any suggestion on how i can make the code more readable please tell..."Keep it simple. Your code, from what I can see, actually does almost nothing. Why do you need that strange multiple inheritance abuse? When core code has to know all types (Camera, Geometry, Material, Mesh...) , that means there is too much coupling between core code and those . Core code shouldn't know it, and should not be changed when you add one more type.

Boost is good for two things: wasting a lot of time on even the most trivial problems, and writing a lot of code that looks impressive, generic, and complicated but actually does very little and is very unflexible. And I'm being generous; some would say that it is just 2 facets of one thing. There is very few useful things in boost; and generally very few professional projects use advanced features of boost (I am excluding those projects that do not complete, counting only those that were deployed / generated revenue).

Look, this thread makes second result in google search for inherit_linearly, and first is the documentation. This should be quite good indicator of (lack of) usefulness of inherit_linearly.

For productive metaprogramming, you need programming language that does actually support metaprogramming (preferably using roughly same syntax for compile-time type expressions as for runtime code), not language which, by historical accident, happens to have turing complete macro-ish system never intended for anything but the most rudimentary metaprogramming, and lacking even the most rudimentary ability to locate bugs in "meta programs".

0

Share this post

Link to post

Share on other sites

Original post by Dmytry"but i dont see what the differance is between the two?"I think inherit_linearly does something like that:class root{}class a: public root,t0{}class b: public a,t1{}class c: public b,t2{}...and returns last in sequence. You cant inherit from all at once in template.

"if u have any suggestion on how i can make the code more readable please tell..."Keep it simple. Your code, from what I can see, actually does almost nothing. Why do you need that strange multiple inheritance abuse? When core code has to know all types (Camera, Geometry, Material, Mesh...) , that means there is too much coupling between core code and those . Core code shouldn't know it, and should not be changed when you add one more type.

Boost is good for two things: wasting a lot of time on even the most trivial problems, and writing a lot of code that looks impressive, generic, and complicated but actually does very little and is very unflexible. And I'm being generous; some would say that it is just 2 facets of one thing. There is very few useful things in boost; and generally very few professional projects use advanced features of boost (I am excluding those projects that do not complete, counting only those that were deployed / generated revenue).

Look, this thread makes second result in google search for inherit_linearly, and first is the documentation. This should be quite good indicator of (lack of) usefulness of inherit_linearly.

For productive metaprogramming, you need programming language that does actually support metaprogramming (preferably using roughly same syntax for compile-time type expressions as for runtime code), not language which, by historical accident, happens to have turing complete macro-ish system never intended for anything but the most rudimentary metaprogramming, and lacking even the most rudimentary ability to locate bugs in "meta programs".

well after reconsidering my design i have to agree with you... my attempt to make the code shorter and with less duplication has become counter productive... ive rewritten it...