What flavor of does C++11 support

[kurt krueckeberg]

Are Perl Compatible Regular Expressions (PCRE) supported with the regex support added to C++11?

 

[kurt krueckeberg]

I meant <regex> . Looks like various flavors of POSIX, according to http://www.cplusplus.com/reference/regex/regex_constants/

 

[Jorgen Grahn]

I meant <regex> . Looks like various flavors of POSIX, according to
http://www.cplusplus.com/reference/regex/regex_constants/

That's funny; TC++PL says the default RE syntax is the one in
ECMAScript, Others include basic POSIX, extended POSIX, awk, grep and
egrep.

As I understand it, ECMAScript REs are similar to Perl's, and Perl's
are very similar to PCRE.

/Jorgen

 

[Jorgen Grahn]

If you want PCRE, it doesn't matter what is or isn't in C++11. Just link
with PCRE, and use it.

It's common for people to prefer the standard library to some
third-party library which does the same thing, but in a non-standard
way.

/Jorgen

 

[kurt krueckeberg]

As I understand it, ECMAScript REs are similar to Perl's, and Perl's

are very similar to PCRE.

According to the answer given at
http://stackoverflow.com/questions/...n-to-equivalent-ecmascript-regular-expression

"ECMA regex is a subset of Perl regex", which is good to know.

 

[Jorgen Grahn]

gcc's libstdc++ does not have regex implemented yet.

Huh? Yes, you're right, unless they forgot to update
<http://gcc.gnu.org/onlinedocs/libstdc++/manual/>.
That's surprising -- any idea why?

There's also Boost.Regex; II suppose that would be more similar to the
standard regex than PCRE is.

/Jorgen

 

[Rui Maciel]

It's common for people to prefer the standard library to some
third-party library which does the same thing, but in a non-standard
way.

It's irrelevant if the library is standardized or not if it's freely available and released
under an open-source library.

PCRE is one of those cases.

This is exactly the sort of thing that should never be in the C++ standard.


Rui Maciel

 

[Jorgen Grahn]

Sure it does matter. There is a mountain of difference if you can just
rely on your code to working on all platforms with the standard C++
implementation, or you must take care of downloading, compiling,
integrating into the build process, porting and/or upgrading the library
when adding platforms or changing to a newer compiler version, etc, etc.

More generally: you can expect the standard library to be well-known,
documented in books and so on. And stable. No disrecpect intended:
PCRE seems like one of those few C libraries which will stick around
for a decade or two ... But books and courses on C++ won't cover it.
They will cover the mechanisms /inside/ the language.

/Jorgen

 

[Jorgen Grahn]

On the platforms that I care about, pcre comes as part of the standard OS
build.

I'm on Linux, so yeah, it's an 'aptitude install' away. And nowadays I
know that it is not sinful to rely on your platform. Lots of money
have been wasted by people trying to do Unix-specific things on Unix
in a supposedly platform-independent way. However:

And even on platforms that are not, if "downloading, compiling,
integrating, porting and/or upgrading" is such a big issue for
someone, they should probably find some other line of work,
other than C++ development. Really. I thought that "downloading,
compiling, integrating, porting and/or upgrading" is really what
a C++ developer is expected to do.

No, that's an integrator's work. If you're a programmer in a large
organization, deciding "I need PCRE" creates an unknown amount of work
for different people down the line. Someone has to watch out for
security bug fixes, someone has to do the paperwork related to
licensing and patent issues and whatnot. Someone has to make sure there
are people who can maintain the code if you're run over by a bus, and
so on ...

On the other hand, deciding "I need a C++ compiler with regex support"
has similar consequences if you don't have one already. That's why my
people are stuck with old ANSI C from 1989 -- for ~15 years we've
failed to find a path through the maze of bureaucracy and intra/
extra-office politics which lets us move to a more efficient way to
express our designs.

/Jorgen

 

[Rui Maciel]

Not sure which part of above qualifies as "develop C++". For me, writing
my own code *on top* of existing libraries is much more fun than
downloading/upgrading/etc. The latter is just a necessary evil which I
would like to reduce to minimum.

The libraries exist even if they haven't been added to ISO/IEC 14882 by a standards committee.

And if it really pains you to do simple and mundane things such as download a package from the
internet and install it, even if it only takes a couple of mouse clicks or a simple command
(sudo apt-get install libpcre3-dev), then you have bigger problems to tackle other than what
component has or hasn't been standardized.


