Is it possible to overload a method on default parameters?
For example, if I have a method split() to split a string, but the string has two delimiters, say '_' and "delimit". Can I have two methods something like:
split(const char *str, char delim = ' ')
and
split(const char *str, const char* delim = "delimit");
Or, is there a better way of achieving this? Somehow, my brain isn't working now and am unable to think of any other solution.
Edit: The problem in detail:
I have a string with two delimiters, say for example, nativeProbableCause_Complete|Alarm|Text. I need to separate nativeProbableCause and Complete|Alarm|Text and then further, I need to separate Complete|Alarm|Text into individual words and join them back with space as a separator sometime later (for which I already have written a utility and isn't a big deal). It is only the separation of the delimited string that is troubling me.
No, you cant - if you think about it, the notion of a default means 'use this unless I say otherwise'. If the compiler has 2 options for a default, which one will it choose?
How about implementing as 2 different methods like
split_with_default_delimiter_space
split_with_default_delimiter_delimit
Personally I'd prefer using something like this (more readable.. intent conveying) over the type of overloading that you mentioned... even if it was somehow possible for the compiler to do that.
Why not just call split() twice and explicitly pass the delimiter the second time? Will delimiters always be single characters?
Do you perform any other processing on the 2nd set of words before joining them? If not, then for the second task what you really want to do is replace substrings. This is most easily done with std::string::find and std::string::replace. If you must use c-strings, you could use strstr/strchr/strpbrk, strcpy and strcat, or use just strstr/strchr/strpbrk and join them in place.
You could use a version of split that accepts a variable number of delimiters (split(const char*,vector<string>), if you want to split(const char*, const char**)) or just use Boost Tokenizer.
Related
Just trying a programming test for fun. It stipulates that I should read each word of a file, one by one.
It hints that I might want to use ifstream, but won't let me use std::string, so it looks like I have to use char*
In C I would read line by line & use strok() as I have multiple delimiters (white-space, quotes, brackets, etc).
What the most C++ way to do this - get the words one by one - without using std::string ?
First you must make sure that you have memory allocated for your string (this part would be handled automatically by std::string). Then just use the normal input operator >>, as it will separate on whitespace.
Don't forget to free the memory you allocate (also handled automatically by std::string).
Lesson to be learned: Use char pointers for exercises like these, otherwise use std::string.
Just read the file into a std::string and then use std::string::c_str ( ) to retrive the nul-terminated C-style string from std::string object.
Is it better to use std::string or single char when possible?
In my class I want to store certain characters. I have CsvReader
class, and I want to store columnDelimiter character. I wonder,
is it better to have it as char, or just use std::string?
In terms of usage I suppose std::string is far better, but I wonder
maybe there will be major performance differences?
If your delimiter is constrained to be a single character, use a char.
If your delimiter may be a string, use a std::string.
Seems fairly self-explanatory. Refer to the requirements of the project, and the constraints of the feature that follow from those requirements.
Personally it seems to me that a CSV field delimiter will always be a single character, in which case std::string is not only misleading, but pointlessly heavy.
In terms of usage I suppose std::string is far better
I have largely ignored this claim as you did not provide any rationale, but let me just say that I reject the hypothetical premise of the claim.
I wonder maybe there will be major performance differences?
Absolutely! A string consists of a dynamically-allocated block of characters; this is entirely more heavy than a single byte in memory. Notwithstanding the small-string-optimisation that your implementation may perform, it's simply pointless to add all this weight when all you wish to represent is a single character. A single character is a char, so use a char in such a case.
A character is a character. A string is a string; conceptually, a set of N characters, where N is any natural number.
If your design requires a character, use char. If it requires a string, use string.
In both cases you may have multilanguage issues (what happens if the characteer is 青? what happens if the string is 青い?), but these are totally independent of your choice of whether you need a character or a set of N characters, i.e. a string.
I have a variable named "String" that may have values like the following ones:
const char* String = "/v1/AUTH_abb52a71-fc76-489b-b56b-732b66bf50b1/test/DSC_0188.JPG";
or
const char* String = "/auth/v1.0";
or
const char* String = "/v2/AUTH_abb52a71-fc76-489b-b56b-732b66bf50b1/images?limit=1000&delimiter=/&format=xml";
Now I want to make sure whether or not "String" has the character 'v1'. Checking this has to be precise. I tried with strchr, but it's not quite accurate as it doesn't take 'v1' as one character, it rather takes 'v' and '1' as two separate characters. Moreover I can't use namepace std and library string, I can only use "string.h". Within these limitations how can I accurately check whether the variable "String" has a character 'v1'?
Thank you.
I want to make sure whether or not "String" has the character 'v1'
I can only use "string.h"
Then you probably want strstr. Also v1 is not a character, it's a string.
Side note: why use cstring in C++ ? What kind of teacher is still calling it string.h ?!
v1 is not character according to any alphabet. This is a proper string "v1" and as #cnicutar mentioned the c way to search for string in string is to use strstr. It is quite easy to use and runs KMP which is also very fast (though for the kind of your string it is not that crucial).
I would advise you to:
always name your variables starting small-caps (i.e. String -> my_string)
declare your string as const char[], no need to interfere with pointers, when you can avoid them. Declaring this as pointer might confuse you, that you dynamically allocated the memory for the string.
what is the best way to call a function with the following declaration
string Extract(const char* pattern,const char* input);
i use
string str=Extract("something","input text");
is there a problem with this usage
should i use the following
char pattern[]="something";
char input[]="input";
//or use pointers with new operator and copy then free?
the both works but i like the first one but i want to know the best practice.
A literal string (e.g. "something") works just fine as a const char* argument to a function call.
The first method, i.e. passing them literally in, is usually preferable.
There are occasions though where you don't want your strings hard-coded into the text. In some ways you can say that, a bit like magic numbers, they are magic words / phrases. So you prefer to use constant identifier to store the values and pass those in instead.
This would happen often when:
1. a word has a special meaning, and is passed in many times in the code to have that meaning.
or
2. the word may be cryptic in some way and a constant identifier may be more descriptive
Unless you plain to have duplicates of the same strings, or alter those strings, I'm a fan of the first way (passing the literals directly), it means less dotting about code to find what the parameters actually are, it also means less work in passing parameters.
Seeing as this is tagged for C++, passing the literals directly allows you to easily switch the function parameters to std::string with little effort.
I wish to split a string on a single character or a string. I would like to use boost::split since boost string is our standard for basic string handling (I don't wish to mix several techniques).
In the single character case I could do split(vec,str,is_any_of(':')) but I'd like to know if there is a way to specify just a single character. It may improve performance, but more importantly I think the code would be clearer with just a single character, since is_any_of conveys a different meaning that what I want.
For matching against a string I don't know what syntax to use. I don't wish to to construct a regex; some simple syntax like split(vec,str,match_str("::") would be good.
I was looking for the same answer but I couldn't find one. Finally I managed to produce one on my own.
You can use std::equal_to to form the predicate you need. Here's an example:
boost::split(container, str, std::bind1st(std::equal_to<char>(), ','));
This is exactly how I do it when I need to split a string using a single character.
In the following code, let me assume using namespace boost for brevity.
As for splitting on a character, if only algorithm/string is allowed,
is_from_range might serve the purpose:
split(vec,str, is_from_range(':',':'));
Alternatively, if lambda is allowed:
split(vec,str, lambda::_1 == ':');
or if preparing a dedicated predicate is allowed:
struct match_char {
char c;
match_char(char c) : c(c) {}
bool operator()(char x) const { return x == c; }
};
split(vec,str, match_char(':'));
As for matching against a string, as David Rodri'guez mentioned,
there seems not to be the way with split.
If iter_split is allowed, probably the following code will meet the purpose:
iter_split(vec,str, first_finder("::"));
On the simple token, I would just leave is_any_of as it is quite easy to understand what is_any_of( single_option ) means. If you really feel like changing it, the third element is a functor, so you could pass an equals functor to the split function.
That approach will not really work with multiple tokens, as the iteration is meant to be characater by character. I don't know the library enough to offer prebuilt alternatives, but you can implement the functionality on top of split_iterators