Post the code written by you thread. :D

[-Ashe-]

Originally Posted by Fadingz

code snippet to do asynchronous kernel calls and memory writes in cuda c++ using the thrust library:

What does the triple <<< >>> do?
edit: nvm just looked it up

---

Last edited by -Ashe-; November 29th, 2011 at 20:20..

[Fadingz]

The main down side of cuda is that the code looks fugly lol

__________________

[Fadingz]

more #define and typedef lol:
Think I made the code a lot more readable.

    int len = length - 6;
    d_bool d_isTaken(len, false);
    d_keyframes = d_uint(len);
    
    cudaStream_t stream1, stream2;
    cudaStreamCreate(&stream1);
    cudaStreamCreate(&stream2);
    
    d_x_odd = d_float(odd);
    d_x_even = d_float(even);
    d_y_odd = d_float(odd);
    d_y_even = d_float(even);
    
    async_cpy(d_x_odd, h_x_odd, f_odd, stream1);
    async_cpy(d_y_odd, h_y_odd, f_odd, stream2);
    ComputeJerk<<<gridSize,blockSize,0,stream2>>>
        (d_ptr(d_x_odd), d_ptr(d_y_odd), length, joints, d_ptr(d_isTaken), Tol, make_float2(MultPos, MultRot), true);
    
    async_cpy(d_x_even, h_x_even, f_even, stream1);
    async_cpy(d_y_even, h_y_even, f_even, stream2);
    ComputeJerk<<<gridSize,blockSize,0,stream2>>>
        (d_ptr(d_x_even), d_ptr(d_y_even), length, joints, d_ptr(d_isTaken), Tol, make_float2(MultPos, MultRot), false);
    
    d_keyframes.resize(thrust::copy_if(c_iter(0),
                                       c_iter((int)length - 6),
                                       d_isTaken.begin(),
                                       d_keyframes.begin(),
                                       thrust::identity<bool>()) -
                       d_keyframes.begin());
    h_keyframes = d_keyframes;

#define d_ptr(d) thrust::raw_pointer_cast(&d[0])
#define async_cpy(d, h, l, stream) cudaMemcpyAsync(d_ptr(d), h, l, cudaMemcpyHostToDevice, stream)
#define c_iter(n) thrust::make_counting_iterator(n)

    typedef thrust::device_vector<bool> d_bool;
    typedef thrust::host_vector<unsigned int> h_uint;
    typedef thrust::device_vector<unsigned int> d_uint;
    typedef thrust::host_vector<float> h_float;
    typedef thrust::device_vector<float> d_float;

__________________

[cottonvibes]

Originally Posted by -Ashe-

Also, you can't do what I mentioned with C-style casts for a simple reason: static_cast and reinterpret_cast do different things, try doing two different things with the same syntax...

yes obviously they do different things, or else they wouldn't be distinct cast operators.
but you can do both their behaviors using only C-style casts.

take a look at this:

struct ST0 { int x; };
struct ST1 { int y; };
struct ST2 : ST1, ST0 { int z; };

int main() {
    ST2* ptr = new ST2;

    // Static Casts:
    ST0* sc0 = static_cast<ST0*>(ptr);
    ST1* sc1 = static_cast<ST1*>(ptr);

    // Same As: 
    ST0* sc0 = (ST0*)ptr;
    ST1* sc1 = (ST1*)ptr;

// ----------------------------

    // Reinterpret Casts:
    ST0* rc0 = reinterpret_cast<ST0*>(ptr);
    ST1* rc1 = reinterpret_cast<ST1*>(ptr);
    
    // Same As: 
    ST0* rc0 = (ST0*)(void*)ptr;
    ST1* rc1 = (ST1*)(void*)ptr;
}

the c-style equivalents are clearer imo because they're less verbose.

btw i'm not saying you should never use c++ casting operators, within templates you might want to use them as you showed.

however in c++03 when you're not dealing with templates you pretty much always know what types you're dealing with, so using c++ casts are something i never really use (and i don't see them used much in the projects i've worked on).

with c++0x/c++11 we have the introduction of auto/decltype which will make code harder to know what types you're dealing with. so using c++ casts with those types might be more clear.
i fear for the obfuscation that c++0x will cause.

__________________

"It was, of course, a lie what you read about my religious convictions, a lie which is being systematically repeated. I do not believe in a personal God and I have never denied this but have expressed it clearly. If something is in me which can be called religious then it is the unbounded admiration for the structure of the world so far as our science can reveal it." - Albert Einstein
check out my blog

