Sign in to follow this  

ostringstream going wrong - c++

This topic is 3634 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Good evening all. I'm fiddling with ostringstream as a means of getting my numeric variables into strings, and considered it to be going oh-so-well until the following function started giving me a headache:
std::string OrderDetail::getSaveString(void)
{
	std::string saveString = "";
	std::ostringstream oss;

	
	oss << saveString << orderItem->getRef();
	saveString.append(" ");
	oss << saveString << getQuantity();

	std::cout << "getRef gave: " << orderItem->getRef() << std::endl;
	std::cout << "getQuantity gave: " << getQuantity() << std::endl;
	std::cout << "But string contains: " << saveString;
	system("PAUSE");
	return saveString;
}


as you can see I've got some debugging couts at the end there. They show that although the functions are correctly getting their hands on numbers, the string is only populating with a space. The use of the stream seems identical to previous uses, and I can't see what's going wrong. Can anyone help?

Share this post


Link to post
Share on other sites
You are using the ostringstream wrong.

Here is the error. First you store saveString in oss and then you store the result of orderItem->getRef() in oss. Then you add a space to the string. After that you add the string again to oss followed by the results of getQuantity()

oss << saveString << orderItem->getRef();
saveString.append(" ");
oss << saveString << getQuantity();


You see you have not saved anything into the string, you have just been adding content to the ostringstream object.

Here is how it should work

std::string OrderDetail::getSaveString(void)
{
std::ostringstream oss;
oss << orderItem->getRef() << " " << getQuantity();

return oss.str();
}

Share this post


Link to post
Share on other sites

std::string OrderDetail::getSaveString()
{
std::ostringstream oss;

oss << orderItem->getRef();
oss << " " << getQuantity();
return oss.str();
}




I think you probably want something like the above. The problem with your posted code snippet is that the stream insertion operator << is simply inserting your saveString into the ostringstream. The value of saveString never changes, and you never do anything with the values now stored inside of your string stream.

Also, it is not necessary or considered "good practice" in C++ to declare a function as foo(void). If the function takes no arguments, just write it as foo().

Share this post


Link to post
Share on other sites
Quote:
Original post by jcullet
*** Source Snippet Removed ***

Also, it is not necessary or considered "good practice" in C++ to declare a function as foo(void). If the function takes no arguments, just write it as foo().


Thanks for your help both - all working as intended now.

Is it considered _bad_ practice to leave the "void" in. I'm sure I could train myself out of the habit, but do I need to?

Share this post


Link to post
Share on other sites
Well, in C, writing foo(void) explicitly tells the compiler that a function must be called with no arguments. Thus calling foo(1,2) would give a compile time error. At the same time, declaring foo() in C will allow you to call foo(1,2) without a compiler error.

C++ treats both declarations the same. That is, foo(void) and foo() are equivalent and each will raise a compiler error if you try to call foo(1,2).

It is simply unnecessary to write foo(void) in C++.

Share this post


Link to post
Share on other sites
Quote:
Original post by jcullet
Well, in C, writing foo(void) explicitly tells the compiler that a function must be called with no arguments. Thus calling foo(1,2) would give a compile time error. At the same time, declaring foo() in C will allow you to call foo(1,2) without a compiler error.

C++ treats both declarations the same. That is, foo(void) and foo() are equivalent and each will raise a compiler error if you try to call foo(1,2).

It is simply unnecessary to write foo(void) in C++.


You are really splitting hairs here, just because it is unessecary means you can not do it and is wrong? I most certainly think not. That is almost as silly as people arguing over whether a brace goes on the same line as the difinition of a function or not.

Unless you have a real code breaking reason for someone not to do something then do not go around telling others to change thier coding styles. That is up to what the individual wants to do or what their professor/boss tells them.

To the original poster, whatever you decided to do just be consistant with it.

Share this post


