c++ iterate through a vector of strings
Asked Answered
H

5

8

So I recently discovered the use of map and vectors, however, I'm having trouble of trying to figure a way to loop through a vector containing strings.

Here's what I've tried:

#include <string>
#include <vector>
#include <stdio>

using namespace std;

void main() {
    vector<string> data={"Hello World!","Goodbye World!"};

    for (vector<string>::iterator t=data.begin(); t!=data.end(); ++t) {
        cout<<*t<<endl;
    }
}

and when I try to compile it, I get this error:

cd C:\Users\Jason\Desktop\EXB\Win32
wmake -f C:\Users\Jason\Desktop\EXB\Win32\exbint.mk -h -e
wpp386 ..\Source\exbint.cpp -i="C:\WATCOM/h;C:\WATCOM/h/nt" -w4 -e25 -zq -od    -d2 -6r -bt=nt -fo=.obj -mf -xs -xr
..\Source\exbint.cpp(59): Error! E157: col(21) left expression must be integral
..\Source\exbint.cpp(59): Note! N717: col(21) left operand type is 'std::ostream watcall (lvalue)'
..\Source\exbint.cpp(59): Note! N718: col(21) right operand type is 'std::basic_string<char,std::char_traits<char>,std::allocator<char>> (lvalue)'
Error(E42): Last command making (C:\Users\Jason\Desktop\EXB\Win32\exbint.obj) returned a bad status
Error(E02): Make execution terminated
Execution complete

I tried the same method using map and it worked. The only difference was I changed the cout line to:

