|
As I read the question, the OP isn't looking for an uppercase regex; he wants case-insensitive matching.
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994.
|
|
|
|
|
Hi.
Yes, that works, the problem seems to lie in that the chars between the brackets [] do not get processed in a case-insensitive way.
I believe the following describes the problem:
www.comeaucomputing.com/iso/lwg-active.html#523
It is still flagged as an open issue - if this is actually the case then this is madness. The least I expect from a regex, is to be able to perform a case-insensitive comparison on a given range of characters.
-- modified 28-Sep-11 5:42am.
|
|
|
|
|
TenFiftyTwo wrote: Yes, that works, the problem seems to lie in that the chars between the brackets [] do not get processed in a case-insensitive way.
So then how about:
H[A-Za-z]+O
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
|
|
|
|
|
Hi.
Thanks very much - thats what I did in the end. I know the example I gave was trival and the real expression is significally more complicated; so I wanted the fastest regex I could get. The process operates on potentially many miliions of lines of data and I wanted to keep the process as 'inexpensive' as possible.
Neverthless - thanks a lot for your time and effort pondering this.
Many thanks.
James.
|
|
|
|
|
Obvious dumb debug thing I'd do - dump the arguments you're actually using immediately before the regex_match() call. You use a_pRegex in one place and m_pRegex in another, so I, for one, don't know what is actually going to be used...
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994.
|
|
|
|
|
I want to build a parameters string, but keep each parameter on it's own line for easy editing and reading.
The variable is a CString, and I want to make 1 giant string out of it. Just looking for the proper way to do this.
lp_Parameters = "/iu " +
"IIS-WebServerRole;" +
"IIS-WebServer;" +
"IIS-CommonHttpFeatures;" +
"IIS-StaticContent;" +
"IIS-DefaultDocument;" +
"IIS-DirectoryBrowsing;" +
"IIS-HttpErrors";
|
|
|
|
|
get rid of the + operator.
so
CString string("/iu "
"IIS-WebServerRole;"
"IIS-WebServer;"
"IIS-CommonHttpFeatures;"
"IIS-StaticContent;"
"IIS-DefaultDocument;"
"IIS-DirectoryBrowsing;"
"IIS-HttpErrors");
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun
|
|
|
|
|
|
Adding strings together and CString.Format() do give the same results. However, for some uses, like if the string is periodically edited, adding strings is easier to change / expand / delete things without having to go back and fix the formatting control string too. Especially when mixing constant strings and variables to create a MessageBox string.
|
|
|
|
|
except that he's not formatting a string, there are no parameters. Otherwise I would agree.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun
|
|
|
|
|
You can still use the method... it should save operating cycles over putting a bunch of strings together, since it won't call individual constructors.
|
|
|
|
|
true, it saves over using the + operator, but since the ctor is going to be called anyway, you're calling an extra method (Format) unnecessarily.
As, I'm sure you know, the compiler does the concatenation of adjacent strings ("abc" "def") is the same as ("abcdef"). So simply removing the + operator and explicitly calling the ctor is better.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun
|
|
|
|
|
No need for the + signs, this should work (as long as there is nothing else between the "string fragments":
lp_Parameters = "/iu "
"IIS-WebServerRole;"
"IIS-WebServer;"
"IIS-CommonHttpFeatures;"
"IIS-StaticContent;"
"IIS-DefaultDocument;"
"IIS-DirectoryBrowsing;"
"IIS-HttpErrors";
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
Hummm, learn something new everyday. For a language that says that whitespace doesn't matter, here it does and it appears to permit concatenation of adjacent strings.
Forgive me but I find putting in the explicit + more clearly states my intentions.
|
|
|
|
|
except that the explicit + operator causes code to be called for each +. A ctor and the operator+() method.
the other way, only one method gets called - the ctor or the assignment operator.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun
|
|
|
|
|
Oh, I agree that there are runtime performance considerations of adding strings at runtime versus letting the compiler do it at compile time.
If this were in a critical path for performance, I would say do it your way. I often will trade of these small performance considerations for clarity / readability of the code if it occurs in a once-only or non-critical path, like error messages or response to a user triggered event (pushes a button).
|
|
|
|
|
That would assume there actually is an operator+() for string literals, but there is none! The expression "foo"+"bar" is not valid in C++. VS produces error 2110 (cannot add two pointers) on such expressions.
|
|
|
|
|
It depends on the definition of CString. If it has a operator+(const char*, const char*) then yes it would be valid C++.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun
modified 28-Sep-11 13:09pm.
|
|
|
|
|
You are mistaken. You cannot define a member function CString::operator+(const char*,const char*), nor a simple function operator+(const char*,const char*). The latter is impossible because you cannot overload operators working on built-in types. The former isn't possible, because that would be a ternary operator, and there is no ternary operator+.
|
|
|
|
|
Read my post again.
I said it depends on whether or not CString has an operator+(const char*, const char*). Since the OP indicated that the variable is a CString (which does have a such an operator+ defined) then it is valid C++ code.
Where did I say anything about a tertiary operator +? And CString is NOT a built-in type.
I'm basically agreeing with you.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun
|
|
|
|
|
ahmed zahmed wrote: Read my post again.
I did, but I see no misunderstanding on my part. I may not have been clear enough though. All of the things I said above were accurate and I actually checked Visual Studio to make sure they were.
Also anything I 'interpreted' into your posting was accurate - I did not state anything that you didn't say, but you might not have realized the literal meaning of what you were saying. I did not in fact 'interpret' your posting inaccurately, I merely took it literally. I am aware that you did not mean to make (some of) the statements that I read into your posting, therefore I pointed that out to you.
Here's what you said:
ahmed zahmed wrote: It depends on the definition of CString. If it has a operator+(const char*, const char*)...
First: it does not depend on CString, but more on that later.
Second, when you say that a class X 'has a operator Y(...)', then this might mean that either the operator is defined as a member function, or the operator is defined outside the class. Both are possible, and in fact, the class CString does define all overloads of it's operator+() outside the class, not as member functions. You can indeed find them in the class definition, but only as friend declarations. All 7 overloads are declared friend.
So, when I considered the two possibilities of either a member function operator, or a non-member function, I did not misunderstand your posting, I merely considered two possible meanings.
Third, ...
ahmed zahmed wrote: Where did I say anything about a tertiary operator +?
... you might not have meant to, but you implied the possibility of an operator
CString& CString::operator+(const char*, const char*)
Now think about that. When you define a member function with two parameters, then in truth, this function has three parameters: the two arguments you specified, plus the instance of the class itself. This instance will be passed to that member function as a pointer, using the name this. Therefore, when you define an operator as a member function and pass it two parameters, the operator will in fact have 3 parameters. An operator with 3 parameters is a ternary operator.
ahmed zahmed wrote: And CString is NOT a built-in type.
Now you are mistaking me, I did not say that. What I did say was:
Stefan_Lang wrote: you cannot overload operators working on built-in types
I did not explicitely or implicitely relate to CString here. I did implicitely relate to the (imaginary) simple function const char* operator+(const char*, const char*), not a member function of CString. The arguments that this operator is working on are of type const char*, and that is a built-in type.
Now back to my first point above:
Stefan_Lang wrote: it does not depend on CString
When you have an expression like this
CString s = "foo" + "bar";
then the compiler evaluates (or at least tries to evaluate) it to
CString::operator=(operator+("foo", "bar"));
Now the compiler has to match all overloads of operator+(,) against the argument types. The argument types in this case are (const char*, const char*). Since neither of the argument types is CString, the compiler can not hope to find one in the list of CString operators! Therefore the implementation of CString is irrelevant in this case!
I hope now my meaning gets clearer.
|
|
|
|
|
Sadly az is a person who thinks he knows a lot more than he actually does. There is no arguing with him. It's a waste of time and effort.
|
|
|
|
|
There is nothing in the posted expression "foo"+"bar" that is or implies "CString", they are two standard language char * expressions. And, as Stefan says, you cannot "add" them.
This is why I wrap them with explicit CString constructors. CString("foo") + CString("bar") when I need to do something like that.
|
|
|
|
|
You are correct, you can't "add" the const char expressions.
However, the OP *did* say the variable was a CString. Given that, and the fact that I said *if* CString had an operator+(const char*, const char*) *then* the code *would* be valid C++.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun
|
|
|
|
|
True, that's what he said *but* the statement that he wrote, with the + for addition of the strings, in now way invokes any CString operators on the right side of the assignment (=) so even if CString would have such an operator, it would not be applied since no items on the right side of the expression are of type CString to start with. A CString object would have to be on the right side for its theoretical + operator to apply.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