Link to post
Share on other sites
Quote:
Original post by antiquechrono
You are really splitting hairs here, just because it is unessecary means you can not do it and is wrong? I most certainly think not. That is almost as silly as people arguing over whether a brace goes on the same line as the difinition of a function or not.

Unless you have a real code breaking reason for someone not to do something then do not go around telling others to change thier coding styles. That is up to what the individual wants to do or what their professor/boss tells them.

To the original poster, whatever you decided to do just be consistant with it.
I do agree with you that:

1. It's important to be consistent.

2. Sometimes you may have to follow someone else's stylistic guidelines (e.g. an employer or professor), so it's important to be flexible and to be able to adapt to different coding styles.

However, IMO the 'void' thing really isn't splitting hairs, and it's not equivalent to issues such as, say, bracket placement. In C++, putting 'void' in parentheses to indicate an empty argument list just adds visual and conceptual noise to the code. There is no benefit, and it could be argued that there is a loss of clarity. So I think 'just don't do it' is reasonable advice here.

Share this post


Link to post
Share on other sites
Quote:
Original post by jyk
However, IMO the 'void' thing really isn't splitting hairs, and it's not equivalent to issues such as, say, bracket placement. In C++, putting 'void' in parentheses to indicate an empty argument list just adds visual and conceptual noise to the code. There is no benefit, and it could be argued that there is a loss of clarity. So I think 'just don't do it' is reasonable advice here.


I can see where you are going with this. For instance my friend uses the "this" pointer on every single variable in all of his classes and it drives me absolutely crazy. I finally got a good laugh when it came back to bite him when he had a nasty bug that turned out to be due to dereferenceing one of them wrong.

Share this post


Link to post
Share on other sites
Quote:
Original post by jyk
However, IMO the 'void' thing really isn't splitting hairs, and it's not equivalent to issues such as, say, bracket placement. In C++, putting 'void' in parentheses to indicate an empty argument list just adds visual and conceptual noise to the code. There is no benefit, and it could be argued that there is a loss of clarity. So I think 'just don't do it' is reasonable advice here.

Eh, it's not so one sided as that. C++ is a language where anything that can be parsed as a function declaration is a function declaration. By using a void function argument list you indicate that the function declaration is intended to be a function declaration, and isn't a malformed variable declaration of a default constructed object. In my own code I use void to indicate a function that takes no arguments.

Share this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
Quote:
Original post by jyk
However, IMO the 'void' thing really isn't splitting hairs, and it's not equivalent to issues such as, say, bracket placement. In C++, putting 'void' in parentheses to indicate an empty argument list just adds visual and conceptual noise to the code. There is no benefit, and it could be argued that there is a loss of clarity. So I think 'just don't do it' is reasonable advice here.

Eh, it's not so one sided as that. C++ is a language where anything that can be parsed as a function declaration is a function declaration. By using a void function argument list you indicate that the function declaration is intended to be a function declaration, and isn't a malformed variable declaration of a default constructed object. In my own code I use void to indicate a function that takes no arguments.
Fair enough.

For my own purposes, when I weigh the regularity with which I deal with function syntax in C++ against the number of times I've been bitten by the 'variable declaration interpreted as function declaration' gotcha (once, maybe?), omitting the 'void' seems to me to be a win.

However, I certainly respect your expertise (which significantly exceeds mine), so I hereby rescind my earlier statements on the matter :)

Share this post


Link to post
Share on other sites
Well, it's not like that's the only reason. There are other reasons like sharing code with C source files since () and (void) are interpreted differently there. Also, by differentiating function declaration and function usage, automated searches of source text for "foo()" will turn up only usages whereas not differentiating will also pollute search results with declarations/definitions; and searching for "foo(void)" will only turn up declarations/definitions. These aren't major arguments for, but at the same time, I don't see any particularly compelling arguments against. A coding standard can reasonably specify one or the other. I personally prefer using (void), but I'm not going to say it's the One True Way™.

Share this post


Link to post
Share on other sites

This topic is 3634 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this