так, как напечатать знак для кода в телеге?

С айфона никак

c клавы как ?

code example

ну типа ё в англ раскладке

using azaza = template <char Delimiter = ',', char Quote='"'>

да, разобрался уже, спасибо

using azaza = template <char Delimiter = ',', char Quote='"'>

это вроде подобнее, не?

какие аргументы против?

какие аргументы против?

аргументы против - не всё можно через шаблон пихнуьт

пихнуть

это минус

using azaza = template <char Delimiter = ',', char Quote='"'>

Вариант с конкретными экземплярами и тайпдефами wtiter'а на них ловчее

может я хочу Quote как std::string="flkjhsdfljkfgsfjkljgjsdfklgjdfklgjdfklg"

может я хочу Quote как std::string="flkjhsdfljkfgsfjkljgjsdfklgjdfklgjdfklg"

но второй вариант юзабельней имхо

Вариант с конкретными экземплярами и тайпдефами wtiter'а на них ловчее

да, я прекрасно понимаю, что такой подход очень гибкий получается и он мне нравится больше. Но с ним возникает проблема, как наиболее грамотно дать пользователю предефаненые типы для работы с TSV, CSV?

но второй вариант юзабельней имхо

он не расширяется

можно туплу пихнуть

или нет?

и мне внутри кода специально иметь кейс для std::ofstream « std::tuple?

тупл же не умеет выводиться, да?

или умеет?

да, я прекрасно понимаю, что такой подход очень гибкий получается и он мне нравится больше. Но с ним возникает проблема, как наиболее грамотно дать пользователю предефаненые типы для работы с TSV, CSV?

А нужен ли такой оверкилл? Или это часть какой то либы будет?

и мне внутри кода специально иметь кейс для std::ofstream « std::tuple?

в смысле?

А нужен ли такой оверкилл? Или это часть какой то либы будет?

да, это часть либы

в смысле?

ну окей, мне пришёл шаблонным параметром std::tuple. как мне его вывести в поток?

Если книгу Шлее купить не советуете и говорите что это "унылое чтиво", а также что кути часто обновляется, то позвольте спросить: как освоить эту самую кути?

Если книгу Шлее купить не советуете и говорите что это "унылое чтиво", а также что кути часто обновляется, то позвольте спросить: как освоить эту самую кути?

А я советую Шлее. Хоть и уныло, но Шлее + дока по Qt == норм путь

ну окей, мне пришёл шаблонным параметром std::tuple. как мне его вывести в поток?

ну так же как ты и по отдельности бы их выводил

ну так же как ты и по отдельности бы их выводил

std::ofstream « std::make_tuple (1,2,3); Работает?

std::ofstream « std::make_tuple (1,2,3); Работает?

с мой библиотечкой для олимпиадок будет

с мой библиотечкой для олимпиадок будет

ну так просто перегрузку делаешь и окей, не спорю

у меня там и std::hash для туплов/коллекций есть

а так мне надо будет распаковывать

std::ofstream « std::make_tuple (1,2,3); Работает?

std::ofstream << std::get<0>(x) << std::get<1>(x) ...

да блять

вот скажи, у меня генерализованный код, всё ок. И мне отдельную ветку для тупла писать?

а так у меня прилетает абсолютно любое говно на вход, и у меня к нему только одно требование - уметь в std::ofstream.operator«

а так у меня прилетает абсолютно любое говно на вход, и у меня к нему только одно требование - уметь в std::ofstream.operator«

так ясен перец гибчее и расширяемей

ну тогда ебашь первый вариант

если тебе это необходимо

во, но может кто-то подскажет тогда, как мне пользователю предоставить как можно приятнее уже готовые типы для работы с форматами разными?

А готовые тайпдефы типа не подходят?

Тип как со строками в стд

вот пока ты писал, я тоже подумал, что можно конечно так сделать...

то есть типа вот так