Rui Maciel

 

[Öö Tiib]

The libraries exist even if they haven't been added to ISO/IEC 14882 by
a standards committee.

And if it really pains you to do simple and mundane things such as download
a package from the internet and install it, even if it only takes a couple
of mouse clicks or a simple command (sudo apt-get install libpcre3-dev),
then you have bigger problems to tackle other than what component has
or hasn't been standardized.

What you are talking about? Linux? Linux crowd anyway uses C more
than C++.

Windows or Mac has it not. That MacPorts and the like are hurting more
than aiding by installing their own Perl, Tex or even gcc. There are also
that pile of tablets and phones for what there is technically nothing.
Even things like QT barely work on some. Without owners and standards
anything reduces into obscure toy of few enthusiasts who get it running
more or less on their own Linux box.

 

[Rui Maciel]

What you are talking about? Linux? Linux crowd anyway uses C more
than C++.

I don't know what you tried to say, but even in your baseless sweeping generalization you've
acknowledge that C++ is in fact used.

Which is stating the obvious.


Rui Maciel

 

[Melzzzzz]

What you are talking about? Linux? Linux crowd anyway uses C more
than C++.

Well, not exactly true. The fact that Linux kernel is 100% C, does not
changes a fact, that many Linux applications are C++, too.
KDE and all KDE apps are C++ for example...
Actually as I look at source code of games and some apps, main
language on Linux is C++... (there are Java apps, too)

 

[Jorgen Grahn]

No, that's an integrator's work. If you're a programmer in a large
organization, deciding "I need PCRE" creates an unknown amount of work
for different people down the line.

Only if your large organization has a technically dysfunctional environment.

Someone has to watch out for
security bug fixes, someone has to do the paperwork related to
licensing and patent issues and whatnot. Someone has to make sure there
are people who can maintain the code if you're run over by a bus, and
so on ...

Right. All the signs of a typical large organization that's run by PHBs.[/QUOTE]

If it's done badly, perhaps. But I do believe it's necessary to
handle those issues in a systematic way.

Thankfully, that's not the case everywhere. Thankfully, there are places
with blanket policies permitting usage of free software, and whose
development environments allow any developer to contribute and install a
particular free software package, making it available to the rest of the
organization.

I'm not trying to attack free software in any way. Having
dependencies to non-free software is a lot /more/ troublesome IME.

/Jorgen

 

[kurt krueckeberg]

gcc's libstdc++ does not have regex implemented yet.

I'm running Linux Mint with gcc version 4.7.2. While still experimental, the <regex> header is present, and you can successfully compile and link using regular expressions by suppling the "-std=c++11" argument.

 

[Melzzzzz]

I'm running Linux Mint with gcc version 4.7.2. While still
experimental, the <regex> header is present, and you can successfully
compile and link using regular expressions by suppling the
"-std=c++11" argument.

Yes, you can compile and link but code will not work...

 

[Öö Tiib]

I don't know what you tried to say,

Then read the part that you snipped again. If you just read few first
words and snip the rest then you indeed do not understand what was said.

 

[Öö Tiib]

Well, not exactly true. The fact that Linux kernel is 100% C, does not
changes a fact, that many Linux applications are C++, too.
KDE and all KDE apps are C++ for example...

I did not say that C++ is not used at all there. Certainly it is.
I just object against that constant anti-library movement of Rui Marciel.
If he does not like standard library then fine. There are other libraries.
However the people who like standard library do not deserve to waste weeks
into hacking trivial stuff to work for each gadget.

 

[Jorgen Grahn]

Yes, you can compile and link but code will not work...

This is starting to sound rather unlikely ... care to cite any
references?

The web page I found at gcc.org which claimed "no support at all for
std::regex" was obviously wrong. And now that I bothered to check my
own system, I see that even libstdc++ 4.6 is shock full of regex
implementation.

/Jorgen

 

[kurt krueckeberg]

Yes, you can compile and link but code will not work...
... care to cite any

references?
The web page I found at gcc.org which claimed "no support at all for

std::regex" was obviously wrong. And now that I bothered to check my

own system, I see that even libstdc++ 4.6 is shock full of regex

implementation.

In fact, it seems like the classes and methods in the so-called experimental version of <regex> that is now part of the recent gcc are identical to those in boost (which I've never used, either). The main difference seems theflavors of regular expression supported: Perl compatible support is the boost default, whereas EMCAScript is the default in C++11 and perl support has been dropped.