[-Ashe-]

Using two casts is cheating, you know
But if you prefer the C ones, why not, I was just speaking of the rationale behind using the C++ ones...
As a "counter"-example (counter because I prefer the C++ casts), I don't really like iostreams - because those are really super-verbose when you start using iomanip's - but still end up using them because of the extensibility/type safety... even though I usually know their type and rarely extend them anyway
But I guess with time I just got used to them
edit: as for projects, in the past 10 years, I don't remember seeing any project that didn't have a ban on C-style casts in their guidelines

[cottonvibes]

the projects you've worked on must be very anti-C then.
completely banning c-style casts sounds ridiculous.
so even in trivial cases where you're casting between primitive types (like from double to int) they'll make you use static_cast instead of c-style casts?

btw i don't consider using 2 c-style casts cheating as the point was its possible to do it w/o using c++ casts, but even with that restriction its still possible to do it:

struct ST0 { int x; };
struct ST1 { int y; };
struct ST2 : ST1, ST0 { int z; };

int main() {
    ST2* ptr = new ST2;

    // Reinterpret Casts:
    ST0* rc0 = reinterpret_cast<ST0*>(ptr);
    ST1* rc1 = reinterpret_cast<ST1*>(ptr);
    
    // Same As: 
    ST0* rc0 = (ST0*&)ptr;
    ST1* rc1 = (ST1*&)ptr;
}

__________________

"It was, of course, a lie what you read about my religious convictions, a lie which is being systematically repeated. I do not believe in a personal God and I have never denied this but have expressed it clearly. If something is in me which can be called religious then it is the unbounded admiration for the structure of the world so far as our science can reveal it." - Albert Einstein
check out my blog

[-Ashe-]

Originally Posted by cottonvibes

the projects you've worked on must be very anti-C then.
completely banning c-style casts sounds ridiculous.

