- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
#include <string>
#include <sstream>
#include <iostream>
int main() {
std::string str;
std::stringstream s("");
std::getline(s, str, '|');
std::cout << "good=" << s.good() <<
" bad=" << s.bad() <<
" fail=" << s.fail() <<
" eof=" << s.eof() << std::endl;
return 0;
}
bormand 30.09.2013 08:05 # 0
bormand 30.09.2013 08:39 # +13
С древних времен программисты разделились на два лагеря: остроконечников и тупоконечников. Остроконечники всегда заканчивали свои файлы на LF или че там использовалось на их оси (LF - терминатор). А тупоконечники заканчивали файл сразу после последнего символа последней строки, не ставя лишний по их мнению LF (LF - сепаратор). Из-за этого раздора, код ньюфагов то недочитывал пару символов в конце строки, то читал лишнюю пустую, то вообще повторял последнюю строку джважды, чем доставлял им море баттхертов...
Крестостандартизаторы, глядя на этот цирк, решили как-то устранить эту проблему в своей либе. Единственным решением оказалась установка failbit не только при чтении за конец файла, но и при чтении злополучной "пустой" строки...
Жизнь была бы простой и безоблачной, если бы они добавили отдельную функцию gettoken(), в которой этого костыля бы не было...
bormand 30.09.2013 09:05 # 0
spivti 30.09.2013 13:20 # −1
anonimb84a2f6fd141 30.09.2013 18:03 # −1
bormand 30.09.2013 19:01 # +1
anonimb84a2f6fd141 30.09.2013 19:41 # +1
bormand 30.09.2013 20:11 # +1
Например если в потоке у нас "a|b", и мы вызываем std::getline(stream, buf, '|'), то при первом вызове мы получим buf = "a", при втором buf = "b" и установленный eofbit у стрима. Если вызвать его еще раз, то ничего не прочитается, и у стрима включится failbit, и вылетит исключение (если оно разрешено).
Если бы все так и работало, достаточно было бы включить режим исключений у потока, и тупо вызвать по getline'у на каждый токен (и проверить stream.eof(), если хочется убедиться, что стрим дочитался до конца). При нехватке токенов вылетело бы исключение.
Но из-за описанной выше питушни, если в потоке было "a|", при первом вызове мы получим buf = "a", а при втором ничего не прочтется, установятся сразу оба флага - eofbit и failbit и вылетит исключение. Поэтому такой простой подход уже не прокатит, и надо отключать исключения, и втыкать проверки после каждого токена... Что неприятно.
anonimb84a2f6fd141 30.09.2013 21:52 # +1
bormand 01.10.2013 05:14 # 0
Отсутствие оного.
anonimb84a2f6fd141 01.10.2013 19:45 # −1
bormand 01.10.2013 21:52 # +1
А альтернативу я нашел: boost::tokenizer или boost::split.
anonimb84a2f6fd141 03.10.2013 17:24 # −1
3Doomer 02.10.2013 12:07 # −1
Stertor 03.10.2013 17:46 # −1
Кто минуснул?!
anonimb84a2f6fd141 03.10.2013 19:14 # 0
Stertor 03.10.2013 19:29 # 0
Dummy00001 30.09.2013 16:07 # −2
Это деление только у глупых программистов, которые не знают как делать FSM для lexer'ов/parser'ов.
bormand 30.09.2013 16:21 # +1
Причем здесь это? Различия то начинаются еще при записи в файл - тот же vim считает LF терминатором, и добавляет \n к последней строке, а тот же notepad, считает LF сепаратором, и не добавляет. Как FSM для getline'а поможет в борьбе с различиями при записи в файл?
Максимум, чего можно добиться навелосипедив getline - это нормальная работа с обеими форматами. Но ведь он и так это умеет. Зачем изобретать то, что уже прекрасно работает?
А вот gettoken да, можно и написать. Но согласитесь, а не лучше ли было бы, если бы он был готовый, и его не приходилось каждый раз писать заново? В сишке же есть strtok. Он хоть и уёбищен, но есть.
P.S. За что мне поставили минус в комменте про boost::tokenizer я вообще не понял.
Dummy00001 30.09.2013 17:32 # 0
Важно не то как оно пишется в файл. Важно то, можно ли оттуда прочитать.
getline() очевидно неправильная функция если тебе нужно читать потенциально битые текстовые файлы и/или файлы с неизвестным заранее разделителем.
"Но ведь он и так это умеет. Зачем изобретать то, что уже прекрасно работает?"
Пример в ГК (и мой личный ограниченый опыт) как бы намекают что оно весьма далеко от "прекрасно."
"В сишке же есть strtok. Он хоть и уёбищен, но есть."
Много лет назад читал от скуки /usr/include/string.h и наткнулся на strpbrk(). Почитал ман, порадовался жизни, и после этого перестал трахатся с strtok(). Рекомендую.
bormand 30.09.2013 17:56 # 0
Пример в ГК использует getline не по назначению (из-за того, что авторы не удосужились сделать отдельный gettoken без описанного выше костыля). Отсюда и проблема. А для чтения строк из файла он вполне адекватно себя ведет.
> с неизвестным заранее разделителем
Ну тут да, придется свой парсер-детектор написать.
> strpbrk
Спасибо, не знал про эту функцию ;) Удобно.
wvxvw 30.09.2013 19:11 # +2
Юникс писался армянской диаспорой в Чехословакии...
Stertor 03.10.2013 22:30 # −1
Снимаю шляпу) Эти слова нужно написать на табличке перед входом на сей сайт.
bormand 30.09.2013 16:30 # +1
roman-kashitsyn 30.09.2013 16:37 # +5
bormand 30.09.2013 16:39 # 0
roman-kashitsyn 30.09.2013 17:55 # +3
bormand 30.09.2013 18:11 # +2
P.S. http://govnokod.ru/12937 :)
guest 01.10.2013 06:59 # +2
Прочитать float константу в переменную lon
[Прочитать >>]
Пропустить 1 или более пробелов
[Прочитать >>]
Прочитать float константу в переменную lat
Соответственно если сматчилось, то используем, иначе обрабатываем ерор. В [] написано то, в чем я сильно не уверен и скорее всего это (а в этом я уверен) просто связующий\разделяющий символ.
LispGovno
bormand 01.10.2013 07:09 # 0
Так и есть.
> сразу понял
Да понять то можно... Ты написать попробуй... Там с действиями в [ ... ] траблы в основном, кресты это ж не ленивый хаскель...
P.S. Хотя траблы с [ ... ] это уже не к спирту, а скорее к фениксу и т.п.
guest 01.10.2013 07:12 # 0
Например? Действия в неожиданном порядке вызываются в соответствии с порядком приоритетов?
bormand 01.10.2013 07:17 # +4
Ну и компилится спиртосодержащий код просто пиздец как долго... Не говоря уж о портянках с ошибками, после которых обычные бустовские кажутся несущественными и маленькими.
1024-- 01.10.2013 08:05 # 0
Кстати, не знаете, есть ли относительно простое (для анскильных питушков) и подробное руководство по Spirit на более-менее русском языке? Желательно, чтобы там охватывалась старая версия (classic) и новая.
А то статьи с примерами обычно пишут в стиле "Давайте напишем Hello, world, теперь распарсим списочек вида a,b,c,d,e;. Смотрите, как всё просто и понятно! Теперь вы знаете Спирит!" Иногда ещё внезапно начинают использовать Phoenix, хотя мозг читателя ещё не отошёл от всей мощи Spirit'а.
Да, документация - это хорошо, но лучше бы почитать в более художественной форме на родном языке.
defecate-plusplus 01.10.2013 08:36 # 0
вы вообще с какой целью интересуетесь? для продакшена спирит в коде - не самый приятный инструмент
bormand 01.10.2013 10:34 # 0
Угу. Для серьезных грамматик что-то в духе bison'а и удобнее и быстрее, и ошибки внятные дает... Простенький скриптовый интерпретатор (процедурное подмножество сишки или паскаля) без замашек на производительность на связке bison+flex ваяется за вечер...
А для простых грамматик можно что-нибудь навелосипедить. Выйдет короче и понятней чем спирт. А главное компилиться будет быстро ;)
1024-- 07.10.2013 17:30 # 0
В основном - для своего развития и повышения компетентности.
Довелось мне писать парсер. Буст использовали не самый новый, новоспирита там ещё не было. Парсер работает, подкрутить грамматику для изменений в будущем я могу, но не чувствую контроля над ситуацией.
Хотелось бы всё осознать и отвязаться если не от периодических заглядываний в документацию, то хотя бы от периодических заглядываний в примеры.
crastinus 01.10.2013 21:14 # +1
qi::rule<string::const_iterator,int()>
развернутое до POD будет выглядеть так:
http://pastebin.com/YGnTLEtE
roman-kashitsyn 01.10.2013 21:21 # +2
Stertor 03.10.2013 22:31 # 0
Dummy00001 30.09.2013 17:37 # 0
мелкую FSM (которая будет правильно обрабатывать отсутствие последнего перевода строки) можно и в десяток строк вместить. даже FSM ее не обязательно называть.
можно чуть больше строк написать и "нагородить" еще и нахождение терминатора строки.
потому что даже с strtok() тебе все равно нужно состояние что бы определить что после последнего разделителя нет больше строки vs. есть пустая строка.
bormand 30.09.2013 18:07 # 0
А с getline'ом файл отлично обрабатывается и без FSM (т.к. подобная FSM инкапсулирована в сам getline).
У меня проблема то возникла при парсинге сообщений в духе "111|222|aaa|bbb". Начал писать к парсеру тесты, и напоролся на этот failbit при "111|222|aaa|". Подключил boost::tokenizer (т.к. свой gettoken писать банально и скучно, а разобраться с незнакомым мне куском буста не повредит), и пошел плакаться на ГК ;)
Dummy00001 30.09.2013 18:28 # +2
в некоторых случаях я забиваю на эффективность, и делаю аналог перлового/этц split() с помощью string::find_first_of (C++ аналог strpbrk), сигнатура:
догадываюсь что тормозит, но по барабану - потому что мне важнее что работает надежно.
bormand 30.09.2013 18:41 # +1
> догадываюсь что тормозит
Если не гигабайтные файлы парсить - не будет :)
> важнее что работает надежно
+1
roman-kashitsyn 30.09.2013 18:49 # +2
bormand 30.09.2013 18:57 # +1
P.S. Хотя с другой стороны split, возвращающий вектор, может сразу найти какие-то форматные ошибки. А с итератором мы о них узнаем только в ходе разбора.
roman-kashitsyn 30.09.2013 19:00 # +2
bormand 30.09.2013 19:09 # 0
roman-kashitsyn 30.09.2013 19:18 # +1
Задачка тут у нас есть - преобразовать большой xml в много маленьких json. Проблема в том, что используемые xml и json библиотеки работают через коллбэки, вызывая функторы с соответствующими объектами на входе. Обе хотят управление, что в плюсах неудобно.
Мораль: люди, делайте нормальные итераторы, пишите пулл-парсеры, не забирайте управление.
bormand 30.09.2013 19:23 # +1
roman-kashitsyn 30.09.2013 19:31 # +1
bormand 30.09.2013 19:40 # +1
Хотя с DOM'ом оно бы неплохо скрестилось.
> Почему так сделали, я не знаю.
Поди под работу с DOM'ом или подобными иерархиями заточено.
gost 11.04.2019 17:21 # +1
PACTPOBblu_nemyx 11.04.2019 18:21 # 0
Steve_Brown 11.04.2019 18:35 # 0
Впрочем, вопрос о максимальном уровне вложенности уже вызывает вопросы. Что ты такое хочешь сделать, извращенец?
BOKCEJIbHblu_nemyx 11.04.2019 18:39 # +1
Ну проверять незакрытые/лишние скобки то надо.
Steve_Brown 11.04.2019 18:44 # +2
PACTPOBblu_nemyx 11.04.2019 18:55 # +3
https://ideone.com/HdzxT8
PACTPOBblu_nemyx 11.04.2019 19:01 # +1
gost 11.04.2019 19:58 # +1
PACTPOBblu_nemyx 11.04.2019 20:27 # 0
Мы уже работаем над тем, чтобы пофиксить это в следующей версии.
OCETuHCKuu_nemyx 11.04.2019 20:47 # 0
/fixed
Steve_Brown 11.04.2019 19:37 # 0
- А вот она!
OCETuHCKuu_nemyx 11.04.2019 20:43 # 0
gost 11.04.2019 19:56 # +1
http://rapidjson.org/md_doc_sax.html
Причём есть даже «PrettyWriter», который на выходе даст отформатированный JSON.
gost 11.04.2019 20:03 # +1
http://rapidjson.org/md_doc_faq.html
BOKCEJIbHblu_nemyx 11.04.2019 18:34 # 0
Dummy00001 30.09.2013 19:16 # 0
твой сплит ничего не возвращает. к нему join() не прикрутишь: join( sep1, split(str, sep2) ); (или еще лучше: join( sep1, apply( split(str, sep2), func1 ) ); )
и в добавок можно всегда результат на экран дампнуть.
в добавок генерализировать токое, по личному опыту, уже давно не пытаюсь. если мелкие тривиальные разницы типа: сплит по строке, сплит по набору символов, мержить соседние сплитеры или нет, сплитить только первые Н подстроки (хвост целеком пихать в последний элемент).
PS я скопипастил сигнатуру именно из того одного места где у меня сплит не имеет аргумент разделитель! он там в пробелы захордкожен (симулирует split /\s+/).
bormand 30.09.2013 19:20 # 0
Он третьим аргументом передаст какой-нибудь join_iterator:
Dummy00001 30.09.2013 19:31 # +1
но мне все равно писание задом наперед, к чему С++ с итераторами и функтоидами подталкивает, не нравится.
я предпочитаю прямолинейный функциональный код.
собственно говоря, первый split()/join() (а так же keys() и values() для мапов) у меня в С++ появились когда меня просто трахание с итераторами достало в одном пруф-оф-консепт'е. тормозило заметно, но работало.
до этого еще пытался эмулировать слайсы с помощью std::pair<iterator,iterator>, но оно сосало немеряно (в оссобенности когда второй итератор инвалидировался).
bormand 30.09.2013 19:48 # 0
Да не, все-таки итераторы это не задом-наперед. Ну а вообще - итераторы удобны только для потоковой обработки. Если надо рандомный доступ - лучше ваши split'ы и join'ы (или их Qt'шные аналоги, если проект на Qt).
roman-kashitsyn 30.09.2013 19:26 # +4
Функциональщиной в крестах балуетесь?
continuation passing style же
Dummy00001 30.09.2013 22:06 # +2
только же опять задом наперёд...
bormand 01.10.2013 05:15 # +1
Forth :)
anonimb84a2f6fd141 30.09.2013 18:20 # +1
А что, русского термина нету? Конечный автомат же.
guest 01.10.2013 22:53 # −3
остроконечников, тупоконечников и хуеконечников
guest 04.10.2013 14:14 # +2
Dummy00001 30.09.2013 16:30 # +2
лично по граблям не ходил, но наблюдал людей которые пытались обработать ошибки ввода в iostream. как правило их отличает от нормальныю людей тенденция стучатся головой по стенке. в паре мест у нас народ просто забил и переписал на stdio.
к слову, по крайней мере в старой версии гнутой stl, можно было добится что бы все четыре флага были выставлены. последовательности уже не помню, но по сырцам я ее находил. а по сырцам я лазил пытаясь понять накой фиг их там 4ре и чем они отличаются друг от друга.
ЗЫ Согласно вот этому: http://www.cplusplus.com/reference/ios/ios/fail/ - "failbit is generally set by an operation when the error is related to the internal logic of the operation itself;" Другими словами std::getline() призналась что в ней есть ошибка... Вообщем вынос мозгов.
bormand 30.09.2013 16:34 # 0
failbit в этом месте вполне логичен для основного применения getline: Но вот для других разделителей он там только мешается.
bormand 30.09.2013 16:43 # 0
Ну вернее как. Он вполне логичен как костыль, позволяющий работать с файлами обеих типов одинаково, не обрабатывая лишнюю пустую строку.
roman-kashitsyn 30.09.2013 16:39 # 0
bormand 30.09.2013 16:49 # +7
Stertor 01.10.2013 19:45 # −4
То-то я смотрю, как распухают дистрибьютивы линукса (это при том, что ядро весит около ~100 мб), а он как был жопой, так ей и остается. Не зря их логотип напоминает сфинктер с геморроидальными шишками.
guest 01.10.2013 20:54 # −10
crastinus 01.10.2013 21:04 # −1
guest 01.10.2013 21:14 # +3
Stertor 01.10.2013 22:54 # −5
anonimb84a2f6fd141 02.10.2013 00:06 # 0
anonimb84a2f6fd141 03.10.2013 17:25 # +1
Stertor 03.10.2013 19:31 # 0
anonimb84a2f6fd141 03.10.2013 19:54 # 0
Stertor 03.10.2013 19:55 # 0
TarasB 04.10.2013 14:23 # 0
anonimb84a2f6fd141 07.10.2013 19:12 # 0
LispGovno 04.12.2013 20:49 # 0
crastinus 01.10.2013 21:02 # 0
~3 мб
> он как был жопой, так ей и остается.
.NET в винде весит каких-то 1.5 ГБ, а она как оставалась жопой так и остается.
Я ведь рассказывал о работе своих прог в винде. Когда .NET 4 прогу я переношу с семерки на хрюшу половина функционала исчезает))
guest 01.10.2013 21:12 # 0
crastinus 01.10.2013 21:15 # −1
guest 01.10.2013 21:17 # +1
crastinus 01.10.2013 21:20 # 0
guest 01.10.2013 21:24 # +1
crastinus 01.10.2013 21:32 # −2
Разрабатывал прогу в платформонезависимом фреймворке, перенес ее на чуть другую платформу с тем же фреймворком и не работает. Это нормально?
bormand 01.10.2013 21:54 # +4
P.S. Кстати 4.0 или 4.5, не помню какой точно, на хрюше уже не идет.
guest 01.10.2013 21:57 # 0
bormand 01.10.2013 22:02 # +3
Да почему, может быть 4.0 еще идет, а 4.5 - уже нет. Я не помню когда они поломали совместимость, т.к. первый и последний .net, под который я кодил неделю-две имел версию 2.0 :)
Просто я недавно пытался поставить на виртуалку 2013ю визуал студию экспресс, и нужный ей фреймворк не встал на хрю. Пришлось корячить семерку в виртуалбокс...
guest 01.10.2013 22:50 # 0
Виртуалишь?
3.14159265 08.10.2013 13:32 # +4
Жабу, ту и вовсе используя различные ухищрения можно компилить и запускать хоть под 1.4 и ниже, хоть под 1.1.
Байт-код ведь всё тот же. Проблемы только с новыми классами, которые можно собрать и подложить. И новой моделью памяти в 1.5.
Stertor 08.10.2013 14:33 # 0
+1
anonimb84a2f6fd141 05.12.2013 03:04 # 0
crastinus 02.10.2013 05:59 # −1
anonimb84a2f6fd141 02.10.2013 00:12 # −1
crastinus 02.10.2013 05:58 # −1
anonimb84a2f6fd141 02.10.2013 00:12 # −1
TarasB 04.10.2013 14:24 # +1
guest 04.10.2013 15:20 # +1
Stertor 04.10.2013 16:18 # 0
bormand 04.10.2013 16:59 # 0
Stertor 04.10.2013 18:19 # 0
defecate-plusplus 04.10.2013 18:23 # +1
многие системные вещи были написаны, переписаны и дописаны
даже есть нюансы между сервис-паками сраной xp, о чем и говорить
или ты хочешь сказать, что апи 15 летней давности должно хватать и поныне?
Stertor 04.10.2013 18:36 # 0
У Вас, простите, все в порядке?
Коды ошибок иные, во всяком случае на дельфях. Я уже обжегся. Я просто имею в виду, что суть неизменна. Иначе это была бы уже не винда.
Stertor 04.10.2013 18:27 # +2
кого она еще стоит, главное, чтобы прога на xp/vista/7 шла, и т.п. -
но я не такой человек! Пришлось упорно колдовать. Окончательный вариант: прога определяет версию ОС и в зависимости от
этого включает ту или иную отрисовку.
Кстати, Delphi 7 работает начиная с win98 и кончая семеркой, а вот Delphi 2009 и все последующие - уже нет, так как они юникодные.
anonimb84a2f6fd141 07.10.2013 21:38 # +1
bormand 08.10.2013 06:23 # +1
Он на делфи 6 вроде написан. И автор обновляться вроде как не собирается. Есть вероятность, что у него винда 9х, и в ней больше ничего не идет...
P.S. А в той же кутишке где-то до 4.3 были и юникод и поддержка 98 винды. :)
P.P.S. А еще в 98й вроде бы нет поддержки больших файлов (4 гига и больше), т.к. еще не было 64 битных перемоток, да и фат один хер такие файлы не понимает.
anonimb84a2f6fd141 08.10.2013 06:44 # +1
Stertor 08.10.2013 14:37 # 0
Гисслер до сих пор сидит на 2-ой или 3-ей Делфи. Я был в шоке, когда узнал. Что это - нежелание раскошеливаться на новый компилятор или попытка сохраненить свой статус "тру-кодера": (форма готовая есть, классы есть, руки есть, голова есть. Что еще надо для кодинга???)
TarasB 08.10.2013 15:12 # 0
anonimb84a2f6fd141 05.12.2013 03:05 # +1
anonimb84a2f6fd141 05.12.2013 03:28 # +1
>Есть и приятные моменты. Например, полная поддержка Unicode в TC была написана мной вручную, тогда как в Lazarus все контролы изначально поддерживают Unicode и базируются на UTF-8.
anonimb84a2f6fd141 05.12.2013 17:15 # +1
Я являюсь обладателем лицензионных версий всех последних Delphi, поэтому я достаточно хорошо представляю себе их возможности. Но дело тут вот в чем: компиляция exe-файла в Delphi 2 дает на выходе файл, ощутимо меньший по размеру, чем, например, в Delphi 7. Кроме того, тестирование показывает, что exe'шник из-под Delphi 2 работает заметно быстрее, чем его полный аналог, выпущенный компилятором Delphi 7. Я сталкиваюсь с тем, что люди часто удивляются, что Total по-прежнему работает очень быстро. Я собираюсь сохранить эту его особенность, и отчасти секрет тут в правильно выбранном компиляторе.
Добавлю, что, кроме того, Delphi 2 генерирует очень универсальный код, например, с полной поддержкой 16-битовых приложений или Windows 95/98 - у меня до сих пор хватает таких клиентов. В то же самое время TC прекрасно себя чувствует и в Windows 7.
Stertor 05.12.2013 17:40 # +2
сказал одну очень умную мысль, которая запала мне в душу: не стоит
увлекаться скинами - интерфейс такой программы выглядит вычурно на фоне
остальных окон.
anonimb84a2f6fd141 05.12.2013 18:26 # +1
anonimb84a2f6fd141 06.12.2013 00:05 # 0
Для плееров конечно же.
crastinus 07.10.2013 21:09 # 0
anonimb84a2f6fd141 02.10.2013 00:09 # +1
bormand 02.10.2013 08:23 # +1
Да не, у андроида совместимость годная. Ну настолько, насколько ее вообще можно сделать годной для такого зоопарка устройств и осей.
Тут дело скорее в писателях софта, которые не хотят париться и поддерживать 2.х (меньше стандартных компонентов, нету некоторых апишек, или же нужно подключать compat либу, чтобы они эти апишки юзать и т.п.), и выбирают минимальное сдк повыше...
anonimb84a2f6fd141 03.10.2013 17:26 # +1
Stertor 04.10.2013 16:19 # 0
Yuuri 02.10.2013 10:46 # +3
PACTPOBblu_nemyx 11.04.2019 16:29 # 0
guest8 10.04.2019 17:01 # −999
guest8 10.04.2019 17:02 # −999
guest8 10.04.2019 17:04 # −999
guest8 10.04.2019 17:05 # −999
guest8 10.04.2019 17:25 # −999
guest8 10.04.2019 17:25 # −999
guest8 10.04.2019 17:25 # −999
guest8 10.04.2019 17:26 # −999
guest8 10.04.2019 17:26 # −999
guest8 10.04.2019 17:26 # −999
guest8 10.04.2019 17:26 # −999
guest8 10.04.2019 17:27 # −999
guest8 10.04.2019 17:27 # −999
guest8 10.04.2019 17:27 # −999
guest8 10.04.2019 17:28 # −999
guest8 10.04.2019 17:28 # −999
guest8 10.04.2019 17:28 # −999
guest8 10.04.2019 17:29 # −999
guest8 10.04.2019 17:29 # −999
guest8 10.04.2019 17:29 # −999
guest8 10.04.2019 17:30 # −999
guest8 10.04.2019 17:30 # −999
guest8 10.04.2019 17:30 # −999
guest8 10.04.2019 17:31 # −999
guest8 10.04.2019 17:31 # −999
guest8 10.04.2019 17:31 # −999
guest8 10.04.2019 17:31 # −999
guest8 10.04.2019 17:32 # −999
guest8 10.04.2019 17:32 # −999
guest8 10.04.2019 17:32 # −999
guest8 10.04.2019 17:33 # −999
guest8 10.04.2019 17:33 # −999
guest8 10.04.2019 17:33 # −999
guest8 10.04.2019 17:34 # −999
guest8 10.04.2019 17:34 # −999
guest8 10.04.2019 17:34 # −999
guest8 10.04.2019 17:35 # −999
guest8 10.04.2019 17:35 # −999
guest8 10.04.2019 17:35 # −999
guest8 10.04.2019 17:35 # −999
guest8 10.04.2019 17:36 # −999
guest8 10.04.2019 17:36 # −999
guest8 10.04.2019 17:36 # −999
guest8 10.04.2019 18:20 # −999
guest8 10.04.2019 18:20 # −999
guest8 10.04.2019 18:20 # −999
guest8 10.04.2019 18:21 # −999
guest8 10.04.2019 18:21 # −999
guest8 10.04.2019 18:21 # −999
guest8 10.04.2019 18:21 # −999
guest8 10.04.2019 18:22 # −999
guest8 10.04.2019 18:22 # −999
guest8 10.04.2019 18:22 # −999
guest8 10.04.2019 18:22 # −999
guest8 10.04.2019 18:23 # −999
guest8 10.04.2019 18:23 # −999
guest8 10.04.2019 18:23 # −999
guest8 10.04.2019 18:23 # −999
guest8 10.04.2019 18:24 # −999
guest8 10.04.2019 18:24 # −999
guest8 10.04.2019 18:24 # −999
guest8 10.04.2019 18:24 # −999
guest8 10.04.2019 18:25 # −999
guest8 10.04.2019 18:25 # −999
guest8 10.04.2019 18:25 # −999
guest8 10.04.2019 18:25 # −999
guest8 10.04.2019 18:26 # −999
guest8 10.04.2019 18:26 # −999
guest8 10.04.2019 18:26 # −999
guest8 10.04.2019 18:26 # −999
guest8 10.04.2019 18:27 # −999
guest8 10.04.2019 18:27 # −999
guest8 10.04.2019 18:27 # −999
guest8 10.04.2019 18:27 # −999
guest8 10.04.2019 18:28 # −999
guest8 10.04.2019 18:28 # −999
guest8 10.04.2019 18:29 # −999
guest8 10.04.2019 18:29 # −999
guest8 10.04.2019 18:29 # −999
guest8 10.04.2019 18:30 # −999
guest8 10.04.2019 18:30 # −999
guest8 10.04.2019 18:30 # −999
guest8 10.04.2019 18:30 # −999
guest8 10.04.2019 18:31 # −999
guest8 10.04.2019 18:31 # −999
guest8 10.04.2019 18:31 # −999
guest8 10.04.2019 18:31 # −999
guest8 10.04.2019 18:31 # −999
guest8 10.04.2019 18:32 # −999
guest8 10.04.2019 18:32 # −999
guest8 10.04.2019 18:32 # −999
guest8 10.04.2019 18:32 # −999
guest8 10.04.2019 19:31 # −999
guest8 10.04.2019 19:31 # −999
guest8 10.04.2019 19:31 # −999
guest8 10.04.2019 19:32 # −999
guest8 10.04.2019 19:32 # −999
guest8 10.04.2019 19:33 # −999
guest8 10.04.2019 19:34 # −999
guest8 10.04.2019 19:34 # −999
guest8 10.04.2019 19:35 # −999
guest8 10.04.2019 19:35 # −999
guest8 10.04.2019 19:36 # −999
guest8 10.04.2019 19:37 # −999
guest8 10.04.2019 19:37 # −999
guest8 10.04.2019 19:37 # −999
guest8 10.04.2019 19:38 # −999