Subject: Updated Records Available - (View Details)

From: Confirm Roommate Identity <[email-masked]>
Date: Tue, 12 Aug 2014 13:39:03 -0700

ATTN Atompub-archive,

Does that someone special have an Email account you dont know about?

Remain Anonymous and Check Here -> http://www.gaddug.com/view/updated/reports.index

Classified Info In Report to Include:
=====================================
Criminal Records | Judgements & Liens
Previous Addresses | Phone Numbers
Social Media Accounts | Emails

For Instant background check on person of your choice

Enter Name Here ::  http://www.gaddug.com/view/updated/reports.index

-
=
'
To stop further notifications - write Daily Updated Alerts
9306 BOVA CT- Louisville, KY 40291 or visit http://www.gaddug.com/hue3/aor9/95jf.s3tfdw

Probably a couple years late, but what's wrong with: ([^h]*(h([^e]|$)|he([^d]|$)|hed([^e]|$)))*? The idea is simple. Keep matching until you see the start of the unwanted string, then only match in the N-1 cases where the string is unfinished (where N is the length of the string). These N-1 cases are "h followed by non-e", "he followed by non-d", and "hed followed by non-e". If you managed to pass these N-1 cases, you successfully didn't match the unwanted string so you can start looking for [^h]* again: try this for 'a-very-very-long-word' or even better half a sentence. Have fun typing. BTW, it is nearly unreadable. Don't know about the performance impact.  Sure it's not pretty for very very long words, but it is a viable and correct solution. Although I haven't run tests on the performance, I wouldn't imagine it being too slow since most of the latter rules are ignored until you see an h (or the first letter of the word, sentence, etc.). And you could easily generate the regex str
 ing for long strings using iterative concatenation. If it works and can be generated quickly, is legibility important? That's what comments are for., are you using boost::regex() to find the regular expressions or anything other?  i'm even later, but that answer is almost completely wrong. for one thing, it requires the subject to contain "h" which it shouldn't have to, given the task is "match lines which [do] not contain a specific word". let us assume you meant to make the inner group optional, and that the pattern is anchored: ^([^h]*(h([^e]|$)|he([^d]|$)|hed([^e]|$))?)*$ this fails when instances of "hede" are preceded by partial instances of "hede" such as in "hhede"