Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+8
//список строк
QStringList rows_list = text.split("\n");
uint32_t row=0;
uint32_t col=0;
for(QStringList::iterator itR=rows_list.begin(); itR!=rows_list.end(); itR++,row++)
{
QStringList columns_list=itR->split(";");
col=0;
for(QStringList::iterator itC=columns_list.begin(); itC!=columns_list.end(); itC++,col++)
{
//*itC,row,col
}
}
Человек осилил итераторы в с++...
(для тех, кто не в теме - QStringList имеет доступ по индексу за константное время)
А еще мне нравятся uint32_t вместо int или, на худой конец, quint32.
Запостил: 
ABBAPOH,
22 Февраля 2013
Follow us!
Ну хорошо, осилил, и?
К чему тут про какой-то доступ по индексу за константное время. Без разницы связный список это или массив - тут я не вижу "доступ по индексу" вообще. Доступо по индексу(*(ptr+N*sizeof(e))) и разименование(*ptr) - эт совершенно разные вещи.
И да, int пишут либо для мистической "переносимости", либо от тупой привычки. Норм пацаны всегда юзают unsigned там, где не должно что-то опускаться ниже нуля, а неосиляторы орут про переполнение. Дядя страустрп пытался вас приучить к тайпдефам нормальным, но зачем вам это надо? Инт есть всегда, он прост - тыкай везде.
int - пишет лох(в 99.9% случаев), uint32_t(quint32) - пишет про пацан, который ниодно проблемы с переносимостью не встретит( а дурочки будут дальше ныть про то, как сложен "митический рефакторинг под амд64"). А ещё более про пацаны для временных переменных юзают fast_t размером с регистр и не страдают фигнёй.
Ну а тайпдефы кути ущербны(имхо) и нужны для переносимости. Но юзайте, юзайте, иначе защитники недокнпеляторов закидают меня какахами.
Ну а так - говно, показывает Суть ООП. Как вайл-моностроку без тела заменяют на стопицот строк, а потом пишут "ваш Си говно, надо писатьмногострок". Просто смишно. Ну и работает всреднем раз в 10медленней.
Про доступ по индексу - это было к тому, что раз он считает row/column (это нужно для того, чтобы засунуть в таблицу), то их можно было использовать как а) счетчик б) как средство доступа к текущей строке - уменьшение производительности было бы минимальным. Итераторы нахрен не нужны в данном куске кода.
Про int. На _всех_ мне известных архитектурах размер инта _строго_ 32бита. И это сделано как раз потому, чтобы не ломать переносимость - ни один разраб компилера, находясь в здравом уме, не будет делать int 64битным.
Кроме того, ф-ии qt-контейнеров, такие как count(), indexOf() - все возвращают int. Поэтому использовать unsigned неудобно - компилер будет выдавать кучу варнингов про каст от signed к unsigned.
Писать quint32 тоже абсолютно бессмысленно в данном случае, так как нас абсолютно не волнует размер счетчика (см пункт 1) - даже если int каким-то чудом окажется 64битным, то всё будет спокойно работать (16 битные платформы, вроде, уже умерли).
И? Будешь тут писать unsigned long int, а там int, а там uint32_t, а там uint64_t? Аргументация на уровне детсада. Я говорил о тайпдефах в целом, а не о инте.
Ну естественно там инт, ибо оно возвращает -1. А почему инт в count() - это вопрос к коду кути, который говно( чего стоит боязнь указателей в одном куске кода и юзанье их уже 10строками ниже, где без них можно обойтись). Поэтому оно тормазное говно.
Нет. Писать не unsigned, юзать для временных переменных( включая счетчики) int. Это всё говорит о полном незнании архитектуры на которой пишешь, и языка в частности.
Хотя конечно, наверное круто везде писать int и на каждом чихе проверять if(n > 0), как это делается в кути.
Хотя с кути ладно, он писался для полных неосиляторов и если пацан напишет в конструкторе сайз -1, то ничего не будет, а вот если будет uint32_t, то его приятно удивит count(), вернувший UINT32_MAX.
Пусть робатет, ведь как работает не важно - важно чтобы работало. Логично, ничего не скажешь.
Расскажите, пожалуйста, в каком именно месте Qt тормозит?:) Желательно, предоставив бенчмарки. Я могу предоставить мини-бенчмарк, сравнивающие std::vector и QVector/QList, сравнение не в пользу std::
Юзаю кеды, не аргумент? Ладно. Писание гуйни на кути+разгребание тонн говнокода на кутикоре тоже?
Твои бенчмарки? Зачем ты мерил говно с говном? Ты мерий вектор с malloc(100500*100500). Или ты до сих пор веришь в нужность реалока и выделение памяти?
Так тонко, что даже толсто... Тогда уж лучше заниматься писькомерством соно работает еще быстрее, выделяясь за одну ассемблерную команду.
Да и не в этом суть. Суть в том, что универсальность тормазит. Кути не тормазит, стл не тормазит - тормазит их универсальность. Эта новомодная погоня за универсальностью. Она порочна - она не нужна.
>>высокоуровневыйЯП
/0
Если вы не умеете применять о-нотацию на практике - ваши проблемы, именно она помогла в свое время оптимизировать айтеммодели-вьюхи в рабочем проекте.
Кеды не аргумент совершенно, они написаны в совершенно другом стиле, нежели Qt (боже, они d_ptr в каждом классе заново открывают, с чего оно будет быстро работать?)
Вы пишете гуй на Qt и не знаете, что QList - вектор? Океееей.... "Тонны говнокода на кутикоре" - это НА коре или В коре? Кажется, что говнокод - это личные трудности тех, кто не умеет использовать Qt, нет?
Окей, какие контейнеры не говно?:) Буст интрузив? Кажется, что сравнивать с ними - это будет теплое с мягким.
Я мерил вектор как с преаллоком (на 10^9 элементов), так и без (на 10^4 итераций аппенда минимум) Здесь http://mtgs.clan.su/stlvsqt.zip какая-то из версий; эксперименты с другими типами данных и преаллоком можете произвести сами.
Также было бы прикольно, если бы кто-то написал бенчмарк, сравнивающий хеши/мапы (не уверен, что метод, представленный здесь http://habrahabr.ru/post/170017/ даёт правильные результаты, тк кол-во итераций в Q_BENCHMARK иногда очень сильно разнится, могу предположить, что это происходит из-за сильных разбросов => подсчет кол-во итераций за 1 сек может давать неверный результат)
О-натация бесполезна чуть более, чем полностью, ибо работает она в твоих мечтах. То, что ты там что-то "оптимизировал" и как - для меня не аргумент. Уж банальности, про O(n) почти всегда быстрее O(1) до определённого n - я тебе писать не буду. А уж про собенности работы с памятью. Да что я тебе рассказываю.
Я похож на идиота, которы йбудет юзать кутикор? Уж максимум, что я буду юзать - это стл. Я тебе уже привел пример говна в кути. Да, говна и в кутикор и на кутикоре.
Я тебе написал, что не говно( хотя сам малок то ещё говнецо) malloc(100500*100500) - на него ровняйся. Все приплюснутые контейнеры говно, ибо интерфейс ставится во главу угла, ибо мозг 95% не может хранить много сущностей.
Твой тест говно - хз чё он мериет. Ну подобавлял ты туда много раз одну и туже строку, и? Возьми для начала мильёнчик уникальных слов.
Мапы, хеши. Всё твои мериния универсального говна порочны. Вот берёшь какую-то реальную задачу и уже на ней мериешь. Там ты уже можешь и над вариантами хранения строк подумать и над правильной реализацией деревьев, так и над подходящяй хеш-функцией.
А так - это всё детсад и ясли. Абсалютно бесполезно.
Так точно. Бенч на реальном сценарии (или на упрощенном, но приближенном к нему) намного полезней субъективных бенчей хуйпоймичего.
> Прилепи к нему вектор указателей на елемент, который будет обновляется каждую вставку/удалении.
Тогда зачем тут связный список?
Молодец, ты почти наступил на ахилесову пяту ООП. ООП, как мир абстрактного работает только с абстрактным. Когда же дело доходит до реального мире - адепты ООП пытаются съехать с темы и съюлить и свести разговор к "безопасности", "универсальности".
Про реальный мир, почему я хаю ООП - патамучто запилить тот же вектор под свои данных, со своим удобным и не избыточным алокатором(либо без него, если ваще хардок) и премлемой шустростью РЕАЛЬНО проще, чем адаптировать универсальный контейнер.
Универсальный контейнер нужен для быстрого прототиповаяния, когда нужно быстро сваять какую-то байду на один раз( для чего собственно и были придуманы скриптовые ЯП). Но мы понимаем, что в 99.(9)% случаев прототип никогда не будет переписан. Поэтому весь программо-мир скатился в говно и жив засчёт дешевой рабсилы и железа.
А мозг 5% может хранить чуть-чуть больше сущностей. При этом если этот мозг ослаблен простудой или вчерашней попойкой, или его периодически отвлекают от работы коллеги, то он работает ничуть не лучше чем мозг оставшихся 95%.
Вы предлагаете не разбивать задачу на подзадачи? Не использовать уже существующие наработки и тратить время на разработку всего с нуля и самостоятельно? Помилуйте, сейчас процессоры и плашки оперативки намного дешевле оплаты труда хорошего программиста...
Да, можно все писать с нуля. Да, мне тоже иногда хочется позаниматься байтоебством или для души реализовать какие-то новые алгоритмы самому. Но это совсем не повод не юзать уже проверенные и отлаженные алгоритмы, которые чуть-чуть медленнее чем собственное решение, на написание (и тестирование с отладкой, а потом и поддержку) которого уйдет драгоценное время...
Широкое мышление это на милиметр шире, а на порядки, на сотни порядков шире. Это как длинна причинно-следственных цепочек, когда у 95% - это 2-3звена, а у 5% тысячи.
Поэтому 95% и пытаются придумать себе мирок, ограниченный мирок. Этот мирок должен быть ограничен 10-20абстракциями с 1-2смыслами( почему неосиляторы не любят Си, ибо один символ - множество действий.).
>Вы предлагаете не разбивать задачу на подзадачи? Не использовать уже существующие наработки и тратить время на разработку всего с нуля и самостоятельно? Помилуйте, сейчас процессоры и плашки оперативки намного дешевле оплаты труда хорошего программиста...
Да нет же. Я считаю, что программист - это человек, который вмещает в себе все уровни абстракций начиная с софтварного уровня. Его сознание и код не должен ограниваться парадигмами, языками( но тут тоже спорно, ибо вменяемых ЯП 2-3штуки 2 из которых - это сиасм), теорией, О-нотацией, примитивами, готовыми шаблонами и т.д. т.п.
Е.Замятин, "Бог"
> Поэтому 95% и пытаются придумать себе мирок, ограниченный мирок
Если бы. 95% пишут нечитаемую кашу, имеют слабое представление о модульности и построении правильных абстракций. Гениальный код настолько прост, что понятен с первого взгляда, и в нём, очевидно, нет ошибок.
В соседнем треде упоминались GNU-style и сорцы Emacs. Так вот, сорцы Emacs (во всяком случае, сишную часть) я считаю хорошо написанными (пролистывал как-то на досуге пару лет назад). Мне не импонирует gnu-style, но код мне показался весьма простым. И, кстати, с абстракциями там всё впорядке. Для меня подобный код является примером для подражания.
Из знакомых мне кодобогов только Линус на словах весьма прохладно относится к абстракциям, но это скорее от склонности к троллингу. Вам до него далеко, это точно. Его троллинг - недостижимая вершина мастерства.
Вот код выше - пример того, как пишут люди с ООП-говного мозга. Эту байду из 20строчек(10, если напишет автор) можно заменить strchr+вайл на 1-2строки.
Да суть ен абстракциях - суть в том, что про-пацан никогда не ограничен парадигмой. Он пишет в ООП-стеле не потомучто ООП - это модно и недля ООП ради ООП, а только потому, что ООП в данном случае понятней, удобней и просто лучше.
Все тролли троллят не абстракции, а ограниченное мышление, увязщие в абстракциях ради абстракций. Я не пытаюсь троллить или т.п. Его троллинг отчасть успешен тем, что никто ему не скажет, что он школьник-неосилятор и т.п.( как мне в соседнем треде написали - не нравится стл - напиши лучше).
У меня есть ещё лет 25-30 есть чтобы дорости до великого линуса.
Странно, раньше такая форма фимоза встречалась мне только среди лисперов.
Ты ещё не рассылаешь жывтоне по биореакторам, не?
Фу. Загуглив я увидел такую противную гадость.
О5 непонимание. Это возможность дана тому, кто может объективно оценить код - т.е. тому, кто это сам может реализовать. Но её требуют люди, которые САМИ сложнее хелворда НИЧЕГО НАПИСАТЬ НЕ МОГУТ - они полностью не компитентны во всём, начиная от архитектуры, заканчивая уровнем ОС и прокладухи.
Их мнением движет вендор и маркетолог и желание поменьше делать, а результата иметь побольше. Они пытаются юзать твои аргументы, аля "зачем мне байты - всё уже написано, я ИЛИТА, преждевременная оптимизация, оптимизация для лохом, идите сами трахайтесь со своими битами". Но мы понимаем, что за твоими слова стоит ВОЗМОЖНОСТЬ и УМЕНИЕ реализовать ЭТО САМОМУ, а за их ТОЛЬКО не желание учиться.
Предоставь.
>>сравнение не в пользу std::
У вектора из STL есть такие штуки, как growth factor и аллокатор, изменяя которые, можно варьировать его производительность за счет потребления памяти.
Потокобезопасный COW (а в кутишке он потокобезопасный) тоже далеко не бесплатен...
На самом деле, глупо говорить "std::vector быстрее, чем QList" или "QList быстрее, нежели std::vector". Производительность - не одномерная величина. Можно говорить только "при таком-то сценарии использования XXX окажется выгоднее чем YYY". И поэтому бенчмарки, заточенные под один сценарий, совершенно бесполезны, если контейнеры будут использоваться по-другому.
Да, COW не бесплатен, зато имеет ряд плюсов (как-то возможность оптимизировать скорость QVector/QList под них), которые компенсируют его медленную скорость.
*С потолка == мне лень выписывать нули перед значащими разрядами.
Насчет сценариев - можно протестить _все_ варианты использования контейнеров (я протестил те, к-ми часто пользуюсь - аппенд, препенд, вставку) и судить по ним. Очевидно, что любая задача может быть декомпозирована на ряд операций и если ВСЕ операции контейнера А лучше, чем опреации контейнера B, то вполне можно судить, что лучше.
Дык тут не скорость вставки в вектор сравнивается, а скорость конструктора копирования у стринга. Естественно COW строка копируется быстрее, чем std::string, который копируется полностью. А если сравнивать std::vector<QString> и QVector<QString>, имхо, разница будет в пределах погрешности, и не в пользу QVector.
Да, и std::string тоже использует COW
Не факт. Реализаций STL немало, где-то могут использовать, а где-то - нет.
В других реализациях может не быть, тут вы правы.
http://goo.gl/IFoLO
Спасибо, статья интересная. Не сказать бы, что что-то новое узнал, но структурирование информации всегда полезно.
Кстати, вариант D как-то совсем плох в случае юникод строк, врядли он где-то сейчас используется?
Что значит "неправильно" применяют? vector<QString> всяко удобнее и безопаснее, чем vector<QString*>, но без COW первое будет сильно медленее в ряде случаев => оно неправильное?
Я в курсе. Но на сценариях, в которых надо бегать по вектору и править его элементы, COW сказывается не самым лучшим образом - хотя настоящее расщепление произойдет максимум один раз, проверка будет выполняться на каждой итерации. Можно, конечно, вызвать data() и работать с массивом...
P.S. Забавный коммент в исходниках QVector:
На самом деле, там переписали QVector/QString/QByteArray поверх одного класса - QArrayData
16 битные рахитектуры?
> quint32 бессмысленно
контейнеры больше чем на 2 гига?
нет, не слышал
выдать count() и size() в signed int - это пиздос, даже не верится, что в qt настолько все плохо
Ну во-первых на реальных 32-битных системах больше чем 2 гига все равно не дают (да, в некоторых извращенных конфигурациях можно добыть 3 и даже 4, но это именно извращенные конфигурации, не самым лучшим образом влияющие на работу ядра). Во-вторых на 64-битной системе этот quint32 стал бы новым искуственным ограничением на 4 гига минус 1 байт. Поэтому только size_t/ptrdiff_t, только хардкор.
Ну что тут ответить. Отвечу только то, что Qt это не STL, который должен охватить все-все-все сферы применения, и поэтому просто обязан иметь возможности для тюнинга. А для большинства GUI приложений кутишных контейнеров вполне достаточно.
пока что это всё выглядит так, что праотцы накосячили в интерфейсе (потому что в лихие 90-е они развлекались как могли, и 2 гига "хватит всем"), и более того, сделали очевидное беззнаковое знаковым, потому что "ну компилятор то ругается, когда я как дебил переменную цикла объявляю int, это определённо недостаток контейнера"
а теперь это называется "другой путь", ну-ну
аллокаторы это не странная попытка абстрагироваться, это совсем другое
но они работают как нужно только начиная с 11 стандарта (это к комменту про пулы)
На 64битной системе всё лучше, на данные приходится гораздо больше места, мы можем использовать не только чары:)
Вот только засовывать массив такого объема в память - всяко хреновая идея...
Насчет праотцов - в Qt это могли поменять уже 4 раза (во 2й..5й версии). Очевидно, раз это не сделано (а в 5ке QMap/QVector/QString/QByteArray полностью переписаны), то врядли дело в обратной совместимости. Просто это не нужно никому. В память не влезут такие контейнеры.
Там в QVector используется malloc с интовым параметром, поэтому ограничение не в два гигаэлемента, а именно в 2 гига памяти. В QList, если я не туплю, удастся запихать до 512М элементов, даже очень больших.
> поиметь 3 гиговый контейнер
А вот эта проблема, имхо, надуманная. В 99% случаев такие гигаконтейнеры не нужны. А в тех случаях когда программе реально нужен такой объем данных (более 500 миллионов элементов в одном контейнере) - всяко нужно что-то более узкоспециализированное, заточенное под конкретную задачу, а не QVector и не QList и даже не std::vector.
Qt - прежде всего платформа для разработки GUI приложений, а для 99.99% таких приложений 3 гиговый контейнер, действительно, не нужен.
слишком предсказуемо
"если это не сделано в кутэ, значит это не нужно никому"
вместо того, чтобы признать, что знаковый результат для категории "количество" - абсолютно притянутое за уши ограничение, которое безболезненно исправляется, и другой причины, как "я пeшу цикл for (int i = из учебника, а компилятар ругаеться!" этому нет
Правильнее будет так: "если это не исправлено в кутэ, значит тролли не хотят без особо веской причины ломать совместимость с существующим софтом" ;)
> абсолютно притянутое за уши ограничение, которое безболезненно исправляется
Не совсем за уши. Если мы исправляем size(), то нужно исправить и indexOf() и аналогичные ему, т.к. кому нужен контейнер, в котором можно найти не все элементы? Придется возвращать какой-нибудь not_found = ~0 или вообще выпилить indexOf() и юзать только итераторы. Оба решения не очень хорошо скажутся на существующем коде переломав его к хуям.
что мешает сделать QVector::QNPos? видимо, они передрались из-за того, сколько букв q и в каком регистре придется засовывать, и остановились на -1
про совместимость - выше же было отмечено, что в мажорных версиях все и так переписано
Вон в гугле запрещены исключения по документам и все счастливы использовать аналог MayBe-типа.
Реализации поправили, а интерфейсы то не изменили. Значит или его величество похуизм, или действительно боятся поломать совместимость.
Ну не брать же им пример с питона 3. Там все переписали стремясь к идеалу, и где теперь этот питон 3? Сколько лет прошло, а в большинстве линуксов по дефолту стоит второй...
"Это никому не нужно", значит "это не нужно тем, на кого ориентирована Qt". А ориентирована она, хоть и не только на гуи приложения, но не стремится покрыть все возможные юзкейзы.
Если встает вопрос о том-нужен ли контейнер, в к-и можно разместить 2^64 элементов, то int в методе size() - это последнее, о чём стоит волноваться. Для начала стоит выкинуть refcount (ибо копировать ТАКИЕ контейнеры самоубийственно), во вторых, подумать в сторону интрузив, в третьих-выкинуть редблек три в мапе и переписать ее на b-tree.
Если же вас волнует не размер, а знаковость/беззнаковость, то не могу понять, чем. Писать != -1 гораздо удобнее и понятнее, чем никому не понятный std::string::npos. Код должен быть простым, а введение npos и size_t его лишь усложняет, но не дает ничего взамен. Нет, ну серьезно, зачем вам вообще нужен unsigned?) потешать самолюбие "я всегда пишу unsigned и const и мой код всегда работает верно"?)
Вы еще не используете const? Тогда мы идем к вам.
Объявлять же локальные переменные как конст считаю излишним, мой вброс был именно про это - конст локалки, конст инт как возвращаемое значение ф-ии и тп.
авотхуй. -1 лишено семантики
0 тоже лишен семантики, ну и что?
Однако в большинстве случаев я юзаю смарт поинтеры а там как правило есть приведение в bool.
А вот сравнение разных типов меня бесит
А что плохого?
Ну COW для таких структур (а мы рассматриваем контейнеры на 3 гига и больше) совершенно бесполезно т.к. никто в здравом уме не допустит detach'а, копирующего 3 гига. Поэтому проверки счетчика в не const методах будут зазря жрать такты.
Стали стейтфул? А каким образом это поможет прикрутить пулы?
> нет, не слышал
Да, не слышал.