Why auto instead of int? (Crbegin, crend)

[vast hornet]

Why do I need to use an auto instead of an int, is it becuase the return type for crbegin isn't int?

[dusky oyster]

When your question is answered use !solved to mark the question as resolved.

Remember to ask specific questions, provide necessary details, and reduce your question to its simplest form. For tips on how to ask a good question use !howto ask.

@vast hornet

Screenshots!

Your message appears to contain screenshots but no code. Please send code and error messages in text instead of screenshots if applicable!

[velvet stirrup]

crbegin does not result in an int

it results in an iterator

[graceful sigil]

auto is frequently used for iterator variables

[velvet stirrup]

specifically std::string::const_reverse_iterator

[vast hornet]

Okay, I just saw that. one more moment, question on this is going to pop up

how can I state reverse iterator, or am I not allowed to do that?

becasue I have iterator within the include tags now.

[velvet stirrup]

wdym by that

#include<iterator>?

[autumn lichen]

!cppref std::reverse_iterator

[dusky oyster]

cppreference.com

std::reverse_iterator

template<class Iter>
class reverse_iterator;

Defined in

<iterator>

[autumn lichen]

So #include <iterator> is fine

[vast hornet]

Ohh okay, I thought it was going to want me to use const_reverse_iterator

[velvet stirrup]

if you do std::string::const_reverse_iterator i=... that will work

[vast hornet]

instead of just a normal one.

[velvet stirrup]

btw putting a semicolon after main isn't necessary, and same for the parentheses with return

[vast hornet]

Okay, also why can this work with normal reverse iterator and const reverse iterator? I'm gussing inheratance?

[velvet stirrup]

wdym

[vast hornet]

I can use const_reverse_iter

and reverse_iter

[velvet stirrup]

for the type of i?

[vast hornet]

yes

[velvet stirrup]

;compile cpp std::string s; std::string::reverse_iterator i=s.crbegin();

[trim nexus]

Compiler Output

In file included from /opt/compiler-explorer/gcc-14.1.0/include/c++/14.1.0/cassert:43,
                 from /opt/compiler-explorer/gcc-14.1.0/include/c++/14.1.0/x86_64-linux-gnu/bits/stdc++.h:33,
                 from <source>:1:
/opt/compiler-explorer/gcc-14.1.0/include/c++/14.1.0/bits/stl_iterator.h: In instantiation of 'constexpr std::reverse_iterator<_Iterator>::reverse_iterator(const std::reverse_iterator<_Iter>&) [with _Iter = __gnu_cxx::__normal_iterator<const char*, std::__cxx11::basic_string<char> >; _Iterator = __gnu_cxx::__normal_iterator<char*, std::__cxx11::basic_string<char> >]':
<source>:5:43:   required from here
    5 | std::string::reverse_iterator i=s.crbegin();
      |                                           ^
/opt/compiler-explorer/gcc-14.1.0/include/c++/14.1.0/bits/stl_iterator.h:216:9: error: no matching function for call to '__gnu_cxx::__normal_iterator<char*, std::__cxx11::basic_string<char> >::__normal_iterator(const __gnu_cxx::__normal_iterator<const ch

halalaluyafail3 | c++ | x86-64 gcc 14.1 | godbolt.org

[velvet stirrup]

doesn't seem to work

[vast hornet]

One moment I can show

[velvet stirrup]

std::reverse_iterator not std::string::reverse_iterator ok

big difference there

[vast hornet]

okay, my bad on that. but are you able to explain why it's allowed?

or should I just avoid doing something out of the library intentions in general

[velvet stirrup]

std::reverse_iterator i=test.crbegin() is creating an object of type std::string::const_reverse_iterator

[velvet stirrup]

it's deducing the template arguments for the template std::reverse_iterator

[vast hornet]

ohhh okay, so metaprogramming.

I understand, thanks for the expo and help today!

[velvet stirrup]

and the result of test.crbegin() is std::reverse_iterator<std::string::const_iterator>

so it sees that the input is a reverse iterator already, and it just uses the same type

[shrewd goblet]

i see that its already been explained

[vast hornet]

I thought that would only be a const_reverse_iterator also

[velvet stirrup]

if you try to assign to *i you should see that it is a const iterator

[shrewd goblet]

general rule of thumb is to use "auto" when doing range loops, or when you're trying to use an iterator as it makes code readable.
You can technically write out the entire type that you're using, but it's not friendly to see.
An int would be used if you're iterating over integers. But a reverse iterator is not at all similar to a int. Two completely different types/objects

so if you wanted to do

[vast hornet]

and that's due to the template, so it's justusing that const_iterator template if I am setting it to i

[vast hornet]

Also, yeah I see what you mean

[velvet stirrup]

yes

[shrewd goblet]

!f

[dusky oyster]

!f

int main() {
  std::string test = "Hello";
  for (int i = test.size() - 1; i >= 0; --i) {
    std::cout << i << " ";
  }
  return 0;
}

Pierre

[shrewd goblet]

this is essentially the same thing as what you orignially intended

but with the use of ints

[velvet stirrup]

should use std::size_t not int for the loop preferably

[vast hornet]

okay, but that was just for the I situation. aka the template metaprogramming because I shoved in just a normal reverse iter

[velvet stirrup]

since that is what test.size() results in

[vast hornet]

Looking

[shrewd goblet]

that's true, but i wanted to show him an example of it in an int, even if i broke some standards doing so lol

[vast hornet]

Std::size_type right?

[velvet stirrup]

yes

btw prefer cppreference

cplusplus.com is not as good from what I've seen

[shrewd goblet]

i started with cplusplus, but cppref is much better once you get used to it

[shrewd goblet]

another reason why "auto" is preferable in this case. Prevents user error from happening; the compiler knows what the type should be

[vast hornet]

@velvet stirrup on cpp refrence where is the return value? as in the outright stated return?

oeither one of you

[vast hornet]

I must be looking at the wrong thing one sec

[shrewd goblet]

return value of what?

std::string::size()?

[vast hornet]

okay, yeah I found the right one. thanks foor all the help guys!

also @shrewd goblet yeah

and why is it being called basic string?

[velvet stirrup]

because std::string is just a specific specialization of std::basic_string

[vast hornet]

oka ythanks

!solved