-1

Is auto universal and works with any API, or i am not using it correctly i guess should be work in this case but error, if i shall change it with concrete type will work, but why ?

//  Set  vertex  buffer
auto  stride = m_FullScreenVTFTonemapPass.stride;
auto  offset = m_FullScreenVTFTonemapPass.offset;
m_pD3DDevice->IASetInputLayout( m_FullScreenVTFTonemapPass.IALayout );
m_pD3DDevice->IASetVertexBuffers ( 0, 1, &m_FullScreenVTFTonemapPass.VBdata, &stride, &offset );
m_pD3DDevice->IASetPrimitiveTopology( D3D10_PRIMITIVE_TOPOLOGY_TRIANGLESTRIP );

in IASetVertexBuffers() function stride and offset should be referenced but errors are popping up , if i'll change one of them stride or offset with UINT it works but why auto does not work ?!

Achiko Mezvrishvili
  • 226
  • 1
  • 12
  • 1
    It would be very helpful if you could tell us *what* "errors are popping up". In your editor? When building? When running? What is `m_FullScreenVTFTonemapPass.stride` and `m_FullScreenVTFTonemapPass.offset` supposed to be for types? What happens if you pass pointers to these members insteadof using the local variables? – Some programmer dude Mar 05 '16 at 07:21
  • @Achiko Mezvrishvili It is obvious that there is some type inconsistence and the error message should point it out. So read the error message. – Vlad from Moscow Mar 05 '16 at 07:30
  • 1
    `IASetVertexBuffers` wants `UINT*` for both of those parameters, but (assuming `m_FullScreenVTFTonemapPass` is an instance of [PostFXFSQuad](https://searchcode.com/codesearch/view/63809468/), both those variables are of type `int`. – Jonathan Potter Mar 05 '16 at 07:38
  • @JonathanPotter Yeah my mistake :). IASetVertexBuffer() needs two UINT* params not simple integers and auto returned simple integers from PostFXQuad and IASetVertexBuffer() method was throwing error about casting from simple integer to UINT* :). Thanks. – Achiko Mezvrishvili Mar 05 '16 at 09:44
  • Omitting the exact error message you get is a disservice to the programming community. You know what people usually do first when they encounter a strange error message they don't understand? Copy and paste it into Google, hoping that a good Stackoverflow answer will pop up in the results. This obviously only works if the error message appears in the question. – Christian Hackl Mar 05 '16 at 09:48

3 Answers3

1

I have solved the issue was IASetVertexBuffer() needs two UINT parameters and my auto declaration was getting two simple integer(stride, offset) that was an error. IASetVertexBuffer() couldn't cast from int to UINT* parameters. That's it.

auto  stride = quad->stride;
auto  offset = quad->offset;
m_pD3DDevice->IASetInputLayout( quad->IALayout );
m_pD3DDevice->IASetVertexBuffers(0, 1, &quad->VBdata, (UINT*)&stride, (UINT*)&offset);
m_pD3DDevice->IASetPrimitiveTopology( D3D10_PRIMITIVE_TOPOLOGY_TRIANGLESTRIP );

P.S. Anyway if i will insist to use auto then i will cast those values stride and offset with (UINT*) and that's it. Works without a problem.

Achiko Mezvrishvili
  • 226
  • 1
  • 12
  • 1
    Using `auto` in this case seems pointless; why not just do `UINT stride = quad->stride;` instead? – Jonathan Potter Mar 05 '16 at 12:42
  • @JonathanPotter I think actually auto in general in C++ is pointless and in Win API, this is my personal opinion. In C#(CSHARP) var works best but in C++ it is a better to declare specific type exactly , either way in Win api u have to do a lot of casting sometimes. in C++ auto is handy when u exactly know what kind of value u will get though. – Achiko Mezvrishvili Mar 05 '16 at 13:51
  • auto is very useful for some things, e.g. iterators. – Jonathan Potter Mar 05 '16 at 13:56
  • Might be in STL when you are iterating through containers.(map, vector etc). – Achiko Mezvrishvili Mar 05 '16 at 13:58
  • 1
    At least go with ``reinterpret_cast(&stride), reinterpret_cast(&offset));`` I'm generally a fan of ``auto``, but I think in this case you are not using it well because your data structure has scalar values while the API expects to take an array. In this case ``UINT strides[1] = { quad->stride }; UINT offsets[] = { quad->offset };`` is probably clearer and more correct. – Chuck Walbourn Mar 07 '16 at 06:44
  • FWIW, I'd probably go with: ``auto stride = static_cast(quad->stride); auto offset = static_cast(quad->offset);`` In general I like ``auto`` anywhere you basically have the same information on the LHS and RHS. – Chuck Walbourn Sep 20 '22 at 05:57
0

Use auto for iterators and loops only. In my opinion using auto is a bad habit.

If you'll visit your code days or weeks later, you will hate yourself for using auto at every possible variable. And if there is a other coder who have to read your code try to avoid it completely.

In your special case? What do you thing will be better when using auto here? UINT and auto has both 4 letters, so lazyness can't be the reason. If you're looking at your code and you see a UINT you will immediatly know what type the variable is.

kaiser
  • 940
  • 1
  • 10
  • 25
  • ``auto`` is IMO most useful anywhere the type is already explicitly listed such as cast statements; ``auto p = reinterpret_cast(data);``. It's also very useful where the specific type isn't critical and use is obvious by context: ``auto device = m_deviceResources->GetDirect3DDevice(); device->IASetInputLayout(...);``. Most of the crazy uses of ``auto`` are there only for the Standard Library and template metaprogramming... – Chuck Walbourn Jan 26 '18 at 17:41
-1

auto is not a type definition but a storage class (like static).

The compiler complains because you have told it how and where (in this case, on the stack) to store something, but not what the something should be.

You should add the type definition after the auto keyword, or as auto is the default anyways, replace it with the proper type.

UNIT stride = ......
tofro
  • 5,640
  • 14
  • 31