-1

I'm trying to do this.

#include<graphics.h>
string words[4]={"Monday","Tuesday","Wednesday","Thursday"};
outtextxy(12,24,words[2]);

But I keep getting the error

cannot convert 'const string {aka const std::basic_string}' to 'char*' for argument '3' to 'void outtextxy(int, int, char*)'

How do I put array elements into outtextxy?

Some Student
  • 134
  • 6
  • You cannot issue any statement outside of function. – πάντα ῥεῖ Apr 15 '21 at 07:21
  • Duplicate question: https://stackoverflow.com/questions/347949/how-to-convert-a-stdstring-to-const-char-or-char – πάντα ῥεῖ Apr 15 '21 at 07:22
  • "You cannot issue any statement outside of function"? What does it mean? – Some Student Apr 15 '21 at 07:24
  • 1
    Side note: Due to the age of many implementations of graphics.h, you can do everything right and the program may still fail to work simply because the BGI library implementation cannot work on modern computers. Be careful with it and remember BGI came out of the 1980s. Are you really sure you want to use 40-year-old technology? – user4581301 Apr 15 '21 at 07:38

1 Answers1

1

Your outtextxy() expects a char pointer not an std::string, so either change your function, or use a pointer. Since this expects a char, and a string returns a const pointer you need to cast it. If you can change the function, then I would recommend to change it at least to a const char *.

outtextxy(12,24,const_cast<char *>(words[2].c_str()));
Devolus
  • 21,661
  • 13
  • 66
  • 113
  • This causes undefined behavior if the C string is modified in the function. Don't `const_cast` unless you're completely sure it's allowed. You could copy the element into a new C string and pass a pointer. –  Apr 15 '21 at 07:25
  • 1
    Note that from C++17 onwards, you don't have to use `const_cast` and can use `words[2].data()` since `std::string::data` returns a mutable array from C++17 onwards. – mediocrevegetable1 Apr 15 '21 at 07:29
  • https://en.cppreference.com/w/cpp/string/basic_string/c_str _"Writing to the character array accessed through c_str() is undefined behavior."_ –  Apr 15 '21 at 07:32
  • @jabaa strange, I just checked the prototypes of `data` here https://en.cppreference.com/w/cpp/string/basic_string/data and from C++17 onwards, there is a prototype `CharT* data() noexcept;` (which returns a mutable array) that `c_str` does not have – mediocrevegetable1 Apr 15 '21 at 07:36
  • @mediocrevegetable1 I'm confused by the sentence _"data() and c_str() perform the same function."_ but I assume they mean the const version of `data()`. But couldn't _"The returned array is not required to be null-terminated (until C++11)"_ be a problem? –  Apr 15 '21 at 07:37
  • @jabaa must be that, maybe the author of the page forgot to put _(until C++17)_ :/ As for the non-null-terminated issue, it is null-terminated from C++11 ownards, and since `data()` returns a mutable array as of C++17, this is likely not be an issue in C++17 (and the point about using `data()` is useless pre-C++17 since it returns an immutable array anyways, so same as `c_str`). – mediocrevegetable1 Apr 15 '21 at 07:40
  • 1
    `outtextxy`'s signature is, most likely, a design flaw (a typo?) - I doubt the function is changing the pointed content. – zdf Apr 15 '21 at 08:06
  • 1
    @zdf, that's my assumption as well, as it wouldn't really make sense to modify the string. But I assume that the OP uses a library and can't change that anyway. – Devolus Apr 15 '21 at 09:03
  • @jabaa, We are developing by information provided. – Devolus Apr 15 '21 at 10:05
  • And nowhere in the question there are details that the C string is not modified. You're just assuming it. –  Apr 15 '21 at 10:54
  • 2
    Relatively safe assumption, given the API. The BGI library predates C's adoption of `const` in C89. – user4581301 Apr 15 '21 at 15:49
  • Another side note: Pre C++11 `c_str` was allowed to do some pretty silly stuff , like make a null-terminated buffer out of thin air on he off chance the `string`'s real buffer wasn't null terminated. You rarely saw this happen in the wild because too much existing code needed that `c_str` function, so it wasn't worth the extra work to save that null-termination byte. I never worked on a mainstream compiler that had problems with illegal stuff like `&str[0]` to get the buffer li just like I never had any problems with `&vec[0]` before c++11 and `data`. – user4581301 Apr 15 '21 at 22:53
  • That said, before about 2013, I was writing a LOT more C and Java than C++ and, in hindsight, my C++ was truly horrific C and Java-inflected garbage. – user4581301 Apr 15 '21 at 22:58
  • @user4581301, My C++ improved a lot after I learned Java. Before it was not much more than some little bit of better C. :) – Devolus Apr 16 '21 at 06:30
  • Probably a function either of you or the ordering. For me, C++ after Java required a great deal of unlearning. Perhaps the other way around is better. Can't say. – user4581301 Apr 16 '21 at 06:34