- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
if ( _It->m_sOpenText.substr( 0, 3 ) == "<tr" ||
_It->m_sOpenText.substr( 0, 3 ) == "<th" ||
_It->m_sOpenText.substr( 0, 3 ) == "<td" ||
_It->m_sOpenText.substr( 0, 6 ) == "<thead" ||
_It->m_sOpenText.substr( 0, 6 ) == "<tbody" ||
_It->m_sOpenText.substr( 0, 6 ) == "<tfoot" ||
_It->m_sOpenText.substr( 0, 8 ) == "<caption" ||
_It->m_sOpenText.substr( 0, 4 ) == "<col" ||
_It->m_sOpenText.substr( 0, 9 ) == "<colgroup" )
return; // TODO: я пишу ТАКОЙ код, убейте меня...
потому что до сих пор ни в бусте, ни в стандарте.
я radix tree/patricia trie уже пару раз писал, включая раз на битовом уровне. удовольствия мало. уже как лет 7-8 с последнего раза прошло - и никакой штатной реализации так до сих пор и не появилось.
чтобы в редких случаях получить необходимое значительное ускорение, а в остальных - незначительное
но в данном примере, кстати, достаточно было бы unordered_set:
после имени html тега явно идёт пробел
значит легко вычленить name() из тега (если это до сих пор не сделал богоугодный парсер) - т.е. 1 конструктор std::string и сделать find оного в сете
Не факт:
<td>some content</td>
Лучше ориентироваться на первый не алфавитно-цифровой символ.
привык к хорошему, давно не приходилось парсить xml/html вручную, и надеюсь, never again :)
Последний (он же первый) раз, парсил xml вручную года 4 назад из-за совместимости с другим ёбнутым на голову велосипедистским парсером\генератором, который экранировал символы совсем не так, как это положено делать в настоящем xml...
Искренне надеюсь, что больше такого не потребуется :)