Ну я вот это же самое имел ввиду :(

Вариант с конкретными экземплярами и тайпдефами wtiter'а на них ловчее

так, я запутался. Ещё раз - конкретный тайпдеф не сделаешь, если мы имеем сигнатуру диалекта вида

`template <typename Delimiter, typename LineTerminator, typename Quote, typename Comment> struct Dialect { using DelimiterType = Delimiter; using LineTerminatorType = LineTerminator; using QuoteType = Quote; using CommentType = Comment; Dialect(Delimiter delimiter1, LineTerminator lineTerminator1, Quote quote1, Comment comment1) : delimiter(delimiter1), lineTerminator(lineTerminator1), quote(quote1), comment(comment1) {} Delimiter delimiter; LineTerminator lineTerminator; Quote quote; Comment comment; };`

то есть так вот не получится сделать

`template <typename Delimiter, typename LineTerminator, typename Quote, typename Comment> struct Dialect { using DelimiterType = Delimiter; using LineTerminatorType = LineTerminator; using QuoteType = Quote; using CommentType = Comment; Dialect(Delimiter delimiter1, LineTerminator lineTerminator1, Quote quote1, Comment comment1) : delimiter(delimiter1), lineTerminator(lineTerminator1), quote(quote1), comment(comment1) {} Delimiter delimiter; LineTerminator lineTerminator; Quote quote; Comment comment; };`

три для многострочного

то есть так вот не получится сделать

А диалект инстанцировать ?

А диалект инстанцировать ?

а это уже создание обьекта

Грязь типа? Ну а как ещё тут быть?

то есть видишь - в таком варианте мы имеем гибкость, но все эти знаки выходят за границы типа

Грязь типа? Ну а как ещё тут быть?

второй вариант заключался в том, чтобы запихунть все эти знаки в сам тип Диалекта. Но так получается люто негибко

второй вариант заключался в том, чтобы запихунть все эти знаки в сам тип Диалекта. Но так получается люто негибко

Ну вариантов диалекта не так уж много будет по сути

Грязь типа? Ну а как ещё тут быть?

ну вот, такой вариант и остаётся: проинстанциоровать парочку готовых диалектов

Ну вариантов диалекта не так уж много будет по сути

это не беда, что их много. Я дам только парочку пользователю, а там чуть что - пусть сам пишет. Это не проблема

Проблема вот в чём: Есть диалект. И теперь пользователю нужно работать с CSV. Как ему обьявить CSVreader с таким вот решением?

Вспомнился один пиздец https://github.com/brofield/simpleini/blob/master/SimpleIni.h

ERROR: S client not available

как-то так GeneralReader<column_count> reader(CSVdialect);

а я хотел вот так: GeneralReader<column_count, CSVdialect> reader;

но второй вариант как-то не получается, как видите. Если есть идеи, как свести ко второму варианту - я слушаю

Но у меня никак не получилось без падения гибкости

Вспомнился один пиздец https://github.com/brofield/simpleini/blob/master/SimpleIni.h

Какая прелесть

Зайцев, если не сложно можешь коротко обрисовать что нужно.

Или переслать что нужно из чата

Я кажется сталкивался с подобной фичей

Какая прелесть

О, моя школа :)

Зайцев, если не сложно можешь коротко обрисовать что нужно.

