Ваш путь к классу нарушен (что является общей проблемой very в мире Java).
В зависимости от того, как вы запускаете свое приложение, вам нужно пересмотреть аргумент в -cp
, запись в Class-Path в файле MANIFEST.MF или на вашем диске.
<regex>
был реализован и выпущен в GCC 4.9.0.
В вашей (более старой) версии GCC это не реализовано .
] Этот прототип кода <regex>
был добавлен, когда вся поддержка GCC C ++ 0x была очень экспериментальной, отслеживая ранние C ++ 0x черновики и предоставляя людям возможность экспериментировать. Это позволяло людям находить проблемы и давать обратную связь стандартным комитетом до того, как стандарт был доработан. В то время многие люди были благодарны за то, что имели доступ к возможностям кровотечения задолго до того, как C ++ 11 был закончен, и еще до того, как многие другие компиляторы предоставили любую поддержку , и эта обратная связь действительно помогла улучшить C ++ 11 , Это был хороший ThingTM.
Код <regex>
никогда не был в полезном состоянии, но был добавлен как работа в процессе, как и многие другие биты кода в то время.
Это часто работает с открытым исходным кодом: Release early, release часто - к сожалению, в случае <regex>
мы получили только раннюю часть, а не часто часть, которая завершила бы реализацию.
Большинство частей библиотеки были более полными и теперь почти полностью реализованы, но <regex>
не были, поэтому он остался в том же незавершенном состоянии, поскольку он был добавлен.
Серьезно, хотя кто-то, кто отправляет реализацию regex_search, которая только делает «return false», была хорошей идеей?
blockquote>Это была не такая плохая идея несколько лет назад , когда C ++ 0x все еще продолжал работу, и мы отправили множество частичных реализаций. Никто не думал, что он останется непригодным для использования так долго, поэтому, оглядываясь назад, возможно, он должен был быть отключен, и для его включения требуется макрос или встроенная опция. Но этот корабль давно отплыл. Есть экспортированные символы из библиотеки libstdc ++, поэтому , которые зависят от кода регулярного выражения, поэтому просто удалить его (в, скажем, GCC 4.8) не было бы тривиально.
В этот момент (с использованием std = c ++ 14 в g ++ (GCC) 4.9.2) все еще не принимается regex_match.
Вот подход, который работает как regex_match, но вместо этого использует sregex_token_iterator. И он работает с g ++.
string line="1a2b3c";
std::regex re("(\\d)");
std::vector<std::string> inVector{
std::sregex_token_iterator(line.begin(), line.end(), re, 1), {}
};
//prints all matches
for(int i=0; i<inVector.size(); ++i)
std::cout << i << ":" << inVector[i] << endl;
он будет печатать 1 2 3
, вы можете прочитать ссылку sregex_token_iterator в: http://en.cppreference.com/ ж / CPP / регулярное выражение / regex_token_iterator
std::regex_search
, хотя, см. wandbox.org/permlink/rLbGyYcYGNsBWsaB
– Jonathan Wakely
29 September 2017 в 11:58
Это фрагмент, чтобы определить, реализована ли реализация libstdc++
с препроцессором C:
#include <regex>
#if __cplusplus >= 201103L && \
(!defined(__GLIBCXX__) || (__cplusplus >= 201402L) || \
(defined(_GLIBCXX_REGEX_DFS_QUANTIFIERS_LIMIT) || \
defined(_GLIBCXX_REGEX_STATE_LIMIT) || \
(defined(_GLIBCXX_RELEASE) && \
_GLIBCXX_RELEASE > 4)))
#define HAVE_WORKING_REGEX 1
#else
#define HAVE_WORKING_REGEX 0
#endif
_GLIBCXX_REGEX_DFS_QUANTIFIERS_LIMIT
задано в bits/regex.tcc
в 4.9.x
_GLIBCXX_REGEX_STATE_LIMIT
, определено в bits/regex_automatron.h
в 5+
_GLIBCXX_RELEASE
был добавлен к 7+
в результате этого ответа и является главной версией GCC Вы можете протестировать его с помощью GCC следующим образом:
cat << EOF | g++ --std=c++11 -x c++ - && ./a.out
#include <regex>
#if __cplusplus >= 201103L && \
(!defined(__GLIBCXX__) || (__cplusplus >= 201402L) || \
(defined(_GLIBCXX_REGEX_DFS_QUANTIFIERS_LIMIT) || \
defined(_GLIBCXX_REGEX_STATE_LIMIT) || \
(defined(_GLIBCXX_RELEASE) && \
_GLIBCXX_RELEASE > 4)))
#define HAVE_WORKING_REGEX 1
#else
#define HAVE_WORKING_REGEX 0
#endif
#include <iostream>
int main() {
const std::regex regex(".*");
const std::string string = "This should match!";
const auto result = std::regex_search(string, regex);
#if HAVE_WORKING_REGEX
std::cerr << "<regex> works, look: " << std::boolalpha << result << std::endl;
#else
std::cerr << "<regex> doesn't work, look: " << std::boolalpha << result << std::endl;
#endif
return result ? EXIT_SUCCESS : EXIT_FAILURE;
}
EOF
Вот некоторые результаты для разных компиляторов:
$ gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ ./a.out
<regex> doesn't work, look: false
$ gcc --version
gcc (GCC) 6.2.1 20160830
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ ./a.out
<regex> works, look: true
$ gcc --version
gcc (Debian 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ ./a.out
<regex> works, look: true
$ gcc --version
gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ ./a.out
<regex> works, look: true
$ gcc --version
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ ./a.out
<regex> works, look: true
$ gcc --version
gcc (GCC) 6.2.1 20160830
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ clang --version
clang version 3.9.0 (tags/RELEASE_390/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
$ ./a.out # compiled with 'clang -lstdc++'
<regex> works, look: true
Это абсолютно неподдерживается и полагается об обнаружении частных макросов, которые разработчики GCC поместили в заголовки bits/regex*
. Они могут меняться и уходить в в любое время . Надеюсь, они не будут удалены в текущих версиях 4.9.x, 5.x, 6.x, но они могут исчезнуть в версиях 7.x.
Если разработчики GCC добавили #define _GLIBCXX_HAVE_WORKING_REGEX 1
(или что-то, подсказка hint nudge nudge) в релизе 7.x, который сохранился, этот фрагмент можно было обновить, включив его, а последующие выпуски GCC будут работать со сниппетом выше.
Насколько я знаю , все остальные компиляторы работают <regex>
, когда __cplusplus >= 201103L
, но YMMV.
Очевидно, что это полностью нарушится, если кто-то определит макросы _GLIBCXX_REGEX_DFS_QUANTIFIERS_LIMIT
или _GLIBCXX_REGEX_STATE_LIMIT
вне заголовков stdc++-v3
.
_GLIBCXX_REGEX_IS_OK_NOW_KTHXBAI
в заголовках, поэтому он не забывается - спасибо!
– Jonathan Wakely
16 December 2016 в 19:06