Not anti-C, just anti-common-mistakes
(it's also to make sure the code is consistent, which is useful when 300 different people work on the codebase)

[cottonvibes]

i'm pretty sure i've never had a mistake due to accidental improper use of c-style casts, which the compiler didn't give an error on.
c-style casts already give errors on common mistakes...

can you give an example of a mistake that would work with c-style casts, but prevented with c++ casts?

__________________

"It was, of course, a lie what you read about my religious convictions, a lie which is being systematically repeated. I do not believe in a personal God and I have never denied this but have expressed it clearly. If something is in me which can be called religious then it is the unbounded admiration for the structure of the world so far as our science can reveal it." - Albert Einstein
check out my blog

[-Ashe-]

Assigning a T1* to a completely unrelated T2* (but sure, as you mentioned before, this is mostly useful in templates... but then a lot of code ends up being templated heheh; and because you never had an issue doesn't mean other people won't, many developers don't understand half of what they type, a C-style cast is a powerful weapon to just be happy the code compiles, even when it's incorrect)
The C-style cast is more like giving an order to just ignore pretty much every rule to your compiler

As for projects/etc:
http://google-styleguide.googlecode....de.xml#Casting
http://www2.research.att.com/~bs/bs_...ml#static-cast

Anyway it's common knowledge, while what you mention is just style preference, similar to where you end up using {, where to place spaces or using tabs vs spaces...

In the end I tend to use bitmasks instead of static_cast (except for float to int and similar, obviously) and pretty much only use reinterpret_cast (or very rarely const_cast) for some winapi functions that take odd argument types... Otherwise casts are pretty much useless (but I'd rather be able to search for them and quickly see what they do )

[cottonvibes]

Originally Posted by -Ashe-

In the end I tend to use bitmasks instead of static_cast (except for float to int and similar, obviously)

i don't understand, how are bitmasks a substitute for static_cast?

__________________

"It was, of course, a lie what you read about my religious convictions, a lie which is being systematically repeated. I do not believe in a personal God and I have never denied this but have expressed it clearly. If something is in me which can be called religious then it is the unbounded admiration for the structure of the world so far as our science can reveal it." - Albert Einstein
check out my blog

[-Ashe-]

Say you go from a 4-byte uint to a 2-byte ushort:
us = ui & 0xffff;
vs
us = static_cast<ushort>(ui);
(yeah I use the maximum warning level + warning as error so I can't just leave it like that)
But that's mostly because when I do those assignments it's generally when reading from files and such, otherwise the types are consistent pretty much in every function calls so there's no need to cast...

[Fadingz]

I use c casing all the time for polymorphism

a funny trend sightly off the track:
for the past 30 years or so, we've been trying to make the code as easy to code as possible for developers, even with performance as sacrifice.
Recently, we been throwing functionality and performance into development tools, even with the mean of possible broken and/or unreadable code. For instance, multi-threading.

__________________

[-Ashe-]

Hm why would you need to cast for polymorphism?

[cottonvibes]

Originally Posted by -Ashe-

Say you go from a 4-byte uint to a 2-byte ushort:
us = ui & 0xffff;
vs
us = static_cast<ushort>(ui);
(yeah I use the maximum warning level + warning as error so I can't just leave it like that)
But that's mostly because when I do those assignments it's generally when reading from files and such, otherwise the types are consistent pretty much in every function calls so there's no need to cast...

technically the above is not casting (as the result is still an int or larger), although it is enough to get rid of warnings about truncation.

consider the following:

void foo(unsigned short s) { cout << "u16 "; }
void foo(unsigned int i) { cout << "u32 "; }
int main() {
    unsigned int u = 0x7fffffff;
    foo(u);
    foo(u&0xffff);
    foo((unsigned short)u);
}
output: u32 u32 u16

here's another interesting example:

int main() {
    char c = 1;
    auto a = 1 & 1;
    cout << sizeof(a);
}
output: 4 (on architectures with 32bit int)

__________________

"It was, of course, a lie what you read about my religious convictions, a lie which is being systematically repeated. I do not believe in a personal God and I have never denied this but have expressed it clearly. If something is in me which can be called religious then it is the unbounded admiration for the structure of the world so far as our science can reveal it." - Albert Einstein
check out my blog

[-Ashe-]

I know it's not casting, since I say "I use this instead of casting"

[Exophase]

I don't like that the compiler stops warning you based on a code optimization. Turn optimization level down and maybe that warning will come back! If you're concerned about making truncations clear I'd stick with the cast.

[-Ashe-]

Originally Posted by Exophase

I don't like that the compiler stops warning you based on a code optimization. Turn optimization level down and maybe that warning will come back! If you're concerned about making truncations clear I'd stick with the cast.

Hm hadn't thought of that, maybe I'll switch to static_cast

[cottonvibes]

Originally Posted by Exophase

I don't like that the compiler stops warning you based on a code optimization. Turn optimization level down and maybe that warning will come back! If you're concerned about making truncations clear I'd stick with the cast.

why do you want it to warn you if it can detect at compile-time that the variable will fit in the desired range w/o truncation?
afaik its not about optimization in this case, its that the compiler is smart enough to know through static analysis that (x & 0xffff) will fit in the range of an unsigned int with 16 bits, so it doesn't need to warn you about potential loss of information through truncation, because it knows it can't happen.

__________________

"It was, of course, a lie what you read about my religious convictions, a lie which is being systematically repeated. I do not believe in a personal God and I have never denied this but have expressed it clearly. If something is in me which can be called religious then it is the unbounded admiration for the structure of the world so far as our science can reveal it." - Albert Einstein
check out my blog

[cottonvibes]

Originally Posted by -Ashe-

Hm why would you need to cast for polymorphism?

well you could want to use one of the superclasses' methods that are hidden due to derived classes.

__________________

"It was, of course, a lie what you read about my religious convictions, a lie which is being systematically repeated. I do not believe in a personal God and I have never denied this but have expressed it clearly. If something is in me which can be called religious then it is the unbounded admiration for the structure of the world so far as our science can reveal it." - Albert Einstein
check out my blog

[blueshogun96]

Originally Posted by cottonvibes

c++ has a lot of nice features that c doesn't have to make code clearer and more optimal.
references being a key feature that makes code much nicer than the c-way of throwing pointers around everywhere.

coding c-like with the useful features of c++ is how i like to do things. there's no reason to code pure C, its just limiting yourself and makes for worse-code (the reason you have to use so much macros in C is because it lacks too many features).

I agree and disagree at the same time. C++ has some useful features, but using pure C does not limit yourself. As long as you're a good coder, it shouldn't matter which one you use, and a good coder can write good C code no problem without the need for all the extra stuff. I've seen FAR more bad C++ usage then bad C usage to date.

__________________

Official Website of Shogun3D's RyuAwai!

Shogun3D Game Development Blog

Zengjük a Dalt: Manliest Song Ever!