да, хорошо. Потому что чувствую, что немного сумбурно вышло. Внимание, длиннопост. Итак, для чего это нужно. Обычная либа с CSV форматом. Почему не взял готовое? Потому что всё, что я нашёл готовое - говно. Это один из немногих случаев, когда приходится садиться за написание своего качественного велосипеда и доведения его до ума. В чём суть либы (конкретно сейчас мы говорим только про часть либы, но не суть): есть класс для записи DSV-like файлов. DSV-like - это CSV, TSV, SCSV и так далее - что придумаете похожее, то и будет писать. Что мы можем в аднном случае конфигурировать? О, список довольно большой: - Символ(строка)-разделитель - Символ(строка)-кавычка - Символ(строка) конца линии - Символ(строка) комментария - Символ(строка) для тримминга - Policy для выставления кавычек (то есть как ставим кавычки: всегда или только на те поле, которые без кавычек нельзя выводить. А может быть только на не числовые значения? простор для фанатзии велик) - Policy для тримминга (триммим всё в строке, или только начало, или только конец. Или вообще не тримим) И это вроде как не всё (я скорее всего что-то забыл). Почему так много? Потмоу что я пишу велосипеды обощённые и не хочу, чтобы кому-то пришлось ещё раз писать всю эту дрянь. Итак, у нас есть столько параметров, и нам нужно как-то запихнуть их в класс Writer. Окей, как? На ум приходит нескольно вариантов: 1) template <typename Delimiter, typename Quote, ...> class Writer{bla-bla-bla}; Какая здесь проблема? Всё очень просто - Вы не сможете передать сами символы сепараторы, кавычки и так далее через параметры шаблона, вы только можете указать их типы. А сами символы вам придётся передавать уже в конструкторе, сохранять их внутри класса и работать с ними. Выглядеть это будет вот так: Writer<char,char> writer(',', '"'); К тому же, если Вы хотите предоставить пользователю уже готовый класс для работы с тем же TSV (а в TSV в качестве сепаратора используется \t, то у вас не получится обьявить такой ТИП (так как мы не можем символы пихать в тип, потому что у нас везде typename, а не char,int,etc.)). Нам придётся давать пользователю уже готовые ОБЬЕКТЫ для работы с этим, чего делать бы очень не хотелось (так как нам же надо тогда давать интерфейс допольнительный для установки выходного потока, так как обьект уже есть). ДА и вообще, готовый обьект - дерьмо. Пользователь должен сам создать Writer тогда, когда ОН хочет, а не я. А я должен дать ему макисльно удобные средства для этого. Вариант мне нравится. 2) template <char Delimiter, char Quote, ...> class Writer{bla-bla-bla}; Сразу отметаем, так как мы тут привязываемся к типам, которые я задам. А если пользователь захочет wchar_t или ещё какую-нибудь свою штуку, которая будет нормально выводится? Сразу отметаем. 3) Улучшение первого варианта через трейты template <typename Dialect> class Writer{bla-bla-bla}; Всё остаётся по аналогии с первым пунктом, только теперь у нас есть набор предефайненых трейтов для разных случаев жизни: TSV, CSV, SCSV, что-нибудь ещё (трейты эти я дам пользователю сам). Если пользователю не понравится, он всегда сам сможет сделать свой трейт и подпихнуть его в мой Writer. (вот пример, как это примерно будет выглядеть: https://pastebin.com/ETfS7r4K) Проблема в том, что снова же обьекты уже трейта будут предефайнены, потому что снова же мы внутренности их инициализируем не в типе шаблона, а уже в конструкторе (подпихиваем, что там за символы внутри будут) Мне этот вариант нравится больше всего. Что скажете?

И почему же у тебя Delimiter и так далее - шаблонный параметр -ТИП , а не хотя бы шаблонный параметр - значение?

И почему же у тебя Delimiter и так далее - шаблонный параметр -ТИП , а не хотя бы шаблонный параметр - значение?

С каких пор в плюсах есть строковые шаблонные параметры-значения?

А, тут символы только

Тогда непонятно

Возможно, я не загрузился ещё?

Да не, все верно

Варианта (2) достаточно. Задавай все разделители в виде простой либо широкой строки, и все. Это будет достаточно.

А кто сказал, что строки можно в шаблоны?

С каких пор в плюсах есть строковые шаблонные параметры-значения?

И я о том же

Может я хочу, чтобы комментарии начинались с std::u32_string

И почему же у тебя Delimiter и так далее - шаблонный параметр -ТИП , а не хотя бы шаблонный параметр - значение?

А какого типа он должен быть? Char, wchar, char16, char32?

Если определю как шаблонный параметр значение, то пользователь не сможет поменять тип его

Я надеюсь, что все поняли, почему я склоняюсь к третьему варианту

да, хорошо. Потому что чувствую, что немного сумбурно вышло. Внимание, длиннопост. Итак, для чего это нужно. Обычная либа с CSV форматом. Почему не взял готовое? Потому что всё, что я нашёл готовое - говно. Это один из немногих случаев, когда приходится садиться за написание своего качественного велосипеда и доведения его до ума. В чём суть либы (конкретно сейчас мы говорим только про часть либы, но не суть): есть класс для записи DSV-like файлов. DSV-like - это CSV, TSV, SCSV и так далее - что придумаете похожее, то и будет писать. Что мы можем в аднном случае конфигурировать? О, список довольно большой: - Символ(строка)-разделитель - Символ(строка)-кавычка - Символ(строка) конца линии - Символ(строка) комментария - Символ(строка) для тримминга - Policy для выставления кавычек (то есть как ставим кавычки: всегда или только на те поле, которые без кавычек нельзя выводить. А может быть только на не числовые значения? простор для фанатзии велик) - Policy для тримминга (триммим всё в строке, или только начало, или только конец. Или вообще не тримим) И это вроде как не всё (я скорее всего что-то забыл). Почему так много? Потмоу что я пишу велосипеды обощённые и не хочу, чтобы кому-то пришлось ещё раз писать всю эту дрянь. Итак, у нас есть столько параметров, и нам нужно как-то запихнуть их в класс Writer. Окей, как? На ум приходит нескольно вариантов: 1) template <typename Delimiter, typename Quote, ...> class Writer{bla-bla-bla}; Какая здесь проблема? Всё очень просто - Вы не сможете передать сами символы сепараторы, кавычки и так далее через параметры шаблона, вы только можете указать их типы. А сами символы вам придётся передавать уже в конструкторе, сохранять их внутри класса и работать с ними. Выглядеть это будет вот так: Writer<char,char> writer(',', '"'); К тому же, если Вы хотите предоставить пользователю уже готовый класс для работы с тем же TSV (а в TSV в качестве сепаратора используется \t, то у вас не получится обьявить такой ТИП (так как мы не можем символы пихать в тип, потому что у нас везде typename, а не char,int,etc.)). Нам придётся давать пользователю уже готовые ОБЬЕКТЫ для работы с этим, чего делать бы очень не хотелось (так как нам же надо тогда давать интерфейс допольнительный для установки выходного потока, так как обьект уже есть). ДА и вообще, готовый обьект - дерьмо. Пользователь должен сам создать Writer тогда, когда ОН хочет, а не я. А я должен дать ему макисльно удобные средства для этого. Вариант мне нравится. 2) template <char Delimiter, char Quote, ...> class Writer{bla-bla-bla}; Сразу отметаем, так как мы тут привязываемся к типам, которые я задам. А если пользователь захочет wchar_t или ещё какую-нибудь свою штуку, которая будет нормально выводится? Сразу отметаем. 3) Улучшение первого варианта через трейты template <typename Dialect> class Writer{bla-bla-bla}; Всё остаётся по аналогии с первым пунктом, только теперь у нас есть набор предефайненых трейтов для разных случаев жизни: TSV, CSV, SCSV, что-нибудь ещё (трейты эти я дам пользователю сам). Если пользователю не понравится, он всегда сам сможет сделать свой трейт и подпихнуть его в мой Writer. (вот пример, как это примерно будет выглядеть: https://pastebin.com/ETfS7r4K) Проблема в том, что снова же обьекты уже трейта будут предефайнены, потому что снова же мы внутренности их инициализируем не в типе шаблона, а уже в конструкторе (подпихиваем, что там за символы внутри будут) Мне этот вариант нравится больше всего. Что скажете?

ты забыл символ для escape

ты забыл символ для escape

Да, точно. Спасибо

Да, точно. Спасибо

но вообще имхо первый вариант норм

как в питоне)

как в питоне)

С него и делается:)

Потому что сделано адекватно

С него и делается:)

ну может тогда нет смысла усложнять с шаблонными параметрами