cout<<t->first<<" => "<<t->last<<endl;
Hypochondriac answered 25/10, 2016 at 8:17 Comment(20)
Works for meCirrate
Completly fine. There's sometihng up with your includes or your compiler.Unicuspid
Can you provide a minimal reproducible example please. Did you miss to #include <string> eventually?Waggery
Judging by the error text, your compiler treats the << as a bitshift for some reason. The bit of code that you posted is fine, though, so the error is somewhere else.Oswaldooswalt
I've included every required library for this code. Otherwise my compiler would've returned an error on that as well. Anyways, I edited the code and gave a full example as you wished.Hypochondriac
I'm using Open Watcom since it happened to support many platforms ranging from the old DOS era to Windows & Linux (OS/2 and netware also happened to be included)Hypochondriac
You are simply missing #include <iostream>. Check the references.Supposed
add #include <iostream> and change the return type of main to int.Unicuspid
Adding iostream doesn't change anything. The error still occurred. And my actual code does return an integer from the function main, but changing that doesn't change anything either. These parts has no relations to this error I'm getting.Hypochondriac
Update your question with your current code, you can see that it should work (StoryTeller's link). If your compiler is non-compliant but the map example worked for you, try to find out how you would access the element your iterating over in t.Supposed
Your code is compliant and works perfectly well on every modern compiler. We can't help you.Unicuspid
I believe it is based on the compiler itself. But it was unexpected considering that this compiler is still pretty modern as of the latest update was from 2015. I'm going to test this in visual studio and see if things change.Hypochondriac
Your code is hardly perfectly OK, because void main and #include <stdio> are not C++! It must be int main and #include <iostream>. What's true is that your compiler is the culprit and that you should use a modern alternative like the latest VC, GCC or Clang.Mcculley
I tried to compile this in GCC as well. It also gave an error following the same line from Open Watcom.Hypochondriac
[OT]: In c++11, it can even be simplified with for range to for (const auto& s : data) { std::cout << s << std::endl; }Rick
Yes I am also aware of using auto which was implemented in c++11, unfortunately, I'm using c++98Hypochondriac
@JasonLee cpp.sh/2yigrUnicuspid
Your errors don't match the code - what you've posted doesn't even have 59 lines.Essen
That's because this code only has the parts where I have the error in. Obviously I have a much larger code. I also tried this code itself and it gave the same results. Otherwise, I don't think there is any further help since I think it is based on the compiler.Hypochondriac
Your code is fine (maybe #include <iostream>). Your problem is the compiler. Watcom is beyond salvation. Open-sourcing a 1999 product is too little, too late. Give it up. Use MSVC for DOS and Windows and GCC for Linux, OS/2 and netware.Biondo
S
12

Add iostream header file and change stdio to cstdio.

#include <iostream>
#include <string>
#include <vector>
#include <cstdio>

using namespace std;

int main() 
{
    vector<string> data={"Hello World!","Goodbye World!"};
    for (vector<string>::iterator t=data.begin(); t!=data.end(); ++t) 
    {
        cout<<*t<<endl;
    }
    return 0;
}
Saltern answered 25/10, 2016 at 9:16 Comment(0)
H
2
#include <iostream>
#include <vector>
#include <string>
 
int main()
{
   std::vector<std::string> data = {"Hello World!", "Goodbye World!"};

   for (std::vector<std::string>::iterator t = data.begin(); t != data.end(); t++) {
    std::cout << *t << std::endl;
   }

   return 0;
}

Or with C++11 (or higher):

#include <iostream>
#include <vector>
#include <string>

typedef std::vector<std::string> STRVEC;

int main()
{
    STRVEC data = {"Hello World!", "Goodbye World!"};

    for (auto &s: data) {
        std::cout << s << std::endl;
    }

    return 0;
}
Horrendous answered 21/9, 2020 at 0:49 Comment(0)
S
1

From the Open Watcom V2 Fork-Wiki on the C++ Library Status page:

<string>

Mostly complete. Although there are no I/O operators, all other member functions and string operations are available.

A workaround (besides implementing the << operator) would be asking the string instances for the C string:

for (vector<string>::iterator t = data.begin(); t != data.end(); ++t) {
    cout << t->c_str() << endl;
}

This of course only works as long as the strings don't contain zero byte values.

Selachian answered 31/12, 2017 at 17:37 Comment(0)
E
0

When I compile your code, I get:

40234801.cpp:3:17: fatal error: stdio: No such file or directory
 #include <stdio>
                 ^

You clearly have a header called "stdio" in your include path that you haven't shown us.

If you change that line to the standard #include <iostream>, then the only reported error is that you wrote void main() instead of int main(). Fix that, and it will build and run.

In passing, note also that using namespace should be avoided.

Essen answered 25/10, 2016 at 14:37 Comment(0)
H
-2

I found a solution to my own issue. Instead of using a c_str, I used std::string and switched to using the G++ compiler instead of Open Watcom

Instead of having:

char *someString="Blah blah blah";

I instead replaced it with:

string someString="Blah blah blah";

This way is much more efficient and easier.

Hypochondriac answered 26/10, 2016 at 1:26 Comment(5)
this does not answer the question at all. Actually besides talking about string, there is no connection with the question at all.Strawn
What do you mean? It does answer my own question because my issue was a compilation error, but as I said in my answer, the issue was originating from the compiler itself, so I switched from open watcom to G++.Hypochondriac
in your original question there is no mention of c_str or char*. So 80-90% of your answer refers to something that is not in the question. The fact that you used watcom and that changing to gcc solved the issue is buried by all the other information.Strawn
Yes because I'm stating the fact that the use of c_str or char wasn't where my issue came from. I beleived it was, but what I'm saying is that it's rather an internal issue from the compiler. I'm not sure what you're trying to prove here.Hypochondriac
not trying to prove anything. Simply trying to make you understand the discrepancy between your question and your answer. In your question there is absolutely no mention of c_str. None. Not a trace. Nothing. And then in your answer you go on about c_str and char* vs string. The fact that you "thought the problem was with c_str" is completely irrelevant because you didn't write about it in your question and we are not mind readers. So while your answer might make sense to you, for the rest of the community who only can read your question and not your mind it doesn't.Strawn

© 2022 - 2024 — McMap. All rights reserved.