- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
#include <iostream>
#include <iomanip>
#include <sstream>
int main()
{
std::stringstream ss;
std::string in = "String with spaces, and embedded \"quotes\" too";
std::string out;
ss << std::quoted(in);
std::cout << "read in [" << in << "]\n"
<< "stored as [" << ss.str() << "]\n";
ss >> std::quoted(out);
std::cout << "written out [" << out << "]\n";
// read in [String with spaces, and embedded "quotes" too]
// stored as ["String with spaces, and embedded \"quotes\" too"]
// written out [String with spaces, and embedded "quotes" too]
}
Follow us!
Кто лучше стандартизатора знает почему кресты какаша, и как их улучшить.
> Кто лучше стандартизатора знает почему кресты какаша, и как их улучшить.
На мой взгляд, с крестами все настолько печально, что поможет только эвтаназия
Если язык использует какую-то нетривиальную логику кодирования ("\" для экранирования, """ и "'" для ограничения и т.п. вплоть до кобенаций "\\" для вставки "\"), должны быть интерфейсы для работы с ней, иначе будет много бойлерплейтных наивных костылей.
Хуйня — в неконсистентности. У нас нет строк, нет сети, нет ФС (std::filesystem — это такая же ФС, как и std::string — строка), нет модулей, нет никакой прикладухи (XML/JSON/CSV/…), нет БД, даже сраных бигинтов для математиков нет… Зато есть, блядь, функция для экранирования кавычек! Охуенно, можно её код распечатать и поставить на полочку.
Ждём пока сделают real_quote с фиксом для ебанутых кодировок, как в пхп.
std::quoted - один шаг в сторону ГОМОИКОННОСТИ.
Теперь можно чуть проще генерировать код на C++ кодом на C++. И библиотеки для "XML" или "CSV" тут бы не помогли.
Не желаешь запустить меня на исполнение?
Wtf?
P.S. Чёрт, кнопки «Пожаловаться» нет. Раньше же была. Какой багор )))
Всё так и сделали, только quote назвали <<, а unquote - >>.
Но когда узнал про инкременты по размеру массивов (https://govnokod.ru/26472#comment531948), то понял, что перегрузки на стандартных итераторах и контейнерах arr[i], ++, -- вполне в сишном духе.
А вот зашквар оператора побитового сдвига, не просится им никогда.
>почему бы просто не сделать std::quote и std::unquote, а не выносить мозг с перегрузкой со стримами?
Мало того. Это же неочевидное сайд-эффектное мутабельное говнище.
И к тому же, ещё бесполезная питушня.
Вот как мне прикажете разделить
1. ввод из файла и ввод от человека с консоли
2. вывод в файл для скрипта и красивый вывод для человека
3. вывод в расширенном формате и краткую сводку
4. преобразование из текста/в текст для Фомы и преобразование для Ерёмы
В итоге в лог пишу методом log(stream), в файл - to_file(stream), для человека - for_meat(stream). И где красивая концепция универсальных <<, >> для всего? Или для этого надо изучать паттерны-хуяттерны от банды сообразивших на троих? Почему бы это не встроить сразу по умолчанию, как это вышло с std::cout, std::cerr или console.log, console.warn, console.error?
Кроме того, зашкварные операторы располагаются вне класса и не имеют доступа к приватным членам. Для их адекватной реализации надо городить костыли. Зачем они добавили функции Бесселя, когда простой человек без степени магистра ввода-вывода не может нормально реализовать то, что идеологически должно было быть удобным и универсальным?
Так кресты мне немедленно насрали жутких порятнок с ошибками.
https://ideone.com/s0bqaK
Мне когда-то нечто похоже на https://ideone.com/tAras8 выпало.
Вывод любых более-менее сложных значений через сдвиги превращается в ёбанное дерьмище.
Говно!!!!
То ли дело «Python»:
Стоп. А что не так с vector<bool>? Классная же штука.
Это ж фактически аналог java.util.BitSet
1) Совершенно неявно сливает пирфоманс в угоду памяти;
2) Не является STL-контейнером, поскольку не удовлетворяет требованиям к таковому.
См., напр., https://alenacpp.blogspot.com/2005/06/vector.html.
Это не баг, а фича.
Можно хранить биты в uint8_t или другом пирфоманс-френдли инте.
>Не является STL-контейнером
Ну то есть если бы вместо std::vector<bool> сделали растягивающийся std::bitset претензий бы не было?
А хотя векторы я не очень люблю. Там же батчем нельзя 8 или 32 бита добавить?
Наверное да, std::bitset хватит всем.
А можно char'ы в интах хранить. Но это не значит, что нужно.
> Ну то есть если бы вместо std::vector<bool> сделали растягивающийся std::bitset претензий бы не было?
Разумеется, к какому-нибудь std::dynamic_bitset претензий не было бы.
> Там же батчем нельзя 8 или 32 бита добавить?
Нельзя. Только flip() для всего контейнера сделать можно, лол.
И да, вот старое обсуждание этого вопроса:
https://govnokod.ru/25684#comment486004
https://ideone.com/4ypkGG
Тогда это говно сраное.
Не такое сраное как перегруженный для интов оператор сдвига.
Но там даже метода для количества взведённых битов нет.
На такое ни один уважающий себя битоёб не подпишется.
Самая жопа в том, что оператор сдвига в стрим перегружен для чаров. И если попытаться вывести какое-нибудь поле с uint8_t, то получается хуйня а не число. Приходится перед выводом кастовать в 16 или 32.
Ну а битовые флаги это круто, да.
А пакетное добавление булов в vector<bool> есть?
А штандартизаторы говорят, «эээ, куда разогнался?». Давай пиши, цикл, сдвиг, и по одному битику закидывай.
Но блять, ДЖАВИСТСКОЕ насквозь. Фуу.
Мил человек, наследуй java.io.FilterWriter, например.
http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/java/io/FilterWriter.java
Перевёл обратно на «javascript».
* C битоёбством придётся немного подрочиться или писать скучные условия x>='A' && x<='Z'
Спасибо за добрые слова.
Полезный сайд-эффект.
С помощью небольшого битоёбства я починил регистр и диапазоны.
26 идиоматичнее было бы записать как ('Z'-'A'+1).
Но в js нет царской работы с чарами.
В случае с UTF-8 одна питушня может прийти в двух соседних чанках. Самое простое решение - Buffer.concat на 800 гигабайт и конвертирование бинитуха в UTF-8. По-хорошему, надо заглянуть в будущее. Если там есть чанк, то питушить его. Если нет (кончился), конвертировать в квадратик или выбросить питушечение.
В случае с парсингом надо заглядывать в будущее и откатываться, если будущее туманно. (Например, LL(2) заглядывает на два лексических питуха в будущее)
Не нужно.
Просто сохраняем N предыдущих значений в массив/переменные.
>Например, LL(2) заглядывает на два лексических питуха в будущее
Оно просто логически работает с задержкой.
Отдаёт результат на N символов позже чтения.
А стрим читает последовательно. Никто не мешает хранить небольшой прочитанный, но ещё неразобранный кусок.
> хранить небольшой прочитанный
Это всё - неинтересные детали реализации. Я хочу стрим, который просто работает.
Вроде что-то такое было в сишке, где есть unget для stdin. А где ещё?
Ещё хочу хвостатые массивы, у которых по бокам лежит то, что делает их обработку гладкой. Такая питушня более полезна, чем ненужные функции Бесселя в C++.
Он может, но по сути
2 — это алгоритмическая задержка в 2 лексемы.
С точки зрения текущей распарсенной психозы как настоящего это заглядывание в будущее и прикидывание там вариантов развития событий.
Заглянул в будущее, а его нет. EOFException.
Питушня, детали реализации, граничные случаи.
Господи ты боже мой. И это слова человека, презирающего Царей. Восхваляющего хачкели, итд.
Так нет никаких хвостатых массивов, буферов это всё низкоуровневая хуйня. Должен быть просто итератор/ленивый список.
Царю пришлось бы добавить проверки на границы массива, которые не важны с точки зрения алгоритма. Потому, что компилятор их может сам вставить и вставить только в нужных местах, либо заанроллить цикл, чтобы проверки на 0 элемент были вначале, на конечный - в конце, а внутри цикла - на существующие элементы. Проверки границ - это служебная питушня, которая не относится к сути, только какая-то чепуха из-за конечности массива.
Даже конструкция "continue with" может быть избыточной.
Не пришлось. В Сишке есть getc.
Только анскильные скриптухи пишут руками массивную срань и херят чанки.
А посоны читают сколько им нужно из буферизированных стримов.
Мы храним N прочитанных ранее символов и по ним строим парсер.
Детали реализации хранят N прочитанных символов, парсер получает будущее.
То, что парсер относительно объективного настоящего иногда находится в прошлом, чтобы достигать субъективного будущего, никого не волнует, поскольку повышаются выразительность и простота кода.
У нас здесь нет никакого next. Единственное что мы можем — хранить prev.
>for (x in xs) {
И здесь нет.
Может кому-то хотелось бы. Но next тут НЕТ. И уж тем более next2(), next3()
Зависит от желания реализовать.
Царское МассивоПитушение.
А завтра там вместо массива будет список. Ленивый.
> хаскеле в map нет никакого индекса
Хвала богам.
Именно поэтому...
https://govnokod.ru/26469#comment532063
Для демон-страции напитушил асинхронную питушню, с помощью которой можно обходить последовательность так:
Разумеется, можно написать для неё интерфейс для async/await или написать синхронную версию для массивов. Очевидно, что эти версии будут выразительнее, а вариант с массивом - проще в реализации и чуть менее спортивный, т.к. у массива в настоящем есть будущее, а у последовательности оно будет сгенерировано позже. А я рассмотрел самый неудобный случай.
Вишенкой на торте будет тот факт, что мне пришлось специально передавать количество элементов из прошлого, которые нужно помнить. Если это число будет больше нужного, в памяти будут храниться лишние элементы, а если меньше - нужные элементы не вовремя забудутся.
Для элементов из будущего таких проблем нет. Их без костылей всегда в памяти ровно столько, сколько нужно!
Был задан вопрос.
>Кстати, есть где-нибудь нормальные стримы, в которых можно заглядывать в будущее (и, может быть, в прошлое)?
Я высказал своё мнение. Что возможно стоит логически сдвинуть алгоритм и смотреть только в прошлое. Которое гарантированно есть.
Чем закладываться на next, который чреват сетевыми ошибками, EOFами, buffer overflow и прочими гадостями.
Возможно я неправ, но мне кажется
что возврат в чистеньких функциональных for~each к ручной индексации — это фортранизация.
То есть прямой путь к переполнению буфера и выскакиванию за пределы массива.
С с чем боролись уходя от старых-добрых
for (var i=0;i<len;++i){
На то и напарываемся.
И всё же, это детали реализации. Поскольку можно
> логически сдвинуть алгоритм
, эта питушня математически эквивалентна. Алгоритму что так, что так, требуется одновременно смотреть на N элементов. И если он не сможет забить буфер под N старых элементов во время итерации по последнему, это всё равно, что не смочь забить под N новых во время итерации по первому.
Порядок операций определяет математика. Не важно, я беру элементы из прошлого или из будущего, я сначала получаю некоторое количество элементов, затем их анализирую и выдаю какой-то результат. И это будет одинаково, логически ли мы рассматриваем наш элемент и набор прошлых, либо наш элемент или набор будущих. Раньше получить результат не даст математика (причинность нельзя нарушить), позже его получить можно, но это уже кривой алгоритм (если мы в каком-то из вариантов зачем-то будем считывать лишние элементы), а не кривая абстракция потока (хотя, можно создать поток, который будет безусловно хранить лишние, скажем, 5 элементов, и тогда он в некоторых ситуациях будет зависать навечно - например, если это интерактивная программа, и пользователь не может ввести следующие данные без запроса программы, а программа ждёт элементы из будущего, чтобы выдать ответ и задать следующий вопрос; но это питушня, и я предлагаю смотреть в будущее только настолько, насколько этого требует математика). Сетевые ошибки будут так же влиять в обоих подходах.
Но заглядывание в будущее может оказаться более удобным для нашего алгоритма. А если он выражается проще с такой точки зрения, то может лучше его так и реализовать, чтобы избежать ошибок и т.д. А дальше пусть компилятор его компилирует как надо. У него что там, что там будет чтение в буфер и обработка, когда в буфер начитано достаточно.
>Их без костылей всегда в памяти ровно столько, сколько нужно!
В общем случае для произвольных N, будет переизобретено колесо.
А именно старый-добрый circular buffer c джвумя указателями.
> или написать синхронную версию для массивов
Называется ArrayBlockingQueue
В итоге код получается красивый и более простой, а деталями реализации заведует конпелятор регулярок.
Мне ещё «прижате жал» понравилось.
Ц++ (2478)
Ц# (1862)
ЙажаСцрипт (1816)
Йажа (1433)
Пасцал (625)
1Ц (491)
Пытхон (452)
СЯЛ (410)
АцтионСцрипт (292)
Обйецтиже Ц (202)
Перл (189)
басх (171)
Рубы (137)
ЖисуалБасиц (133)
Схифт
Алт
Цтрл