25 Jun, 2010, JohnnyStarr wrote in the 1st comment:
Votes: 0
This may be a simple question, but the examples in my C++ book actually don't include the specifics of what I'm wondering.
It seems that when you create a class, and want to embed that into another custom class, it is a bit more complicated using
a reference than a pointer. If I wanted to add an STL object like a vector or list, I could just do it this way:

class Interpreter {
std::vector<int> dumbList;
};


But say I wanted each Interpreter to have a Lexer and Parser object? How would I go about that? Would it make more sense
to instantiate the objects first, then in the constructor send them by ref? Or, could I initialize them within the constructor and
assign them afterwards? I know I could just use a pointer, but it doesn't make much sense considering that the Lexer and
Parser objects will never change, and therefor the variable representing them shouldn't change as well. I'll throw this out there
too (since it's almost on topic).

Strings in C++ elude me a bit as well. If I were to have a object constructor take a string literal as a parameter, I would assume that it would be received as a string. But whenever I do that, it says "cannot convert const char* to std::string". So,
I understand the whole C-Legacy deal, but this makes it a bit cumbersome. Must one create a string object and then pass it
by reference just to appease the C++ gods? I've observed that I could overload the constructor and receive a const char* which
could call the std::string constructor and convert, but that seems a bit awkward.
25 Jun, 2010, JohnnyStarr wrote in the 2nd comment:
Votes: 0
weird, my post didn't show up on the home page :cry:
25 Jun, 2010, 3squire wrote in the 3rd comment:
Votes: 0
It did, no worries. Kiasyn fucked up everybody's version of the homepage with his upgrade – You have to go to http://www.mudbytes.net/index.php?a=rece... then at the bottom of the left column are two buttons "update" and "save" – click save with all the boxes checked, and you will see the latest post in every forum.
25 Jun, 2010, ocson wrote in the 4th comment:
Votes: 0
JohnnyStarr said:
weird, my post didn't show up on the home page :cry:


It's there now, well at least it is for me.

You can use the initializer list:

class Interpreter
{
public:

Interpreter();

private:

std::vector<int> dumbList;
Lexer lexer;
Parser parser;
};

Interpreter::Interpreter() : lexer(lcparam1,lcparam2,…), parser(pcparam1,pcparam2,…)
{
}


Where the lcparams and the pcparams are constructor parameters for the lexer and parser. Then you don't have to worry about references or pointers.

For the strings, if your constructor accepts a string by value or (better) constant reference, it should convert just fine. If your constructor accepts a non-constant string reference, you may have to explictly create a string object.
25 Jun, 2010, kiasyn wrote in the 5th comment:
Votes: 0
3squire said:
It did, no worries. Kiasyn fucked up everybody's version of the homepage with his upgrade – You have to go to http://www.mudbytes.net/index.php?a=rece... then at the bottom of the left column are two buttons "update" and "save" – click save with all the boxes checked, and you will see the latest post in every forum.


that was davion's upgrade, and theres really no need to be rude about it
28 Jun, 2010, JohnnyStarr wrote in the 6th comment:
Votes: 0
Thanks guys, very helpful.

I tried to compile my ROM project with g++ 4.4.3, which worked fine in 4.1* but it's giving me this warning all over the place:

warning: deprecated conversion from string constant to char*

Which I know has to do with the fact that the string literals are being stored or passed as a char* string and not a const char* right?
I really hope thats all, because I don't want to change it all to std::string. It compiles with no errors, so maybe it's just a matter of
passing a no warning arg to gcc, but I'm curious what others think about the situation.
29 Jun, 2010, David Haley wrote in the 7th comment:
Votes: 0
It's better to fix those warnings but not (usually) necessary. In certain circumstances, you can get a crash, such as when a read-only string in the data segment (that should be const) is modified.
29 Jun, 2010, Runter wrote in the 8th comment:
Votes: 0
DH said:
It's better to fix those warnings but not (usually) necessary


Kinda depends on how you fix it though, right? I know you get it, but probably some people out there don't. I guess my point is just making a warning go away with obligatory code that effectively does the same thing doesn't make much difference. Imo if you're being warned about something it's probably because you're doing something poorly thought out in the first place. Instead of focusing on making warnings go away we should probably focus on what they're trying to warn us about.

int i = 10;
char *c = (char*) i; // fixed


That being said. Warnings aren't compiler errors. I typically don't mind having warnings in a project.
29 Jun, 2010, David Haley wrote in the 9th comment:
Votes: 0
Hmm, yes. I meant actually fixing the warning by not masking it, but making functions that should take const char* actually take const char*, and not casting a const char* to a char* but working around it as necessary (creating temporary copies if needed). It's virtually never a good idea to just mask a warning unless you really know what you're doing.

This particular warning is just annoying because lots of code violates the principle, and it was accepted before (sometimes causing crashes). So a lot of people disable it; there's a compiler flag that does it. (-no-const-literals?? don't remember)
29 Jun, 2010, 3squire wrote in the 10th comment:
Votes: 0
kiasyn said:
3squire said:
It did, no worries. Kiasyn fucked up everybody's version of the homepage with his upgrade – You have to go to http://www.mudbytes.net/index.php?a=rece... then at the bottom of the left column are two buttons "update" and "save" – click save with all the boxes checked, and you will see the latest post in every forum.


that was davion's upgrade, and theres really no need to be rude about it


True. I apologize, both for both mistakes.
29 Jun, 2010, Kaz wrote in the 11th comment:
Votes: 0
JohnnyStarr said:
Strings in C++ elude me a bit as well. If I were to have a object constructor take a string literal as a parameter, I would assume that it would be received as a string. But whenever I do that, it says "cannot convert const char* to std::string". So, I understand the whole C-Legacy deal, but this makes it a bit cumbersome. Must one create a string object and then pass it by reference just to appease the C++ gods? I've observed that I could overload the constructor and receive a const char* which could call the std::string constructor and convert, but that seems a bit awkward.


A string literal in C++ is the same type of C. That is, the type of "Hello, world", is const char *.

There exist implicit conversions to make this less painful. For example, you can have a function that take a reference to a constant std::string, and you can pass std::strings, char*s, and string literals into it.

#include <string>
void fn(const std::string &foo);

int main()
{
fn("Hello, world!");

char *charstarfoo = "Hello, world!";

fn(charstarfoo);

std::string stdstringfoo = "Hello, world!";

fn(stdstringfoo);
}


There is no such implicit conversion the other way, but std::string objects have a c_str() member function that returns the const char* version of that string:

#include <string>
void fn(const char *foo);

int main()
{
std::string stdstringfoo = "Hello, world!";

fn(stdstringfoo.c_str());
}


In short. Yes, you must appease the C++ gods, one way or another. std::string is just another object and has no special status in the language.
0.0/11