Вы видите копию треда, сохраненную 14 августа 2016 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Старый ОП, который
Насаждал к искусству жаркий пыл в сердцах,
Из Dерьма восстанет,
И прекрасен станет
Тред, в котором лабы пишут на крестах.
Шапку он наполнит,
Свой обет исполнит,
Вам на суд являя новые стихи;
Музы скальда живы,
Но в своих призывах
Будьте терпеливы, братья крестухи.
Старший брат: >>780630 (OP)
Предыдущий: >>786424 (OP)
TL;DR
Q: Я хочу тотчас вкатиться, а разбираться буду в процессе. Что я должен делать?
Q: Не уверен, что хочу изучать C++. Как мне пощупать его без лишней ебли?
A: Читаешь эту книжку, смотришь упражнения из нее и суешь в онлайн-компилятор. Сообщения компилятора об ошибках копипастишь в гугл, ответы на возникающие у тебя вопросы ищешь в предыдущих тредах, спрашиваешь в этом треде, если не нашел. Если тебя послали на хуй или не ответили, то ты спросил платину, читай предыдущие треды внимательнее.
Памятка ньюфагу
- Вопросы по синтаксису идут на хуй
- Лабы идут на хуй
- "Как мне сделать Х на чистых крестах без библиотек" идут на хуй
- Все идут на хуй
- Хейтер сосет члены на пару со своей мамашей
Небольшие фрагменты кода размещай в треде при помощи тега [code] и жабаскрипт-костыля. Для больших фрагментов используй внешние сервисы.
FAQ
Мотивация
Q: Почему стоит использовать именно C++?
A: Ни один язык не идеален, но по совокупности киллер-фич C++ оставляет все остальные языки позади. Вот основные три:
- Скорость
C++ действительно быстрый язык — вместе с C, его прародителем, они с большим отрывом уделывают по скорости все остальные языки высокого уровня. Код на C++, как правило, медленнее аналогичного кода на C приблизительно на 0-20% а в ряде случаев C++ оказывается даже быстрее, причем замедление появляется только при использовании высокоуровневых конструкций (в C++ ты никогда не платишь за то, чего не используешь). Таким образом, если тебе требуется высокопроизводительный код, C++ станет отличным выбором. - Мощь
C++, являясь одним из наиболее выразительных и мощных языков, позволяет использовать большинство существующих парадигм. Его философия построена на минимальном ограничении программиста в выборе методов и инструментовпростреливания ногирешения задачи. Как следствие, используя C++, ты можешь не думать о том, как обойти искусственные ограничения языка, а беспрепятственно выбрать наиболее подходящие к ситуации средства. - Популярность
C++ по-настоящему популярен. На нем написаны десятки тысяч приложений и миллиарды строк кода, о нем написаны сотни книг, он до мельчайших подробностей документирован и стандартизован. Используя C++, ты никогда не останешься без работы или поддержки комьюнити.
Литература
Q: Окей, я решил вкатиться. Какие же книги мне читать?
A: Специально для тебя аноны /pr собрали уникальную коллекцию отборной литературы по крестам. Только лучшие книги, последние издания, без хуев! Выбирай категорию и обмазывайся:
-
Для нюфань
Учебники для начинающих. Все примерно одинаковой годноты, читать имеет смысл только какой-нибудь один, который больше приглянется:
Автор(ы) Название Год Ссылка Бьерн Страуструп Программирование. Принципы и практика использования C++ 2016 https://yadi.sk/i/Yd6KKpLBqJSUr Стэнли Липпман, Жози Лажойе и Барбара Му Язык программирования C++ 2014 https://goo.gl/kVaela Стивен Прата Язык программирования C++ 2012 https://goo.gl/z7kA8u
Другие обучающие материалы
Q: Я не умею читать.
A: Можешь посмотреть какой-нибудь онлайн-курс: раз, два, три
Q: Не люблю, когда льют воду. Хочу коротких материалов по существу.
A: Вот тебе блоги, факи, референсы и всякое такое:
- Годный блог, в котором все просто и понятно тян не нужны кококок борщ
- Блог с хорошо расписанными фичами новых стандартов
- Краткие описания библиотечных функций и контейнеров - на русском или более подробно на ангельском
- Блог Герба Саттера (на ангельском)
- Блог Скотта Мейерса (на ангельском)
- Блог еще одной тянки, много о Qt и оптимизации (на ангельском)
- Куча других блогов (на ангельском)
- Большой FAQ по C++ (на ангельском)
- Видео с CppCon (на ангельском)
Софт и библиотеки
Q: Я готов начать погроммировать! Куда мне писать код?
A: На этапе написания хэллоуворлдов можно не ебаться с установкой софта, а использовать онлайн-компиляторы: раз, два, три, четыре. Для работы над более серьезными вещами удобнее всего установить какую-нибудь IDE. Ниже приведены несколько хороших вариантов:
Платформа | Название | Описание | Ссылка |
---|---|---|---|
Windows | Microsoft™ Visual Studio® | Общепризнанно самая продвинутая и удобная IDE, не имеющая равных по части автодополнения и возможностей отладчика. По ссылкам справа можно скачать бесплатную редакцию последнего выпуска (2015 Community Edition). Кроме того, существуют редакции с расширенными возможностями (Professional и Enterprise). Они стоят сотни денег, но если ты студент вуза, подписанного на Dreamspark Premium, то ты можешь получить их безвоздмездно (то есть даром). Многим новичкам интерфейс студии кажется чересчур сложным, так что обязательно прочти этот гайд, если у тебя возникают проблемы с компиляцией хэллоуворда | https://goo.gl/qgAAc6 (русская версия) или https://goo.gl/WIPW9L (ангельская версия) |
Все | CodeLite | Простая, легковесная, кроссплатформенная, швабодная IDE. Менее навороченная, чем студия, но среди бесплатных вне конкуренции. Вероятно, это наилучший вариант для новичка с *nix. Под Windows же требует чуть больше ебли с установкой компилятора MinGW/LLVM | http://codelite.org/, "sudo aptitude install codelite codelite-plugins" для установки под *nix |
Все | CLion | IDE, призванная похоронить Visual Studio пока не особо получается. Она стоит денег, но можно украсть почти не протухшую версию на торрентах или получить бесплатную лицензию на год по скану студбилета, если ты студент. Удобные свистелки и перделки присутствуют. Тормоза и баги присутствуют. Кросплатформенность присутствует | https://www.jetbrains.com/clion |
Q: Я прочитал все вышеперечисленное, теперь я гуру! Что дальше?
A: Дальше переходишь по ссылке, пробуешь отвечать на вопросы и понимаешь, что ты пока в самом начале пути. Кроличья нора крестов практически бездонна, поэтому продолжать постигать тонкости и детали можно очень и очень долго. В то же время, на этом этапе у тебя должно быть достаточно знаний, чтобы уверенно писать неплохой код. Поэтому читай исходники открытого софта и библиотек, отправляй пулл-реквесты в них, читай книжки по предметным областям и общим методикам разработки, а дальше уже сможешь запилить свой проект или вкатиться в существующий.
Погоди, дай тоже примостить сраку.
Имхо, если ты выбираешь между крестами и жабой для мобильной разработки с нуля, не зная ни того ни другого, то лучше начать с жабы. Во-первых, в NDK тебе все равно потребуются как минимум базовые знания жабы, потому что там осуществляется активное взаимодействие твоего кода с жабным. Во-вторых, из-за общей заточенности андроида под жабу имеет смысл использовать кресты только когда тебе требуется что-то довольно производительное, типа вычислений или игрового движка. Иначе ты просто будешь воевать со своим инструментом, а код будет состоять из адаптеров к жабным методам.
Но вообще это интересная тема, так что лучше поставить, если есть лишние 5ГБ. Я поставил, все заработало без ебли, отладка на девайсе работает, эмулятор работает.
Проблема следующая, начал 2 дня назад изучать С++, короче при попытке вывести стандартный халоворлд в консоли нихуя не выводится, хотя часа два назад всё выводилось как надо, а щас нихуя... В душе не ебу в чём проблема гуглил нихуя толкого не нашёл, может объяснит кто ссаному ньюфагу в чём проблема?
#include <iostream>
using namespace std;
int main() {
cout << "Nassal nufagy za sheky!\n";
return 0;
}
VS Express 2013
[Указанные ниже фреймы могут быть неверны и (или) отсутствовать, символы для kernel32.dll не загружены]
ну ладно, все я не дуюсь
ну меня улыбнуло)
> Решил проблему добавлением строчки system("pause");
Ты что ли двойным щелчком запускал консольную программу? Да, крестобляди совсем деградировали.
Бьерн Страуструп
Программирование. Принципы и практика использования C++
По этой книжке начал вкатываться по совету в ОП посте.
>>798123
F5)))))))))))))
> F5)))))))))))))
Проверил. Какое же все-таки говно эта студия. В консольных C# приложениях после завершения подставляет pause, а в таких же C++ приложениях - нет.
> F5)))))))))))))
>Проверил. Какое же все-таки говно эта студия. В консольных C# приложениях после завершения подставляет pause, а в таких же C++ приложениях - нет.
Ты лалка, Ctrl-f5 нажимай. А вообще, нехуй запускать консольщину из шум. Bash поставь, если линупс не осилил.
Олимпиадники как всегда производят нечитаемый кал вместо кода. Найс.
Тебя уже кто-то обосрал выше по треду же, хуле не исправляешься?
Правильно, но это не критично.
Зоделой интерфейс с абстрактными операциями, а затем нахуячь наследников с реализациями под разные архитектуры.
http://man7.org/linux/man-pages/man8/ld.so.8.html#NOTES
Hardware capabilities
Some shared objects are compiled using hardware-specific instructions
which do not exist on every CPU. Such objects should be installed in
directories whose names define the required hardware capabilities,
such as /usr/lib/sse2/. The dynamic linker checks these directories
against the hardware of the machine and selects the most suitable
version of a given shared object.
СериализацЭЯ будит?
Нда, едем на черепахе.
Могли бы уж в какой-нибудь TR занести статическую рефлексию.
Сети из коробки нету. Дичь.
> Нда, едем на черепахе.
Главное, что не туда едем.
> Сети из коробки нету. Дичь.
Дичь была бы если бы она была.
filesystem будет — это дичь.
Всякие сферические функции — дичь.
Отсутствие uhash — дичь
Таки я пекусь о здоровье местных постояльцев
Такую сеть, как в boost::asio, я бы и даром не взял. И вообще, это же вам не примитивные смарт поинтеры, которые всем одинаково хороши, тут каждому нужна своя сеть. Кому-то надо низкоуровщину с сокетами, кому-то - пару легких классов как в libcurl, кому-то - монструозную хуйню с continuations типа касабланки... Поэтому подходить надо очень вдумчиво, а не просто тащить всякое дерьмо в стандарт.
Ладно, хуй с ней, с этой сетью, что душе угодно, можно нарыть. Однако, где моя рефлексия, когда ее введут блять, я буду сериализовать все классы.
запили реализацию в clang, допили существующие пропосалы, вот и появится. Стандарт - это ж некоммерческий opensource, на обычных мимокрокодилах все держится.
> Стандарт - это ж некоммерческий opensource, на обычных мимокрокодилах все держится.
https://isocpp.org/files/img/foundation-members-2016.jpg
Вот уж действительно манямирок. Только у тебя. Если бы организации плотно инвестировали время разработчиков в C++, у нас бы давно был аналог .NET или Swift. Это ясные примеры того, как впрягаются большие компании. А у нас есть полурандомы из гугла, эппла, мс, которые на своей инициативе пилят стандарт. Концепты - 3.5 анонимуса, networking - 3.5 анонимуса, модули - по 5 анонов в гугле и мс. Диапазоны - вообще 1, лол.
Увы, но ты не прав.
Не, дотнет-то я ещё понимаю, гигантская платформа на все случаи жизни и тд.
Но что в этом перечислении делает свифт-то? Кусок говна, который меняется со скоростью дорелизного раста и на нём не написано ничего кроме пары гуй-приложунек? даже интерфейсы cocoa и foundation до сих пор ненативные. Так же криво развивался разве что D – только у него не четырёх сотен миллиардов долларов за спиной.
Тут можно привести в пример Go – сам язык говно, но вы понели.
Я согласен, что swift как-то ниоче, просто привел его как пример, когда впрягается большая компания. Go можно отнести туда же. А вот D - это как раз хороший пример хорошего языка, на который похуй корпорациям.
2 стандартные библиотеки, вечно молодой, пьяный и меняющийся язык, куча разных компиляторов. До недавних пор кроме DMD не было ни одного полноценно работающего компилятора, поддерживающего хотя бы половину позапрошлого стандарта.
Тот же Брайт только и занимался и занимается тем что коммитит "уменьшение аллокации памяти на 0,7% в функции" вместо развития стандартной библиотеки и инфраструктуры. До срача на, блядь, реддите несколько лет назад бы ужасно текущий GC. Сейчас до сих пор 3 человека не могут сойтись во мнении – сделать всё таки нормальный сборщик, продолжать сосать хуй из-за оверхеда барьеров записи в 1-5% для тех, кто не использует этот самый сборщик при том что язык без него полноценно не работает, или всё таки запилить 2 бинарно несовместимые версии.
Ещё можешь посмотреть за текущий https://wiki.dlang.org/Vision/2016H2 а потом за прошлые года, и посмотреть что же сделали.
Ты серьёзно спрашиваешь что не так с его развитием?
>Тот же Брайт только и занимался и занимается тем что коммитит "уменьшение ал
Для полноты картины: в самом компиляторе, а не кодогенераторе.
А что не так-то? Нюфаг в ди коммунити не верит? Врёти? Или читать не умеем и определять пршедшее время?
Они были одной из главных проблем в развитии языка. То что сейчас она одна – несколько поздновато.
После пиздежа про "две стандартные библиотеки" кроме смеха ничего остальное не вызывает. Сразу становится ясно, насколько ты "в теме".
Так всё таки читать не умеем, написано же ясно "проблемы в развитии". Прошедшее время, понимаешь?
Ну, я меня интересует текущий вариант D - D2. Что там творилось в D1 10 лет назад - меня слабо волнует. На данный момент это охуенный язык с охуенными фичами и охуенной стандартной библиотекой.
У тебя серьёзные баги в мозгах видимо.
Всё кроме первого абзаца кстати и к настоящему времени относится, комунити-драйвен язык, все дела. не гори ток
Библиотека там хорошая разве что по сравнению с плюсовой. Паравозик немножко уехал.
Но это ты горишь, мань.
Я так понял - у любителей разрабатывать анал крестом - только один аргумент "ГЦ кококо". Интересно, когда его окончательно сделают опциональным - что они тогда кукарекать будут?
>Библиотека там хорошая разве что по сравнению с плюсовой
По сравнению с любой. Она даст на крык крестовой, растовой, жабьей. Кому еще? Кто там остался?
В растовой и плюсовой ничего и нету – только затычки к языку. Про жабную – даже не смешно.
Из разговора о проблем в развитии ты где-то углядел срач о GC и его выпиле. Ну ладно – сходи на старый форум digital mars и полистай его. Обсуждения этой темы с "опциональностью сборщика", его допилом и пр. идут уже не первый и даже не второй год. Если не поленишься получишь картину, что Брайт с компанией за люди, и почему D – долгострой который никогда не построится.
Алсо, у языка так же проблемы с его местом в этом мире – предназначения для него банально нет. На дворе 2к16, и "у нас есть алгол60 и больше нихуя" уже не котируется, даже у самых убогих высеров вроде Говна оно есть.
>что они тогда кукарекать будут?
Да то же, что и всегда. Нет оценки объективнее, чем оценка комьюнити. Если все голосуют ногами за СТАРЫЕ И ПРОТУХШИЕ КРЕСТЫ, то можно сколько угодно оправдываться и изображать доктора Зло - народ-то не обманешь бенчмарками и сладкими обещаниями.
>аргументы уровня "миллион мух не может ошибаться"
Все и за путина ногами голосуют, следуя твоей логике - он охуенен и пиздат. И айфоны скупают пачками, жрут дерьмо уровня "вы можете зарядить свой телефон только своей зарядкой", и радуются.
Как же заебали D-питухи со своей религией языка, на котором ни одного крупного проекта не написали за 10 лет. Ну сколько можно, а?
Вместе с D1 наберётся. Стандартное "Кококо это разные языки" – всё равно что написать "C++11 и 98 тоже разные языки."
Путин вполне себе охуенен в своей нише, и айфоны сделали много хорошего. Это как раз многое о тебе говорит, что тебе главное быть не таким как все. Ну тогда брал бы действительно интересные и прикольные языки, Nim тот же. А D слишком мало отличается от крестов чтобы 1.5 фичи позволяли отказаться от 30-ти летней кодобазы крестов и сорокалетней сишки.
>А D слишком мало отличается от крестов
D отличается от крестов методом редизайна и исправления их недостатков.
Кресты тупо унаследовали все костыли сишки. А В наследовать кослыли и пердолинг не стал.
Кодобаза > костылей.
>Языку еще нет 10 лет, лол, проекта ему крупного за 10 лет не написали.
Ох, ох, погоди, я и забыл, что ему не 10, а 9 лет. Это действительно многое меняет.
>следуя твоей логике - он охуенен и пиздат
Он успешно справляется с задачами, на которых другие обосрались, точно такая же ситуация с крестами. И в обоих случаях есть раскачивающие лодку неосиляторы, которые пытаются выдать разрозненные попытки перепила за рабочую альтернативу.
>И айфоны скупают пачками
Опять же, айфоны лучше всех справляются с ролью дорогой и статусной игрушки, с которой не нужно пердолиться. Хотя здесь я уже и сам не фанат.
>>798822
>Если сейчас все кинутся голосовать ногами за другое
Кинутся, когда придумают что-то получше. Так было с Фортраном, скинутым с пьедестала, например. И с жабой. Раз не голосуют (а TIOBE не наебешь - не голосуют), значит, пока не придумали. Думайте дальше, господа.
>проекта ему крупного за 10 лет не написали
Ну ничего, мы подождем. А скорость выпуска крупных проектов на крестах спишем на статистические флуктуации.
Все проекты на них тоже посчитаю тогда. А ещё алгол можно посчитать – в си же подобный ему синтаксис со скобочками делали, чо уж.
>точно такая же ситуация с крестами
Хуй там. Ты пытаешься обрисовать ситуацию, как будто кресты были охуенны в свое время и потому взлетели. Хуй там - взлетели они исключительно потому, что была повсюду сишка - а кресты были практически ее надмножеством, макак переучивать не нужно, даже сишная блевотина компилится крестовым компилятором.
Только и всего. Не приписывай крестам имбопиздатость - они просто взлетели паразитируя на популярности си.
Это не совсем так. Кресты взлетели по совокупности факторов. Помимо популярности сишки был общий хайп на ООП и, что важнее, общая философия крестов по вбиранию фич и парадигм из других языков. На более мощный язык всегда легче мигрировать, поэтому отбрасывание фич в угоду безопасности или еще какой хуйне это тупиковый путь. Имхо, конечно, а так поживем - увидим.
Кресты были охуенны - Страуструп придумал как сделать симульное ООП эффективным (а симула - это первый ооп-язык, а не хипстерский тормозной смолток, который и тогда был тормозным, и сейчас) с помощью VMT.
>макак переучивать не нужно
Да ты сам тупая макака, но при этом имеешь наглость обвинять программистов, которым не переучиваться нужно, это хуйня, им нужно ПЕРЕПИСЫВАТЬ КОД. Диванные теоретики типа тебя всегда почему-то об этом забывают, что программисты пишут код, пишут кодами, и потом им пользуется, для них кодирование - это пет-проекты длиной по месяцу. Про тебя история. Но нет, все макаки кроме я.
АППЛ-ТО ПЕРЕПИСЫВАЕТ ВЕСЬ КОД НА SWIFT, А ТЫ ВСЕ СИДИШЬ НАД СВОИМ ЛЕГАСИ КАК БАЙБАК
При этом у них самих всё написано на плюсах, кроме гуйги и интерфейсов к библиотекам.
Ты удивишься, но порой и их системные приложения ВНЕЗАПНО написаны на Obj-C++.
У меня у самого приложения пишутся на Obj-C++, но не потому что мы так премся от этого языка, а потому что единственный способ взаимодействовать с их гуйней. Но дело не в этом
>Swift может использовать рантайм Objective-C, что делает возможным использование обоих языков (а также С) в рамках одной программы
Т.е. в аппле умные люди сидят, они не заставляют выкидывать кодобазу, а позволяют постепенный переход. А ди требует меня отказаться. Я кстати с одним из разработчиков свифта знаком, крестоблядь как я, мы вместе хуисосили D с ним.
>а потому что единственный способ взаимодействовать с их гуйней.
Сестра, 2 кубика Qt этому больному.
Не при чем, это напоминание о том, что корпорации могут себе позволить переписывание легаси. Таким образом, раз уж не метнулись переписывать все на D, значит, вероятно, дело не только в жестокости мира, а, например, в объективных недостатках D, о которых писал анон выше.
>Таким образом, раз уж не метнулись переписывать все на D, значит, вероятно, дело не только в жестокости мира, а, например, в объективных недостатках D, о которых писал анон выше
Раз не кинулись все переписывать на с++ - тогда дело в недостатках с++.
>Раз не кинулись все переписывать на с++ - тогда дело в недостатках с++.
В тот момент и не надо было, можно было просто сделать 'extern "C"' и дополнять легаси на более удобном языке.
Что переписывать? Треть всего существующего кода на крестах, куда уж больше.
>Что переписывать?
Дохуя чего. Практически все, что написано на сишке, к примеру. Взять то же ведро линупса.
Алсо, сейчас это сделать - можно в полуавтоматическом режиме. А если не переписывать, то можно свободно дополнять на C++, но вот только Линус против.
Что самое прикольное - D свои недостатки исправит. А кресты так и останутся парашей, которая компилируется часами, с говном вместо шаблонов и залупой на воротник вместо модульности.
Apple пилят лучший в мире компилятор С++ clang. Наверное им виднее, что нужно писать, а что нет. С++ явно не язык для гуйни в принципе.
Только потому, что gcc они не переваривали по причине лицензии.
>А кресты так и останутся парашей, которая компилируется часами, с говном вместо шаблонов и залупой на воротник вместо модульности.
Смешно будет, когда модули и концепты выкатят хотя бы в виде TS (а это будет уже в течении года). Ведь тогда окажется, что C++ от своих проблем избавился и все такой же популярный, а D - тоже без недостатков, только вот нахуй не нужен будет.
Какие тебе пруфы, лалка? Почитай, как устроен стек вызовов, посмотри листинг.
>Ведь тогда окажется, что C++ от своих проблем избавился
От бесконечного времени компиляции и груза обратной совместимости он не исбавится никогда. Все, чего к нему смогут прикрутить сверху - будет прикручено костылями, потому как изначально в языке не предполагалось.
D это как вяленый, а кресты - как X. Придет время - и иксы отправятся на помойку.
Мань, ты высказал утверждение - тебе его и доказывать. Так я тебе могу сказать, что я ебал твою мамку - опровергнуть ты это не сможешь, а за пруфами я темя в гугл отправлю.
>От бесконечного времени компиляции и груза обратной совместимости он не исбавится никогда
Манька не в курсе, что модули можно использовать уже сегодня и там к тому же инклуды транслируются в импорты на лету для старого кода.
Исправит все - и широкую, ясную
Грудью дорогу проложит себе;
Жаль только, жить в эту пору прекрасную
Не доведется ни мне, ни тебе...
Чай не коммунизм - мне доведется, я не сомневаюсь. Процесс идет.
Все там нормально с рифмой, только ударение проебано. Фиксится заменой "исправит" на "выправит"
Да этот D даже на говно не похож!
>для begin/end и range-based-for
И в чем здесь мякотка? Очередной сахар. Другое дело static if, string view, fs, fold, concurrent stl.
> Очередной сахар.
> Другое дело string view, fs, concurrent stl
А это блядь, даже не сахар. Это просто апдейт к либам.
У меня тут жопа горит от стандарта. Пидоры разрешили reinterpret_cast поинтера на standard-layour struct к поинтеру на её первый мембер. А КАСТИТЬ standard-layour class НЕ РАЗРЕШИЛИ, СУКИ.
Теперь из std::type_index указатель на std::type_info легитимно не достать, т.к. std::type_info это class, а не struct, хотя и standard-layout и указатель на std::type_info это его первый и единственный мембер.
Повбывав бы...
Нет, я, конечно, достаю. Но кагбэ это нарушает стандарт.
Почему ты разделяешь понятия class и struct? А вообще для классов так кастить действительно нельзя. Vptr, все дела.
>Почему ты разделяешь понятия class и struct?
Хотел уже ответить, но пошёл перечитывать стандарт:
A standard-layout struct is a standard-layout class defined with the class-key `struct' or the class-key `class'
Тогда проблемы нет, лол.
> А вообще для классов так кастить действительно нельзя. Vptr, все дела.
Я же оговорил, что речь идёт о standard-layout. Кастить разрешено явно:
A pointer to a standard-layout struct object, suitably converted using a reinterpret_cast, points to its initial member (or if that member is a bit-field, then to the unit in which it resides) and vice versa.
Я хочу, чтобы был исчерпывающий список мест, в которых стало можно/нужно писать по-другому. Иначе можно через пару лет обнаружить, что, скажем, известные тебе ограничения на if-expression уже давно ослаблены. Или наоборот, что запретили твои любимые триграфы. Понятно, что я сейчас утрирую, но там действительно много подобных "тихих изменений", а во всех гайдах обычно пишут только про самые существенные - новые фичи, расшмрения библиотеки etc.
Так а что мешает делать vptr в структуре, лол? Это совершенно ортогональные с layout вещи. По стандарту class и struct отличаются только аспектами доступа.
> своих проблем
Вырвиглазного синтаксиса и богатой истории, со стандартом больше напоминающим законодательство какой-нибудь страны? Сомневаюсь.
А кто сказал, что нельзя, лол? Он явно что-то другое имел в виду, говоря структуры. Но если думать о его классах, как об обычных struct/class, то там нельзя кастить указатель на класс на указатель на первый член с помощью reinterpret.
Нах тебе вообще rtti сдалось?
А где гарантии, что type_index это standard layout? Я только про копируемость вижу.
>А где гарантии, что type_index это standard layout?
Посмотри на его определение в стандарте. Там даже private-мембер определяется.
Взять к примеру дишечный sort - шаблонным параметром можно передать компаратор
sort!((a, b) => cmp(a, b) < 0)(numbers);
sort!("a > b")(array);
Сделай точно так же в крестах (ну, синтаксис будет другой - скобочки угловые вместо восклицательного знака). Разве нельзя? Тут же тоже шаблончики.
Именно что да, передавай шаблоном если не хочешь определять компаратор в раниаймеи не еби мозга.
В буст range есть йоба с пайпами и насколько я помню ленивостью http://www.boost.org/doc/libs/1_46_1/libs/range/doc/html/range/reference/adaptors/reference/filtered.html
Но я бы рекомендовал без нужды типа распараллеливания не увлекаться, range based for ничем не хуже, если ты не ФП-ебанат, конечно.
Я сто лет использую структуры как массивы с именованным членами и проблем не имею.
Знал людей, которые сто лет не инициализируют локальные переменные, собирают только в дебаг-режиме в VS и проблем не имеют.
Ну и мразь же ты, это уже чересчур!
Укажи вариант, при котором это работать не будет, при условии, что структура - POD, и внутри у нее тоже POD, причем одинаковые.
>людей, которые сто лет не инициализируют локальные переменные
Зачем их инициализировать, если уверен, что ниже они обязательно инициализируются перед использованием?
Уже много лет как.
typedef/шаблоны.
Стандарт говорит нам только про каст к первому мемберу. Про остальные — ХЗ.
Это если формально посмотреть.
>>filter
>std::copy_if (?)
Ладно, это не совсем filter, он может только копировать в другой контейнер.
В бусте есть вроде фильтр.
conversion from 'ostream' (aka 'basic_ostream<char>') to 'const void ' for 1st argument; take the address of the argument with &
operator<<(const void __p)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/system_error:209:5: note: candidate function [with _CharT = char,
_Traits = std::char_traits<char>] not viable: no known conversion from 'ostream' (aka 'basic_ostream<char>') to
'const std::error_code' for 2nd argument
operator<<(basic_ostream<_CharT, _Traits>& __os, const error_code& __e)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:108:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to '__ostream_type &()(__ostream_type &)' for 1st argument
operator<<(__ostream_type& (__pf)(__ostream_type&))
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:117:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to '__ios_type &()(__ios_type &)' for 1st argument
operator<<(__ios_type& (__pf)(__ios_type&))
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:127:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'std::ios_base &()(std::ios_base &)' for 1st argument
operator<<(ios_base& (__pf) (ios_base&))
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:166:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'long' for 1st argument
operator<<(long __n)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:170:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'unsigned long' for 1st argument
operator<<(unsigned long __n)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:174:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'bool' for 1st argument
operator<<(bool __n)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:178:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'short' for 1st argument
operator<<(short __n);
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:181:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'unsigned short' for 1st argument
operator<<(unsigned short __n)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:189:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'int' for 1st argument
operator<<(int __n);
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:192:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'unsigned int' for 1st argument
operator<<(unsigned int __n)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:201:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'long long' for 1st argument
operator<<(long long __n)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:205:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'unsigned long long' for 1st argument
operator<<(unsigned long long __n)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:220:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'double' for 1st argument
operator<<(double __f)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:224:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'float' for 1st argument
operator<<(float __f)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:232:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'long double' for 1st argument
operator<<(long double __f)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:270:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to '__streambuf_type ' (aka 'basic_streambuf<char, std::char_traits<char> > ')
for 1st argument
operator<<(__streambuf_type __sb);
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:502:5: note: candidate function [with _CharT = char, _Traits
= std::char_traits<char>] not viable: no known conversion from 'ostream' (aka 'basic_ostream<char>') to 'char' for 2nd argument
operator<<(basic_ostream<_CharT, _Traits>& __out, char __c)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:508:5: note: candidate function
[with _Traits = std::char_traits<char>] not viable: no known conversion from 'ostream' (aka 'basic_ostream<char>') to 'char' for 2nd
argument
operator<<(basic_ostream<char, _Traits>& __out, char __c)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:514:5: note: candidate function
[with _Traits = std::char_traits<char>] not viable: no known conversion from 'ostream' (aka 'basic_ostream<char>') to 'signed char'
for 2nd argument
operator<<(basic_ostream<char, _Traits>& __out, signed char __c)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:519:5: note: candidate function
[with _Traits = std::char_traits<char>] not viable: no known conversion from 'ostream' (aka 'basic_ostream<char>') to 'unsigned char'
for 2nd argument
operator<<(basic_ostream<char, _Traits>& __out, unsigned char __c)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:556:5: note: candidate function
[with _Traits = std::char_traits<char>] not viable: no known conversion from 'ostream' (aka 'basic_ostream<char>') to 'const char '
for 2nd argument
operator<<(basic_ostream<char, _Traits>& __out, const char __s)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:569:5: note: candidate function
[with _Traits = std::char_traits<char>] not viable: no known conversion from 'ostream' (aka 'basic_ostream<char>') to
'const signed char ' for 2nd argument
operator<<(basic_ostream<char, _Traits>& __out, const signed char __s)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:574:5: note: candidate function
[with _Traits = std::char_traits<char>] not viable: no known conversion from 'ostream' (aka 'basic_ostream<char>') to
'const unsigned char ' for 2nd argument
operator<<(basic_ostream<char, _Traits>& __out, const unsigned char __s)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:628:5: note: candidate function [with _CharT = char, _Traits
= std::char_traits<char>, _Tp = std::basic_ostream<char>] not viable: no known conversion from '__ostream_type' (aka
'basic_ostream<char, std::char_traits<char> >') to 'basic_ostream<char, std::char_traits<char> > &&' for 1st argument
operator<<(basic_ostream<_CharT, _Traits>&& __os, const _Tp& __x)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/bits/ostream.tcc:321:5: note: candidate function [with _CharT = char,
_Traits = std::char_traits<char>] not viable: no known conversion from 'ostream' (aka 'basic_ostream<char>') to 'const char ' for 2nd
argument
operator<<(basic_ostream<_CharT, _Traits>& __out, const char __s)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:497:5: note: candidate template ignored: deduced conflicting
types for parameter '_CharT' ('char' vs. 'std::basic_ostream<char>')
operator<<(basic_ostream<_CharT, _Traits>& __out, _CharT __c)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/bits/basic_string.h:5172:5: note: candidate template ignored: could
not match 'basic_string' against 'basic_ostream'
operator<<(basic_ostream<_CharT, _Traits>& __os,
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:539:5: note: candidate template ignored: could not match
'const _CharT ' against 'ostream' (aka 'basic_ostream<char>')
operator<<(basic_ostream<_CharT, _Traits>& __out, const _CharT __s)
^
main.cpp:29:46: error: invalid operands to binary expression ('__ostream_type' (aka 'basic_ostream<char, std::char_traits<char> >') and
'ostream' (aka 'basic_ostream<char>'))
std::cout << find (v.begin(), v.begin(), 1) << std::cout;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:245:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'const void ' for 1st argument; take the address of the argument with &
operator<<(const void __p)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/system_error:209:5: note: candidate function [with _CharT = char,
_Traits = std::char_traits<char>] not viable: no known conversion from 'ostream' (aka 'basic_ostream<char>') to
'const std::error_code' for 2nd argument
operator<<(basic_ostream<_CharT, _Traits>& __os, const error_code& __e)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:108:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to '__ostream_type &()(__ostream_type &)' for 1st argument
operator<<(__ostream_type& (__pf)(__ostream_type&))
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:117:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to '__ios_type &()(__ios_type &)' for 1st argument
operator<<(__ios_type& (__pf)(__ios_type&))
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:127:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'std::ios_base &()(std::ios_base &)' for 1st argument
operator<<(ios_base& (*__pf) (ios_base&))
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:166:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'long' for 1st argument
operator<<(long __n)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:170:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'unsigned long' for 1st argument
operator<<(unsigned long __n)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:174:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'bool' for 1st argument
operator<<(bool __n)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:178:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'short' for 1st argument
operator<<(short __n);
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:181:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'unsigned short' for 1st argument
operator<<(unsigned short __n)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:189:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'int' for 1st argument
operator<<(int __n);
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:192:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'unsigned int' for 1st argument
operator<<(unsigned int __n)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:201:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'long long' for 1st argument
operator<<(long long __n)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:205:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'unsigned long long' for 1st argument
operator<<(unsigned long long __n)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:220:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'double' for 1st argument
operator<<(double __f)
^
conversion from 'ostream' (aka 'basic_ostream<char>') to 'const void ' for 1st argument; take the address of the argument with &
operator<<(const void __p)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/system_error:209:5: note: candidate function [with _CharT = char,
_Traits = std::char_traits<char>] not viable: no known conversion from 'ostream' (aka 'basic_ostream<char>') to
'const std::error_code' for 2nd argument
operator<<(basic_ostream<_CharT, _Traits>& __os, const error_code& __e)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:108:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to '__ostream_type &()(__ostream_type &)' for 1st argument
operator<<(__ostream_type& (__pf)(__ostream_type&))
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:117:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to '__ios_type &()(__ios_type &)' for 1st argument
operator<<(__ios_type& (__pf)(__ios_type&))
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:127:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'std::ios_base &()(std::ios_base &)' for 1st argument
operator<<(ios_base& (__pf) (ios_base&))
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:166:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'long' for 1st argument
operator<<(long __n)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:170:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'unsigned long' for 1st argument
operator<<(unsigned long __n)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:174:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'bool' for 1st argument
operator<<(bool __n)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:178:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'short' for 1st argument
operator<<(short __n);
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:181:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'unsigned short' for 1st argument
operator<<(unsigned short __n)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:189:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'int' for 1st argument
operator<<(int __n);
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:192:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'unsigned int' for 1st argument
operator<<(unsigned int __n)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:201:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'long long' for 1st argument
operator<<(long long __n)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:205:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'unsigned long long' for 1st argument
operator<<(unsigned long long __n)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:220:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'double' for 1st argument
operator<<(double __f)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:224:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'float' for 1st argument
operator<<(float __f)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:232:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'long double' for 1st argument
operator<<(long double __f)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:270:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to '__streambuf_type ' (aka 'basic_streambuf<char, std::char_traits<char> > ')
for 1st argument
operator<<(__streambuf_type __sb);
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:502:5: note: candidate function [with _CharT = char, _Traits
= std::char_traits<char>] not viable: no known conversion from 'ostream' (aka 'basic_ostream<char>') to 'char' for 2nd argument
operator<<(basic_ostream<_CharT, _Traits>& __out, char __c)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:508:5: note: candidate function
[with _Traits = std::char_traits<char>] not viable: no known conversion from 'ostream' (aka 'basic_ostream<char>') to 'char' for 2nd
argument
operator<<(basic_ostream<char, _Traits>& __out, char __c)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:514:5: note: candidate function
[with _Traits = std::char_traits<char>] not viable: no known conversion from 'ostream' (aka 'basic_ostream<char>') to 'signed char'
for 2nd argument
operator<<(basic_ostream<char, _Traits>& __out, signed char __c)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:519:5: note: candidate function
[with _Traits = std::char_traits<char>] not viable: no known conversion from 'ostream' (aka 'basic_ostream<char>') to 'unsigned char'
for 2nd argument
operator<<(basic_ostream<char, _Traits>& __out, unsigned char __c)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:556:5: note: candidate function
[with _Traits = std::char_traits<char>] not viable: no known conversion from 'ostream' (aka 'basic_ostream<char>') to 'const char '
for 2nd argument
operator<<(basic_ostream<char, _Traits>& __out, const char __s)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:569:5: note: candidate function
[with _Traits = std::char_traits<char>] not viable: no known conversion from 'ostream' (aka 'basic_ostream<char>') to
'const signed char ' for 2nd argument
operator<<(basic_ostream<char, _Traits>& __out, const signed char __s)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:574:5: note: candidate function
[with _Traits = std::char_traits<char>] not viable: no known conversion from 'ostream' (aka 'basic_ostream<char>') to
'const unsigned char ' for 2nd argument
operator<<(basic_ostream<char, _Traits>& __out, const unsigned char __s)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:628:5: note: candidate function [with _CharT = char, _Traits
= std::char_traits<char>, _Tp = std::basic_ostream<char>] not viable: no known conversion from '__ostream_type' (aka
'basic_ostream<char, std::char_traits<char> >') to 'basic_ostream<char, std::char_traits<char> > &&' for 1st argument
operator<<(basic_ostream<_CharT, _Traits>&& __os, const _Tp& __x)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/bits/ostream.tcc:321:5: note: candidate function [with _CharT = char,
_Traits = std::char_traits<char>] not viable: no known conversion from 'ostream' (aka 'basic_ostream<char>') to 'const char ' for 2nd
argument
operator<<(basic_ostream<_CharT, _Traits>& __out, const char __s)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:497:5: note: candidate template ignored: deduced conflicting
types for parameter '_CharT' ('char' vs. 'std::basic_ostream<char>')
operator<<(basic_ostream<_CharT, _Traits>& __out, _CharT __c)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/bits/basic_string.h:5172:5: note: candidate template ignored: could
not match 'basic_string' against 'basic_ostream'
operator<<(basic_ostream<_CharT, _Traits>& __os,
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:539:5: note: candidate template ignored: could not match
'const _CharT ' against 'ostream' (aka 'basic_ostream<char>')
operator<<(basic_ostream<_CharT, _Traits>& __out, const _CharT __s)
^
main.cpp:29:46: error: invalid operands to binary expression ('__ostream_type' (aka 'basic_ostream<char, std::char_traits<char> >') and
'ostream' (aka 'basic_ostream<char>'))
std::cout << find (v.begin(), v.begin(), 1) << std::cout;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:245:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'const void ' for 1st argument; take the address of the argument with &
operator<<(const void __p)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/system_error:209:5: note: candidate function [with _CharT = char,
_Traits = std::char_traits<char>] not viable: no known conversion from 'ostream' (aka 'basic_ostream<char>') to
'const std::error_code' for 2nd argument
operator<<(basic_ostream<_CharT, _Traits>& __os, const error_code& __e)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:108:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to '__ostream_type &()(__ostream_type &)' for 1st argument
operator<<(__ostream_type& (__pf)(__ostream_type&))
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:117:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to '__ios_type &()(__ios_type &)' for 1st argument
operator<<(__ios_type& (__pf)(__ios_type&))
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:127:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'std::ios_base &()(std::ios_base &)' for 1st argument
operator<<(ios_base& (*__pf) (ios_base&))
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:166:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'long' for 1st argument
operator<<(long __n)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:170:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'unsigned long' for 1st argument
operator<<(unsigned long __n)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:174:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'bool' for 1st argument
operator<<(bool __n)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:178:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'short' for 1st argument
operator<<(short __n);
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:181:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'unsigned short' for 1st argument
operator<<(unsigned short __n)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:189:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'int' for 1st argument
operator<<(int __n);
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:192:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'unsigned int' for 1st argument
operator<<(unsigned int __n)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:201:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'long long' for 1st argument
operator<<(long long __n)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:205:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'unsigned long long' for 1st argument
operator<<(unsigned long long __n)
^
/usr/bin/../lib/gcc/i586-linux-gnu/5.3.1/../../../../include/c++/5.3.1/ostream:220:7: note: candidate function not viable: no known
conversion from 'ostream' (aka 'basic_ostream<char>') to 'double' for 1st argument
operator<<(double __f)
^
>>799361
Хотелось бы еще скрыть компараторы внутри функции и передавать только какое-нибудь ключевое слово, чтобы было понятно, какой использовать
Г-ди в крестопараше куда понятнее имена, чем у фунциональных каргопетушков.
Ну я бы так однозначно не говорил.
Если углубиться, то там вроде бы есть какие-то гарантии про минимальное достаточное выравнивание и последовательность размещения, но это все довольно мутно и неявно, так что я бы просто не стал использовать, чтобы не рисковать.
Так создай классы Cmp1 и Cmp2, с функциями cmp, и юзай как huita<Cmp1>(args); не зню можно ли в таком же кошерном виде передавать функции
Ну хорошо, remove_if есть (хотя ты и copy_if можешь использовать для тех же целей, там допустимы пересечения коллекции-источника с коллекцией-приемником).
https://ideone.com/6Jtihz
И что в них писать, лол? Нет, я допускаю, что можно придумать монструозную ебалу, которая это проверит на основе существующих недоконцептов, но нахуя, если это в итоге принесет выигрыш в несколько символов всего.
А сейчас в чём проблема?
Нет, все в порядке. Только разыменовывать этот итератор нельзя в общем случае, если там может быть end ().
Просто ты питуз. Эти имена в ФП пришли из математики и старше твоих крестов.
И вообще, зачем ты пишешь свой find?
У тебя почти тот же код, что в http://en.cppreference.com/w/cpp/algorithm/find Possible implementation
> Эти имена в ФП пришли из математики и старше твоих крестов.
Давайте пользоваться римскими, а не арабскими числами тогда. Они старше.
>И что в них писать, лол?
Размер структуры и размер массива совпадают. По стандарту компилятор паддинг может добавлять куда угодно, но на практике ни один компилятор этого не делает.
Ну все, начинаем общаться в терминах трудов Лейбница, а то всякие современные петухи напридумывали новых названий, аж слушать противно.
> По стандарту компилятор паддинг может добавлять куда угодно
Что, стандарт совсем не накладывает ограничений сверху?
И?
Позиционные системы счисления удобнее для использования в жизни и программирования. Битовые сдвиги бы не работали с римской системой. А то, что петушкам непонятно, что такое отображение списка или дерева, это их проблемы.
Возврат итератора как раз в следующей задаче :3
Число это последовательность цифр. Даже если последовательность из одной цифры, то это последовательность цифр (== число), а не цифра.
>Что, стандарт совсем не накладывает ограничений сверху?
Нет, архитектуры CPU ведь могут быть произвольной ебанутости.
Паддинг от алайна не зависит по стандарту. Стандарт задает только порядок членов структуры в памяти, но расстояние между ними может быть произвольное.
Таки да. Не нашёл ничего конкретного про паддинг, что что-то бы гарантировало.
Неоптимально же. resize (n, val) лучше, ну или хотя бы сделать reserve сперва, иначе лишние аллокации возможны.
>>799733
Вот здесь говорят, что set можно использовать как очередь с приоритетами.
http://cybern.ru/algoritm-dejkstry-dlya-razrezhennyx-grafov-realizaciya-na-c.html
Нахуя, если есть priority_queue? Какие-то петухи ставят костыли, а ты и рад проглотить. Читай Седжвика лучше, няша.
Кстати да, у нас за такое убивают нахуй. Родина дала им for(;;), итерируй! Не хочу, хочу жрать предупреждения.
Ты не понял.
>Читай Седжвика лучше, няша
Я Кормена читаю, а реализации гуглю в интернете. Попадается лютое говно.
Не читай этого Василия, он неправильно юзает std::set. Просто потому, что в интерфейсе set'а никакого поведения, похожего на очередь с приоритетами, и близко не планировалось. Также его код говно нечитаемое.
Более того, я очень сомневаюсь, что его код рабочий, но я ебал в рот сидеть и проверять эту поебень.
На пикриле ты можешь увидеть, как должен выглядеть хоть немного понятный код.
Алсо, я не понимаю, нахуя ты лазишь в интернет, когда у Кормена все написано просто заебись (пикрил2).
Говно нечитаемое. Нахрен ты лепишь туда макросы, когда ты пишешь ебаный поиск кратчайших путей? Я ебал читать. Визуализация - говно. Слишком нагружено и непонятно. Осиль dot или просто печатай пошагово результирующий массив.
Можно видоизменить граф для большей наглядности(храни буквенные идентификаторы), должно получится, как на пикриле.
И еще - осиль тесты.
У меня в Кормене алгоритм так записан. Какое-то подзалупное говно с расходом памяти на очередь с приоритетами, содержащую все ребра. Пацаны говорят, что достаточно добавлять по одному ребру в очередь. К тому же у него слишком высокая декомпозиция алгоритма на отдельные функции. Если писать так, как у Кормена, то придется передавать в функцию relax ссылку на очередь. Это слишком грязно.
Когда все хранится в разных областях видимости, такую идеальную декомпозицию без грязи не сделать.
Во-первых, нахуя ты полез в серьезную литературу, если ты, блядь, не шаришь ебаный алгоритм дейкстры? Тебя не смущает то, что тебе сложно читать "Построение и анализ"?
Начни с чего-нибудь попроще. Например, с пикрила. Тоже Кормен, но написано намного проще, легче будет вкатиться. Когда осилишь, сможешь легко перекатиться на старшего брата этой книги.
По тестам почитай введение http://www.boost.org/doc/libs/1_61_0/libs/test/doc/html/boost_test/intro.html
Чтобы просто начать тестировать. Потом сам найдешь что-нибудь посложнее.
>Пацаны говорят, что достаточно добавлять по одному ребру в очередь
Можно и так.
>К тому же у него слишком высокая декомпозиция алгоритма на отдельные функции
Его декомпозиция совершенна.
>Если писать так, как у Кормена, то придется передавать в функцию relax ссылку на очередь. Это слишком грязно.
Не кукарекай, умник. Сперва реализуй алгоритм самостоятельно и, самое главное, правильно. А потом будешь оптимизировать.
>Его декомпозиция совершенна.
Не спорю, алгоритм хорош, но на мою реализацию он не ложится. Не знаю, как вообще получить опыт реалиазации алгоритмов такого же качества, если получается говно.
>Не кукарекай, умник. Сперва реализуй алгоритм самостоятельно и, самое главное, правильно. А потом будешь оптимизировать
Я умею проделывать этот алгоритм на бумажке, писал реализацию без очереди с приоритетами, а сейчас хочу разобраться в эффектином варианте Дейкстры. Если его писать на фибоначчиевых кучах, сложность алгоритма вообще достигает теоретического минимума.
>но на мою реализацию он не ложится
Измени реализацию?
>>799780
>писал реализацию без очереди с приоритетами
Щито? Ты писал не алгоритм Дейсктры. Его Дейкстра не с потолка взял - в его основе лежат определенные идеи, которые безальтернативно приводят к необходимости очереди с приоритетами. Вопрос лишь в том, как будет реализована очередь с приоритетами: через массив, бинарную кучу или фибоначчиеву кучу.
Так что твой алгоритм никак не изменится от замены одной реализации очереди на другую.
>Ты писал не алгоритм Дейсктры
Тогда что это? http://e-maxx.ru/algo/dijkstra
Алсо, почему на пикче раннеры идут к вершинам, к которым идти не нужно? Или они там от балды натыканы? Алгоритм Дейкстры ведь жадный, он на каждой итерации выбирает ребро наименьшего веса. Судя по пикче, там происходит что-то другое.
>Алсо, почему на пикче раннеры идут к вершинам, к которым идти не нужно? Или они там от балды натыканы?
Мда.
Алгоритм выбирает ребро наименьшего веса. Следующая итерация начинается с конечной вершины этого ребра. Точно так же ищется самое оптимальное на этом этапе решение, и следующая итерация начинается с самой близкой вершины. Что не так? На картинке явно не это.
По-моему, картинка вполне соответствует алгоритму.
>Тогда что это? http://e-maxx.ru/algo/dijkstra
Алгоритм Дейкстры с очередью с приоритетами. На пикриле можно увидеть основную операцию очереди с приоритетами.
>Алсо, почему на пикче раннеры идут к вершинам, к которым идти не нужно?
Боженька не велит? Хуле не нужно-то, алгоритм не видит граф так же как ты.
>Алгоритм Дейкстры ведь жадный
Бля, заканчивай гнать умные слова. Впечатление ты на АиБ ни на кого не произведешь. Жадность алгоритмов тебе никак не объяснит, что происходит у Дейкстры. По крайней мере, пока.
>Жадность алгоритмов тебе никак не объяснит, что происходит у Дейкстры
Вполне себе объясняет. Там на каждом шаге делается оптимальный выбор.
>Алгоритм Дейкстры с очередью с приоритетами. На пикриле можно увидеть основную операцию очереди с приоритетами
Нет, это хуйня, а не очередь с приоритетами. Очередь нужна для извлечения ребра наименьшего веса за O(1), а по ссылке и на пикче - брутфорс. Пиздец наркоманы.
>Вполне себе объясняет. Там на каждом шаге делается оптимальный выбор.
Ну раз объясняет, то расскажи нам тогда, в чем СУТЬ?
Блядь, вот это кадр к нам занесло, пиздец просто.
>Очередь нужна для извлечения ребра наименьшего веса за O(1)
Охуительные истории. Ты бы хоть книжки умные почитал, перед тем, как такую хуйню постить.
На каждой итерации выбираешь ближайшую вершину. Если метку этой вершины можно улучшить, то улучшаешь, делаешь записи в массив, и такие же действия повторяешь для вершины, ближайшей к текущей.
>>799819
Именно так. Очередь с приоритетами нужна для того, чтобы элемент с наибольшим или наименьшим приоритетом извлекать за O(1).
Лолка, а ты думаешь все алгоритмы выдумают просто так? Типа раз и догадался? Лал.
>На каждой итерации выбираешь ближайшую вершину
Почему ближайшую? А не, например, дальнюю. Или посередине. Или первую. Ты тупо пересказываешь алгоритм, а я спросил, почему он выглядит именно так, а не иначе.
>Именно так. Очередь с приоритетами нужна для того, чтобы элемент с наибольшим или наименьшим приоритетом извлекать за O(1).
Бля, ну залезь и почитай, заебал. O(1) - это время лучшей реализации такой очереди, но саму очередь определяют 2 операции: доступ к минимальному элементу и вставка. Вполне можно придумать ситуацию, когда константное время вставки элемента будет предпочтительнее, чем константное время изъятия. И в такой ситуации лучше будет применить очередь, основанную на массиве.
>Почему ближайшую? А не, например, дальнюю. Или посередине. Или первую
Потому что для каждого кратчайшего пути к какой-то вершине любая последовательность ребер в этом пути - тоже кратчайший путь. Поэтому выбираются ближайшие вершины, которые входят в кратчайший путь.
Помогите разобраться, что у меня здесь не так? https://ideone.com/pFZd13
Алгоритм работает верно: перед выполнением std::replace данные в distances правильные. std::replace должен заменить все значения INF = MAX_INT на -1, но почему-то алгоритм заменяет все подряд элементы на -1.
>Кормена
Офигеть, перед возвратом вектор содержит правильные значение, а из функции возвращается вектор со значениями INT_MAX. Как это получилось?
https://ideone.com/fg4vlu
У разработчиков Firefox было 22 года (с момента выхода первого Netscape Navigator), чтобы научиться правильно выделять и освобождать память и они так и не научились это делать нормально. Самописный мемори аллокатор не помогает:
https://hg.mozilla.org/mozilla-central/file/tip/memory/mozalloc/mozalloc.cpp
Может быть проблема в самих крестах?
Может быть, проблема в том, что необучаемые за 22 года так и не вышли за пределы C с классами?
Я не пони. Как ты сделал так, что возвращеный вектор стал содержать корректные значения? Я уже дифф сделал, но нихуя непонятно, почти ничего не изменилось же. Как так перед возвратом в векторе одни значения, а после возврата - другие?
>Я не пони. Как ты сделал так, что возвращеный вектор стал содержать корректные значения? Я уже дифф сделал, но нихуя непонятно, почти ничего не изменилось же. Как так перед возвратом в векторе одни значения, а после возврата - другие?
Лолка, у тебя там счетчик j в for, а используешь i
Изменения:
1. Для краткого определения очереди создал класс node с перегруженным оператором сравнения. Теперь очередь применяет упорядочивание элементов, зная, как их сравнивать.
2. Названия поле класса node более удобны, чем first и second. Не нужно вспоминать: в first вес ребра или номер конечной вершины.
3. Единообразие данных, используемых в представлении графа и его обработке: если в списках смежности хранятся пары (вершина, вес), то в очереди координаты пар расположены тоже в порядке (вершина, вес).
4. Небольшой недостаток использования класса node: надо помнить про порядок инициализации полей.
5. Для декомпозиции алгоритма Дейкстры все ребра сразу помещу в очередь. Это избавит от необходимости помещать ребро в очередь в коде релаксации, и процедуру релаксации можно написать отдельно.
6. Блок private выглядит как говно. Как научиться писать такие же красивые классы, как тут? https://rsdn.ru/forum/cpp/4243140.all
И еще:
>Graph::result
Graph::result result = g.dijkstra(...) выглядит как говно, если не использовать auto. Стоит ли вообще использовать в этом классе typedef?
Как лучше найти элемент который чаще всего встречается в векторе?
запихай элементы в std::multimap и потом через count получай количество вхождений каждого
ты в лямбды не научился, не захватил значение `start`, нужно его в квадратных скобках написать, а если ты хочешь выкидывать элемент по его индексу, то сделай так:
http://ideone.com/zHkkZL
но так делать не очень хорошо, по сути
VC++ 2013 не может в перемещающие операции, какой там нахуй экспериментал, не думаю, что даже в 2015 версии такое есть
Я вообще думаю, нафига в C++ столько ненужного дерьма было понапихано.
Вот неполный список:
- wchar_t
- локали
- ostream_iterator
пример кода можно?
в смысле swap не сработает т.к. make_pair нужен
Всё спасибо сам разобрался
Там абсолютно нечего учить.
Именно гуй приложение разве что на Qt, вот только хуй знает, стоит ли свеч ебля с разными билдами под разные процессоры, большим размером от зависимостей и, самое главное, ебля с публикацией в маркете.
>>800294
Не пиши хуйни, там вообще ничего нету для "полноценного приложения".
короче бля, легче java выучить, чем ебаться с плюсами?
С каких пор локали перестали быть нужными?
ostream_iterator был еще в оригинальной реализации i/o потоков.
А вот про wchar_t я не знаю. Поясните мне. Насколько я понял, он нужен, если мы хотим хранить юникод, поддерживающий несколько языков одновременно. Какие альтернативы?
>С каких пор локали перестали быть нужными?
С таких, что для них ничего не гарантируется. Только наличие локали "С". Какой смысл вносить в стандарт entity, для которой не предоставляется никаких гарантий? Как писать переносимый код с этим?
> ostream_iterator был еще в оригинальной реализации i/o потоков.
Кому нужен вывод с delimeter-ом после последнего элемента?
> Насколько я понял, он нужен, если мы хотим хранить юникод
wchar_t хранит не юникод, а он достаточен для хранения некоего расширенного набора символов для данно платформы. Т.е. опять же, по сути ничего не гарантируется.
По мне так wchar_t и прочие локали только сбивают с толку. С ними невозможно написать переносимый код, хотя кажется, что для переносимости они добавлялись.
>Кому нужен вывод с delimeter-ом после последнего элемента?
Да не ебу, просто нельзя говорить, что эту хуйню запилили вместо модулей. Я вообще этой поеботой из итераторов и алгоритмов почти никогда не пользуюсь. Нахуй на каждый чих они зоделали функций, я не ебу.
> нельзя говорить, что эту хуйню запилили вместо модулей.
Я вообще что-то говорил про модули?! о_О
> Я вообще этой поеботой из итераторов и алгоритмов почти никогда не пользуюсь.
Скорее всего, зря.
Код тут: http://pastebin.com/x1N2tSub
>>800336
>>800344
Продолжу вопрос этого хуя. Насколько сильно обфускаторы влияют на генерацию ассемблерного кода? Так можно обходить сигнатурные анализаторы?
насчет очепятки с typedef`ом. тут все ок, это я просто пьяненький был, когда писал. так шо ошибка актуальна.
Хелп! Как завершить поток ввода в консоли windows 10? Ctrl-Z не помогаетвыводит ^Z, enter тоже.
На кой хуй вообще обфусцировать исходный код, если при одинаковой логике конечный ассемблерный код не будет отличатся?
Ну бля(
>На кой хуй вообще обфусцировать исходный код
Я думаю этот все тот же дебил, что уже неделю спамит своим фейк.av. Вероятно его поделие после нескольких тредов в /b уже добавили в базы и теперь он ищет обфускатор.
1. Что такое макрос Q_OBJECT, как он работает, и зачем нужны свойства Q_PROPERTY, если они работают как геттеры и сеттеры, которые и так делаются public?
2. Почему это говно не компилится? http://pastebin.com/jnH961E3
Ошибки:
In function Test:
undefined reference to 'vtable for Test'
In function ~Test:
undefined reference to 'vtable for Test'
После изменения Test test; на Test tst():
Test tst();
tst.setProperty("readOnly", true);
Ошибка:
request for member 'setProperty' in 'tst', which is of non-class type 'Test()'
Что тут не так? Из-за отсутствия скобок программа не компилировалась, я так понимаю, потому, что компилятор Qt не поддерживает 11 стандарт, в котором конструктор преобразования с аргументом по умолчанию может работать как дефолтный конструктор.
>QT
Мамке своей это скажи, капслоковый мудель.
>Q_OBJECT
Открой и посмотри. Добавляет соответствующий для Qt контент в класс.
> Q_PROPERTY
А вот хуй знает, но для них что-то генерирует мок-компилятор.
Который я прописал в настройках (MinGW).
>Кресты не для тупых
Напиши-ка решение дискретной задачи о рюкзаке на нумералах Чёрча, Манька.
Он к компилятору плюсов не относится никак.
Пиздец. Оказывается, все дело в том, что QT ссу в рот капсохейтеру заставляет определять классы в хедерах. Если класс определен в файле имплементации, все это почему-то не будет компилироваться.
1) Q_OBJECT ставится в самом начале.
2) Классы по умолчанию и так приватны, вась.
>>800457
Ссу в рот твоей мамаше, проверяй.
У собаки проверяй.
Вроде полны.
http://neerc.ifmo.ru/wiki/index.php?title=Лямбда-исчисление
> На основе этого всего уже можно реализовать эмулятор машины тьюринга
>>800436
А кресты тут при чём?
Разобрался, уебываю.
Почему у меня всегда выводит число 2, а должно, вроде бы, выводить квадраты дальше.
Посоветуйте, как можно код улучшить. Мне кажется, я хуево написал. Это задачка из Страуструпа. По задумке вводятся 2 числа и один символ. Числа потом выводятся, а если символ равен |, то консоль закрывается.
Хотелось бы, чтобы третий символ не обязательно было вводить, а еще лучше, чтобы | можно было вместо одного из чисел ввести и ввод прекратился бы. Конкретно непонятно, как проверить тип данных, которые поступают из cin.
http://pastebin.com/e5JAXf8h
А ты сам можешь объяснить что делает твоя программа? По шагам каждую строчку расскажи.
Точно, забыл про задание. Я задание по страуструпу делаю - пик.
Хотел пока сделать так, чтобы до 1000 выводились квадраты по порядку.
Я там отдельно функцию вынес - sqr.
Суть в том, что в цикле идёт обращение к этой функции, в которой если
- square = 1, то прибавляется 1
- если != 1, то умножается на самого себя
Только я не пойму почему не работает.
Из одной главы задачи решаем, ахуеть. Только ты дальше продвинулся.
Инициализирую square, потом в цикле беру функцию sqr из square. Я не пойму, почему в функции sqr не увеличивается square.
В функции вроде не обязательно чтобы имена совпадали, нет?
Я заменил s на square - всё равно не работает.
Вот, упростил, но не понимаю. Должно же выводить 1, 2, 3 етц.
А оно мне бесконечную 2 выводит.
Иницизализирую square и rice_count, потом цикл:
до тех пор пока квадрат <= счёт_риса ТО:
вывести функцию квадрата
функция просто +1 делает
Нет походу. Во введении написано, что на сайте есть решения избранных задач. Но я там нифига найти не могу.
http://www.stroustrup.com/programming.html
НУ так и должно быть, а вывод просто число 2 ббесконечно.
???
4-я. У меня задание 1, а там вообще только упражнения.
добавить в параметрах функции перед s амперсант, и будет тебе выводить 1, 2, 3 етц.
>Ты путаешь ум и задротство
Сказал петушок, не приводя определения "ума". Когда спорят, например, ученые, они сначала договариваются о терминах, чтобы каждый понимал, о чем точно они спорят. Вот поэтому ты петушок. И все крестухи такие же петушки
КОРМИТЕ
ЛАБОДАУНА
Определения "петушка", "ученых" и "определения" в студию, маня. Не, ну серьезно, я, конечно, понимаю, что маневрирование помогает психологически, когда нет аргументов, но мы же твои приемы насквозь видим, лучше бы занялся чем-нибудь полезным и не нервничал лишний раз.
Или на proceedings.
https://habrahabr.ru/post/274099/
https://habrahabr.ru/post/269731/
https://habrahabr.ru/post/266851/
Запушил QWORD тебе в рот.
>>>800599
вот тебе анон скинул ссылочку, прочитай раздел "Передача параметров по значении и по ссылке", а вообще лучше все прочитай. Удачи.
С тобой никто не играл.
Обтекай, старпёр.
Условно разделим этот список данных на юниты, каждый из которых состоит от 2 (минимально необходимое) до 4 (оптимальное). Соответственно очень грубо посчитал примерное количество символов в строке и пришел к выводу, что там будет где-то 80 байт, но досыпал ещё чуток.
Если один юнит этого списка весит 150 байт, предположив, что это усредненное значение, а количество юнитов будет около 100000000, то передать нужно будет 15000000000 байт информации.
Если предположить, что скорость передачи данных будет около 20 Mbps, то на один юнит будет уходить по 0.0572205 ms.
За один запрос, который, надеюсь, будет проходить за 0.5 секунды мы можем вытащить до 6000 юнитов. Передать 6000 юнитов, как мы посчитали выше, займет 343.323 ms.
Другими словами, 1000 ms - 343 ms - 500 ms = 157 ms.
А сюда ещё надо добавить выгрузку данных в базу, учесть провисание сети многое другое. Теоретически можно повысить пропускную способность в два раза, что сэкономит ещё ~150 ms, однако обработка массива данных должна уложиться в 200 ms. базу данных хочу Clickhouse использовать, ибо разработчики заявляют нихуевый такой перформанс.
Что такое обработка? Приходит огромный массив от нескольких кб до нескольких мб. Около 7-8 полей, которые нужно распарсить (JSON), конвертировать в csv формат и записать на диск. (все поля не нужны)
Концептуально я пока думаю работать так:
Накапливать в ОЗУ большой объем данных, сохранять в csv файл, сжимать его архиватором и передавать в базу, где доступ к данным можно уже будет в риалтайме получать. Однако насколько какой-нибудь List/Array/etc эффективен для этого? Как организовать многопоточность в таком случае? И опять же, сохранять файлы на диск. Если есть SSD и сохранять по 50-100 mb, то не должно же сильно сказаться на производительности?
Другой вопрос на каком языке это все писать. В спешке писал на Java, ибо там все из карбоки, но использовал другую схему. Request -> обработка -> передача в очередь -> обработка -> сохранение данных. Однако скорость дохуя медленная. Обработка одного блока данных из 4 тысяч юнитов занимала порядка 3.7 секунды, что бесконечно много для такой операции. Можно устранять избыточность запросов к БД, создать адекватное соединение, но моя гипотеза такова, что я не смогу организовать работу серьезно быстрее.
Собственно, поэтому такие вопросы.
- Многопоточность. Как оптимально организовать доступ к очереди?
- Объем данных. Когда и как писать в файл?
- Технологии. Может быть я не знаю что-то не знаю\не знаком, что позволит быстро переваривать большой объем данных и сохранять его.
- Советы. Опять же, может быть я что-то воспринимаю не так или не совсем корректно понимаю. Рад выслушать все рекомендации.
Условно разделим этот список данных на юниты, каждый из которых состоит от 2 (минимально необходимое) до 4 (оптимальное). Соответственно очень грубо посчитал примерное количество символов в строке и пришел к выводу, что там будет где-то 80 байт, но досыпал ещё чуток.
Если один юнит этого списка весит 150 байт, предположив, что это усредненное значение, а количество юнитов будет около 100000000, то передать нужно будет 15000000000 байт информации.
Если предположить, что скорость передачи данных будет около 20 Mbps, то на один юнит будет уходить по 0.0572205 ms.
За один запрос, который, надеюсь, будет проходить за 0.5 секунды мы можем вытащить до 6000 юнитов. Передать 6000 юнитов, как мы посчитали выше, займет 343.323 ms.
Другими словами, 1000 ms - 343 ms - 500 ms = 157 ms.
А сюда ещё надо добавить выгрузку данных в базу, учесть провисание сети многое другое. Теоретически можно повысить пропускную способность в два раза, что сэкономит ещё ~150 ms, однако обработка массива данных должна уложиться в 200 ms. базу данных хочу Clickhouse использовать, ибо разработчики заявляют нихуевый такой перформанс.
Что такое обработка? Приходит огромный массив от нескольких кб до нескольких мб. Около 7-8 полей, которые нужно распарсить (JSON), конвертировать в csv формат и записать на диск. (все поля не нужны)
Концептуально я пока думаю работать так:
Накапливать в ОЗУ большой объем данных, сохранять в csv файл, сжимать его архиватором и передавать в базу, где доступ к данным можно уже будет в риалтайме получать. Однако насколько какой-нибудь List/Array/etc эффективен для этого? Как организовать многопоточность в таком случае? И опять же, сохранять файлы на диск. Если есть SSD и сохранять по 50-100 mb, то не должно же сильно сказаться на производительности?
Другой вопрос на каком языке это все писать. В спешке писал на Java, ибо там все из карбоки, но использовал другую схему. Request -> обработка -> передача в очередь -> обработка -> сохранение данных. Однако скорость дохуя медленная. Обработка одного блока данных из 4 тысяч юнитов занимала порядка 3.7 секунды, что бесконечно много для такой операции. Можно устранять избыточность запросов к БД, создать адекватное соединение, но моя гипотеза такова, что я не смогу организовать работу серьезно быстрее.
Собственно, поэтому такие вопросы.
- Многопоточность. Как оптимально организовать доступ к очереди?
- Объем данных. Когда и как писать в файл?
- Технологии. Может быть я не знаю что-то не знаю\не знаком, что позволит быстро переваривать большой объем данных и сохранять его.
- Советы. Опять же, может быть я что-то воспринимаю не так или не совсем корректно понимаю. Рад выслушать все рекомендации.
И я там кажется обосрался. Уже сам не знаю, как считать. Короче, у меня цель - один блок информации в секунду. От запроса к серверу до выгрузки в базу данных.
Один блок информации - от 1 до 6000 юнитов. Вариативность объема юнита от 4 байт до 70 байт (по оптимистичном расчету) и до 150 байт (по грустному расчету)
>Один блок информации - от 1 до 6000 юнитов. Вариативность объема юнита от 4 байт до 70 байт (по оптимистичном расчету) и до 150 байт (по грустному расчету)
К сожалению, вайпнул всю информацию. Могу лишь сказать, что в среднем на блок информации - 1000 юнитов. Да, долбоеб, не посчитал моду, например. Про объем юнита просто в голове прикинул. Могу ошибаться, так как у меня при сохранении некоторых юнитов в бд были сообщений о том, что varchar(256) превышен, что пиздец странно.
И еще объясни, ты хочешь в реалтайме принять данные по сети, сконвертировать и сохранить на диск, а обрабатывать ты уже будешь потом?
Почему не взять юниты большего размера? У тебя узкое место в скачивании данных? Его же никак не ускорить.
>- Многопоточность. Как оптимально организовать доступ к очереди?
Уверен это распространённая проблема и статьи экспертов помогут тебе больше чем советы с двача.
Максимальный = 6000 юнитов на блок. Необработанный юнит может весить и по 1 кб, обработанный = 150 байт, так как извлекаются всего 2 поля.
>>800790
Нет, у меня есть идея, как увеличить пропускную способность: сжать документ, найти канал шире. Узкое место скорее всего тут исключительно в обработке данных.
Насколько эффективно записывать блоки данных сначала в ОЗУ, а потом в файл?
>>800791
Схема такая:
1. Ответ->пишем в массив нужные поля->пишем в файл.
2. Сжимаем файлы
3. Загружаю их на сервер бд
4. Расжимаю
5. Пишу в БД.
>>800797
Зашел сюда чисто по старой памяти. Очень мило общались с Qt господином. Да и к тому же, анон частенько дает дельные советы.
>Схема такая:
У тебя 20мбит потока данных всего, нафиг ты хочешь сжимать, а, шакал? Я более чем уверен, что ты добьешься нужной производительности и на своем проекте на джаве, просто нужно запустить профайлер и посмотреть, где оно тормозит.
Торрент-клиенты и 500мбит могут выдавать, твоя задача очень скромненько смотрится на их фоне.
Хорошо, а подход вообще целесообразен? Просто мой предыдущий подход, который мне казался наиболее оптимальным (запрос->обработать->очередь->отправить в бд->сохранить в бд) брал почти по 3.7 секунды на блок, что пиздец, как много.
>запрос->обработать->очередь->отправить в бд->сохранить в бд
А типа есть другие варианты, лол?
>брал почти по 3.7 секунды на блок
Для таких проблем умные люди придумали профайлер. Может у тебя там менеджер памяти дохуя времени тратит, а все остальное ходит быстро. Тогда тебе просто нужно пул данных заебенить и все будет круто.
>А типа есть другие варианты, лол?
Очередь у меня была в облаке, поэтому может быть и задержка была - sqs. Второй обосрамс, что я видимо сделал крайне хуевый десериалайзер и сериалайзер json объектов. В итоге у меня один блок дважды парсится, бля. Наверное, в облако стоит тупо только обработанный юнит отправлять без обертки.
Мой же вариантименно генерить большой файл на стороне обработчика, а потом его сразу передавать на сервер, можно сжать.
Ладно, хотя бы теперь яснее стало, пока все описывал. Попробую на Java дописать, а там может и на крестах.
>Очередь у меня была в облаке, поэтому может быть и задержка была - sqs
Почему у тебя очередь и парсер на разных тачках? Ты планируешь масштабирование?
Олсо, я нигде не могу найти вменяемых бэнчей (ага, потому что не знаю, что гуглить). Вдруг Java дохуя медленная будет для этой задачи.
Ну ты блин гонишь
https://www.google.com/search?client=safari&rls=en&q=java+profiler&ie=UTF-8&oe=UTF-8
Бля, ну профайлер - это заебись, но я бы хотел посмотреть, например, как себя ведут те или иные типы данных vector vs. x и т.д. Выгугли библиотеку, которая json парсит. Выбрал правильно, пока читал - понял, что говном занимаюсь.
Если описать алгоритм подробнее.
Запрос-ответ=>кидаю внутреннему воркеру в отдельный тред=>вытаскиваю данные=>упаковываю опять в нужный json=>отправляю в очередь=>ловлю в очереди=>распаковываю=>отправляю в бд.
В общем, действительно прихожу к выводу, что нужно во-первых, оптимизировать парсер json, срать не в облако, а себе в ФС, а потом погонять профайлером.
Ты заебал, лалка. Твою поделку в любом случае вскроют быстрее, чем очко твоей мамаши, понимаешь ты это?
Ты не того детектишь, петушок. Меня удивляет, вообще, что форс Куранина настолько серьезным. Думал сначала, что кто-то траллит или распространяет криптолокер, а там, похоже, действительно самодельный антивирус. Пацаны его даже реверсили.
Почему этот heap-based Prim's Minimum Spanning Tree algorithm не работает?
Потому что это не heap-based prim's minimum spanning tree algorithm.
А может и ты. К чему эти нелепые отговорки? Стыдишься чего-то, петушок?
Я всё понял.
Т.е. в задаче надо сделать так, чтобы последнее отображение было после 1000, а у меня получается до неё.
>Взял короче книжку по крестам из шапки, которая референс от Страуструпа и которая устаревшая, и это, ебать там всё
Читал какого-то Стравуструпа в 15 лет, когда дрочил на вирасы и журнал ксакеп. Понимание какой-то сложности не представляло. Архитектура пека гораздо сложнее синтаксиса и библиотеки петушиных крестов.
Не было бы интересно - не лез бы.
std::transform (std::begin(v), std::end (v), std::begin (l), std::back_inserter (res), std::less);
Попробуй ангельскую версию же. Она не устарела и не зашкварена отвратительным имхо какого-то русского старпера, поэтому читается легче.
Хорошо. Больше не буду лезть с тупыми постами.
И вдогонку. Сложность это то, что добавляет шарм и магию, возбуждает интерес. Простые вещи быстро приедаются.
Асмотред-то утонул, а у сишников сидят какие-то поехавшие и дрочат на синтаксис.
Конечно. Сколько раз в секунду они обновляют результирующее изображение
Сишники не могут дрочить на синтаксис, там ~50 ключевых слов.
Если хочешь посмотреть на реальное задрачивание синтаксиса и неочевидной хуйни, ты на месте.
Пикрелейтед - как я сделал в designer-e. Фрэйм с белым бэкграундом и парочкой label в нем.
вот код, который не работает:
http://pastebin.com/uZv2tUQs
http://acm.timus.ru/problem.aspx?space=1&num=2093
Вот сюда вот отправляй
все тот же классный парень >>801427
Заменил QFrame на QWidget - все работает.
Но мне не хватает некоторый хейдеров. string.h stdlib.h. Жалуется что не может их найти поэтому не компилирует мой хэлоуфорд. Как их все установить?
Первый пост не мой. Я уже код написал. http://pastebin.com/KTEhj139 Виндой давно не пользовался и не могу туд компилятор установить. >>801473
Помоги
Это шутка такая.
Анон-погромист, выручай!
- Тебе нравятся мои методы, да?
- Да!
- А мне нравятся предупреждения!
- Все кому нравятся предупреждения - говнокодеры!!!
- Мне нравится, как они подсвечиваются...
- СУКАНАХ!!!
- Нравятся ошибки...
- Суканах!
- Нравится крашиться...
- Суканах!
- Я люблю костыли...
- СУКАНАХ!
- Я хочу костыль, я знаю, что тебе тоже нравится... Я знаю, что тебе нравится, что я хочу костыль... Тебе нравятся мои макросы, мне тоже. А еще мне нравятся нестандартизованные фичи...
- Суканах!
- Хочу неопределенное поведение! Я так хочу!
- А я не хочу!
- Хочешь почувствовать мои баги своим отладчиком? Хочешь?
- Сучка, ты сводишь меня с ума, заткнись! Ты испорчена! Тебе нет места в памяти!
- Я чувствую, тебе нравится... Ты сходишь с ума от моей скорости...
- Я оптимизирую тебя.
- Ты оптимизируешь меня? О как прекрасно, обожаю оптимизации, и тебе тоже понравится. Обожаю cstdlib, обожаю ассемблерные вставки... Вот это да! Этот профайлер, он сводит тебя с ума... Видишь, он тебе нравится, и я тебе нравлюсь. Перепиши меня, это же так естественно... Нравится? Ведь нравится. Быстрее... Быстрее!
- Ты настоящая сука!
- Собирай релизную версию... Вот молодец...
- Что ты задумала?!!
- Чудненько, а теперь посмотри на размер моей кучи...
- Суканах!!!
- Мне так нравится...
- Нет, а если я добавлю памяти? Нет! Сука, блядь, дедлайн близок... Ах ты сука! Ты меня совращаешь, блядская сука, СУКА!!! Сука... Знаешь, что бывает с такими суками? Знаешь? Их запускают под valgrind'ом, запускают без отладки!
- О да, виртуализуй мой процесс! Как это прекрасно... Трассировка это прекрасно, вдвигай поглубже, глубже, в библиотеки...
- Получай, сука! Вот тебе за все хорошее! Нравится, сука? Вот тебе статический анализ! Я отправляю коммит!!!
- Пора бы...
- Смотри, сука! Иди сюда... Смотри! Смотри, что ты наделала! Это ты виновата...
- Тебе нравятся мои методы, да?
- Да!
- А мне нравятся предупреждения!
- Все кому нравятся предупреждения - говнокодеры!!!
- Мне нравится, как они подсвечиваются...
- СУКАНАХ!!!
- Нравятся ошибки...
- Суканах!
- Нравится крашиться...
- Суканах!
- Я люблю костыли...
- СУКАНАХ!
- Я хочу костыль, я знаю, что тебе тоже нравится... Я знаю, что тебе нравится, что я хочу костыль... Тебе нравятся мои макросы, мне тоже. А еще мне нравятся нестандартизованные фичи...
- Суканах!
- Хочу неопределенное поведение! Я так хочу!
- А я не хочу!
- Хочешь почувствовать мои баги своим отладчиком? Хочешь?
- Сучка, ты сводишь меня с ума, заткнись! Ты испорчена! Тебе нет места в памяти!
- Я чувствую, тебе нравится... Ты сходишь с ума от моей скорости...
- Я оптимизирую тебя.
- Ты оптимизируешь меня? О как прекрасно, обожаю оптимизации, и тебе тоже понравится. Обожаю cstdlib, обожаю ассемблерные вставки... Вот это да! Этот профайлер, он сводит тебя с ума... Видишь, он тебе нравится, и я тебе нравлюсь. Перепиши меня, это же так естественно... Нравится? Ведь нравится. Быстрее... Быстрее!
- Ты настоящая сука!
- Собирай релизную версию... Вот молодец...
- Что ты задумала?!!
- Чудненько, а теперь посмотри на размер моей кучи...
- Суканах!!!
- Мне так нравится...
- Нет, а если я добавлю памяти? Нет! Сука, блядь, дедлайн близок... Ах ты сука! Ты меня совращаешь, блядская сука, СУКА!!! Сука... Знаешь, что бывает с такими суками? Знаешь? Их запускают под valgrind'ом, запускают без отладки!
- О да, виртуализуй мой процесс! Как это прекрасно... Трассировка это прекрасно, вдвигай поглубже, глубже, в библиотеки...
- Получай, сука! Вот тебе за все хорошее! Нравится, сука? Вот тебе статический анализ! Я отправляю коммит!!!
- Пора бы...
- Смотри, сука! Иди сюда... Смотри! Смотри, что ты наделала! Это ты виновата...
> Данная информация предназначена только только для IT-специалистов по системной интеграции модулей БИОСОФТ-М.
Похуй должно быть. mingw везде одинаковый. Как его блять устанавливать?
Да мне всего пару хейдеров надо. Как из докачать?
mingw обычный вроде не в моде сейчас. Везде mingw-w64.
Можешь попробовать поставить его через MSYS2.
Только запускай не msys-shell, а mingw-w64 shell если хочешь подключать виндовые хедеры.
А что это? Там winapi есть?
Ты ещё djgpp посоветуй.
Ну так и fps не 120, лалка.
НО, если я ввожу большие числа, например 1000000, то там начинается бесконечное непонятно что - пикрил.
Я правильно понял что это из-за того, что int имеет ограничение на размер? Если так - как его обойти, если не так, что я не так сделал? С маленькими значениями работает ок.
Сдела лонг лонг,
с 1 000 000 000 работает
с 1 000 000 000 0 не работает
А как сделать чтобы работало? Или это уже продвинутый уровень?
использовать длинную арифметику..
Профа у меня нихуя не прогерская, т.е. на след курсе мы будем делать проги для подсчёта интегралов, а никаких новых курсов по проге не будет. Прочитать книгу с более глубоким подходом к изучению и опять сосницкого сделать? Что мне делать?
ну блять, определись, что именно ты хочешь написать и двигайся.. просто гугли. программист, не использующий гугол - !программист.
Я не он, но я хочу писать игры.
>>801925-кун
Сначала доизучаю книгу страуструпа, а дальше будут смотреть в сторону дума первого.
Хочу сделать что-то типа своего дума с открытым миром, рпг и т.д. с такой графикой.
игры делаются так:
1. пишется движок. там определяется физика, хуйня с графикой разная, ну и т.п. Нужны знания с++(на чем-нибудь другом напишешь или напишешь, но хуево - твое говно будет лагать), тригонометрии, как выводить графику и еще там чето я хз.
2. на самом движке создается игра. тут все уже намного легче, потому что почти никаких знаний и не надо.
если тебя интересует первое, то просто выучи синтаксис, а потом почитай что-нибудь специализированное. там и про оптимизацию и про матчасть должно быть.
если второе, то просто выучи синтаксис.
В общем, нужно посчитать как можно быстрее количество строк в файле (должно быть не более 1 048 576 строчек).
Но погоди отправлять меня в учебник по С++. Суть в том, что я не знаю, как это сделать эффективнее. В целом задача стоит так:
Объединить огромное количество файлов, каждый из которых может состоять из 0-6000 строк в файлы по 1 048 576.
Как бы самое очевидное - нужно тупо создавать новый файл, при достижении 1 048 576 строк сохранять его и проходить так по всем файлам.
Другой вопрос, что найти в каждом файле "\n" дохуя долгая задача, как мне кажется. Какие есть варианты решения?
Пока что я вижу только такио решение:
1. Создать вектор
2. Открыть первый файл
3. Записывать в вектор все строки.
4. При достижении i = 1048576 сохраняем вектор в файл, возвращаемся к пункту 2.
Есть ещё варианты, как сделать быстрее?
перемещающие копирование и присваивание по-умолчанию
constexpr
Это пиздец...
Строка где-то от 70 до 150 байт занимает.
А ты, если я правильно понял, предлагаешь создать массив из 1048576 элементов? Плюс ещё данные терять бы не хотелось.
Зачем вектор? Просто делай fread(), если счетчик не переполнился fwrite().
считывай в буферный массив 4+-2 мегабайт, затем из буферного массива в выходной файл.
>Есть Visual Studio 2013, с++11 стандарт уже вышел
>2016
>C++17
>Visual Studio 2015 Update 3
Марти, ты ли это?
можно уже и vs 15 превью поставить, если хочешь быть на острие
https://ideone.com/EoXjv0
вроде установил. Добавил в PATH путь до /MinGW/bin
Теперь вопрос. Как добавить возможность компилировать c++11?
Если писать так g++ main.cpp, то ругается на синтаксис c++11, если писать так g++ -std=c++11 main.cpp то ругается еще больше. Как быть?
Это все было на работке, сейчас я дома за бубунтой. Завтра все скину
На секунду вернулся на ЛОР образца 2008 года. Приятные воспоминания...
Бамп вопросу.
Все верно. Алгоритмы с бесконечным кол-вом входящих данных нельзя потестить. Да и не надо. Нужно тестить общий случай (1 - 2 кейса) и граничные.
Т.е. если ты тестируешь арифметическое сложение, то тупо делать так:
assert ( 1+1 = 2)
assert ( 1+2 = 3)
assert ( 1+4 = 5)
и т.д.
Нужно проверить обычное сложение (1 + 5), отрицательные операнды (1 - 4, -1 + 4, -1 + -6) и ситуацию с переполнением.
Доказывай, а не тести.
Отвечайте
Всё правильно делаешь. Сначала учишь Си с классами, потом его забываешь и с каждой сотней страниц учишь всё более современный с++.
Не траль плиз
Смищно, потому что CUDA 7 версии (в том числе и 7.5) работает только на MSVC 2013, ахахахаха.
Вроде 8 уже поддерживает 2015
>> fatal error C1189: #error: Microsoft Visual Studio
2015 Update >= 2 is not supported yet!
КЕК, я ебал эту нвидиа
И встретил пару моментов, которые я понять не могу. Будьте дбобры объясните.
string iname = "test";
ifstrean ist(iname); //В книге синтаксис прямой инициализации был такой ist{iname} в MSVC2010 не работает
ist.exceptions(ist.exceptions()|ios_base::badbit);
Полез смотреть на cplusplus/reference там
void exceptions(std::ios_base::iostate except);
Вроде как exceptions() принимает параметр iostate except. И устанавливает значение iostate goodbit, badbit, failbit или eofbit.
Но что в этом примере ist.exceptions(ist.exceptions()|ios_base::badbit); вернет второй ist.exceptions() который передается как параметр в функцию?
Символ | это побитовое или?
И еще запись такого вида впервые встречаю.
vector<Point> points;
for (int p : points){некое действие};
что происходит в for (int p : points), потому, что всегда встречал : в списках инициализации сущностей классов пример
class Foo
{
public:
Foo(int i, int j = 0) : m_i(i), m_j(j){}
private:
int m_i, m_j;
};
ist{iname} - это новый вид инициализации в c++11
ist.exceptions(), очевидно, вернет текущую маску, а | ios_base::badbit добавил badbit. | - это побитовое или, да. С помощью & и | легко ставить флаги в одно число, а не заводить несколько булинов.
for (int p : points){некое действие}; - это новый вид циклов, введенный в c++11. Удобен для итерирования всякого рода контейнеров (массивов / stl-контейнеров).
В общем, читай про фичи c++11
Начать писать на Rust или Go.
Весьма благодарен.
>MSVC2010
Сейчас какой год, мудень? Десятый?
Ещё и литру 89 года выпуска возьми, для консистентности рабочего окружения.
https://ideone.com/UzhSnu
http://www.cplusplus.com/reference/list/list/erase/
>Return value
>An iterator pointing to the element that followed the last element erased by the function call. This is the container end if the operation erased the last element in the sequence.
В книге написано, что инвалидируются все итераторы и ссылки на элементы, следующие после удаляемых, а ты мне про return value втираешь. Страшилки из книги не воспроизводятся.
http://www.cplusplus.com/reference/list/list/erase/
>Iterator validity
>Iterators, pointers and references referring to elements removed by the function are invalidated.
All other iterators, pointers and references keep their validity.
Хочу стать супер оптимизатором, смотреть, что за ассемблерный код там сгенерировался, использовать ассемблерные вставки и прочее.
Но ассемблер я почти не знаю. Было дело как-то давно в универе, но я абсолютно ен помню ничего.
Собственно, вопрос:
Что мне почитать про ассемблер? Что мне нужно знать про архитектуры процессоров(под разные архитектуры - разные языки же)? Что мне нужно знать, касательно С++?
Тебе нужно научится писать на плюсах (а не учить ассемблер) и оптимизировать в первую очередь алгоритмы – вот и 95% производительности в любом софте.
Спасибо. Именно то, что я искал.
>2013
>какой сейчас год
Ты дурак или прикидываешься, няша? Ну открой шапку, там есть ссылка на прекрасную последнюю VS 2015, в которой половина проблем старых версий давно решена.
Если убрать == 0, но оставить приведение по модулю, то код компилируется и запускается.
https://ideone.com/FvKaCp
Если у списка написать ==0, то тоже все валится. http://stackoverflow.com/questions/4645705/vector-erase-iterator
С ним все в порядке. erase() возвращает указатель на следующий элемент за удаляемым. После удаления последнего итератор указывает туда же, куда и end(), но потом увеличивается в цикле и вылезает out of range.
От сейфа?
Смотри, когда ты присваиваешь it = u.erase(it), то it указывает на следующий элемент. Далее, значение it инкрементируется и проверяется условие it != u.end().
Если коротко, то при удалении элемента, кратного двум, ты пропускаешь следующий. Т.к. последнее число у тебя кратно двум 10, то при его удалении it становится равным u.end(). Но дальше у тебя it инкрементируется и получается что, out of range.
Почему работает с if (*it % 2)? А оно тоже не работает! Оно будет удалять только нечётные элементы (и оно точно также перепрыгивает через одно при удалении).
Вот тебе исправленный вариант:
https://ideone.com/TunlsB
Надеюсь достаточно подробно рассписал
void foo(vector<int> v, int a){
for_each(v.begin(),v.end(),[a](int b){cout << (b<a);});
}
Как сделать то же самое без лямбда-выражения? То есть передать в for_each предикат с 1 параметром, но при этом с еще одной переменной "извне".
И функторы тоже нельзя использовать.
bind
А нахуя так вообще делать?
Ни разу не пытаюсь критиковать желание, но хотелось бы узнать у анона - вообще актуально ли в 2016 использовать ассемблерные вставки? Всегда казалось, что компилятор почти во всех случаях генерит крайне годный код. Не выйдет ли так, что оптимизация ручками будет либо в ноль, либо слишком маленький прирост или вовсе тормоза?
нахуй тебе код? Тебе достаточно знать то, что там используются штучки с++11
1) Открой, например, исходники любого видеокодека – куча ассемблерного кода. И так во всех проектах где нужно делать что-то за 0.02 вместо 0.05. Или можешь посмотреть как пишутся всякие алгоритмы компрессии;
2) Будешь неаккуратен – словишь как раз таки регрессию производительности, т.к. сама вставка и всё что с ней связано оптимизироваться не будет (поэтому кстати куски которые нужно написать на асме пишут на нём полностью, а не вставкой с парой инструкций), а так же есть куча платформозависимой хуиты и хуиты в разных компиляторах (в стандарте прописана только необходимость наличия вставок, остальное не оговаривается от слова совсем).
https://ideone.com/bp36j1
И как в случае отсутствия элемента в векторе вернуть v.end(), если сам вектор я не хочу передавать в функцию?
когда нужно использовать специализированные инструкции цп, гп или чего-нибудь еще
Что не так с этим кодом? Один баг я пофиксил, заменив std::min на std::min_element. Но теперь происходит что-то непонятное.
Как минимум std::iter_swap вместо std::swap
Остальное не проверял, просто за что глаз сразу зацепился.
С iter_swap'ом лучше, но все еще не работает как надо. https://ideone.com/ylzMAK
Пошел читать про iter_swap.
- auto smallest = std::min_element (it + 1, v.end());
+ auto smallest = std::min_element (it, v.end());
Что должен уметь делать джун-девелоп с++?
И как можно оценить свой уровень?
Почему так? Я рассматриваю текущую ячейку it и ищу минимум среди следующих за ней ячеек. Найденный минимум свапаю со значением it.
А если в текущей ячейке элемент меньше всех, идущих после него? Как у тебя на втором шаге, когда it == 2, а smallest == 3
Тогда, видимо, у Кормена ошибка. Его алгоритм будет свапать элемент в текущей ячейке даже если он наименьший.
Он ищет минимум среди элементов от (i+1)-го до n-го. Предполагается, что выполняется инвариант цикла, состоящий в том, что элементы до i-го включительно минимальны и отсортированы. Но у меня почему-то так не работает.
В самом деле. Когда алгоритм простой, я как-то пропускаю некоторые детали.
просто не лезь сюда, на работу все равно не устроишся, явка, веб может быть еще успеешь..
Веб как-то не впечатил(
Я полгода в вузе учил си, потом плюсы ещё столько же.
Ща шароюбюсь по гиту, исправляя баги в kdeшных программах(легкие).
Вот и хочу узнать возмут ли меня куда-нибудь джуном или надо что-то подучить.
Конкуренции боишься?
Нет, баги -это новые фичи или некритичные недоделки, которые висят в вишлисте на сайте кде и касаются уже функционала программ.
Но это уход в сторону от вопроса.
Так что должен уметь джун?
Да тебя, аутиста, и auto вместо int смешит.
Писать рабочий код, не слишком выбивающийся из принятых в коллективе конвенций. Простые истины типа code complete надо. Виртуальные деструкторы надо. Анальные пляски на мутирующих шаблонах не надо, если только это не проект специально для создания какой-нибудь уберлибы. Оптимальность надо на примитивном уровне типа отсутствия дублирования данных, экспоненциальных алгоритмов и подобных непотребств, умение дрочить ассемблер не надо, но приветствуется в эмбеддеде.
Обучаемость. Уметь быстро нагуглить и понять то, чего не знаешь. Знание либ и фреймворков, которые используются в проекте, желательно, но не так важно, ибо это все равно вопрос пары недель, если ты нормально схватываешь инфу.
Уметь читать любой код, даже написанный пьяным гуру метапрограммирования 10 лет назад. Чтение с гуглом считается, никого не волнует, что ты там помнишь, главное чтобы не нужно было отвлекать серьезных дядь на разъяснение кода тебе.
Знания по предметной области. В случае, когда задача общая, этот пункт пропускается, но даже не надейся найти вакансию с такими условиями, крудошлепства на крестах нет уже лет 15.
Первые три пункта всегда находятся именно в таком порядке друг относительно друга, по убыванию важности. Четвертый пункт может быть на любом месте, в зависимости от ситуации.
Спасибо.
Думаю, что пойду в ближайшее время что-то искать по работе.
Пока не очень получается ориентироваться в классах больших проектов.
То бишь мне должны примерно сказать где вносить правки.
Это с опытом приходит?
Ты меня, человека который написал змейку, учишь, что такое баг?
>исправляя баги в kdeшных программах
Сам ищешь? Почему до тебя их никто не нашёл и не исправил? Ты знаешь какой-то секрет?
За веб хоть платят, а на придумывание своей пердольной ебы финансов нету.
Да. Но тебе скорее для начала дадут таску, где ты пишешь с нуля какой-нибудь второстепенный модуль, а не правишь чужие.
Да, я знаю их секрет.
У них есть сайт с описанием багов.
Вбиваешь в поиске jj + название программы и готово.
https://bugs.kde.org/
Не.
#include "stdafx.h"
#include <iostream>
#include <cstdlib>
#include <Windows.h>
#include <cstdio>
#include <cstring>
#include <cctype>
#include <conio.h>
#include <process.h>
using namespace std;
int main()
{
setlocale(LC_ALL, "Russian");
setlocale(LC_ALL, "ru_RU.UTF-8");
setlocale(LC_ALL, "");
{
typedef unsigned long int uli;
typedef long double ld;
ld num, a, b, c;
uli x, y, z;
main_menu:
cout << "Введите число, соотвествующее командам, представленным ниже:" << endl;
cout << "1. Сложение." << endl;
cout << "2. Вычитание." << endl;
cout << "3. Умножение." << endl;
cout << "4. Деление." << endl;
cout << "0. Выход из программы." << endl;
cin >> num;
if (num == 1) {
cout << "Введите первое слагаемое:" << endl;
cin >> a;
cout << "Введите второе слагаемое:" << endl;
cin >> b;
c = a + b;
cout << "Сумма слагаемых равна: " << c << endl;
goto main_menu;
}
else if (num == 2) {
cout << "Введите число, из которого будем вычитать:" << endl;
cin >> a;
cout << "Введите вычитаемое:" << endl;
cin >> b;
c = a - b;
cout << "Разность равна: " << c << endl;
goto main_menu;
}
else if (num == 3) {
cout << "Введите число, которое будет умножаться:" << endl;
cin >> a;
cout << "Введите число, на которое будет умножаться первое число:" << endl;
cin >> b;
c = a * b;
cout << "Произведение чисел равно: " << c << endl;
goto main_menu;
}
else if (num == 4) {
cout << "Введите число, которое будет делиться:" << endl;
cin >> a;
del:
cout << "Введите число, на которое будет делиться первое число:" << endl;
cin >> b;
if (b = 0) {
cout << "На ноль делить нельзя! Введите второе число заново." << endl;
goto del;
}
else {
c = a / b;
cout << "Деление дало результат: " << c << endl;
goto main_menu;
}
}
else if (num ==0) {
exit(0);
}
else {
cout << "Число введено неправильно! Попробуйте ещё раз." << endl;
goto main_menu;
}
}
system("pause");
return 0;
}
Правильно ли я всё сделал?
#include "stdafx.h"
#include <iostream>
#include <cstdlib>
#include <Windows.h>
#include <cstdio>
#include <cstring>
#include <cctype>
#include <conio.h>
#include <process.h>
using namespace std;
int main()
{
setlocale(LC_ALL, "Russian");
setlocale(LC_ALL, "ru_RU.UTF-8");
setlocale(LC_ALL, "");
{
typedef unsigned long int uli;
typedef long double ld;
ld num, a, b, c;
uli x, y, z;
main_menu:
cout << "Введите число, соотвествующее командам, представленным ниже:" << endl;
cout << "1. Сложение." << endl;
cout << "2. Вычитание." << endl;
cout << "3. Умножение." << endl;
cout << "4. Деление." << endl;
cout << "0. Выход из программы." << endl;
cin >> num;
if (num == 1) {
cout << "Введите первое слагаемое:" << endl;
cin >> a;
cout << "Введите второе слагаемое:" << endl;
cin >> b;
c = a + b;
cout << "Сумма слагаемых равна: " << c << endl;
goto main_menu;
}
else if (num == 2) {
cout << "Введите число, из которого будем вычитать:" << endl;
cin >> a;
cout << "Введите вычитаемое:" << endl;
cin >> b;
c = a - b;
cout << "Разность равна: " << c << endl;
goto main_menu;
}
else if (num == 3) {
cout << "Введите число, которое будет умножаться:" << endl;
cin >> a;
cout << "Введите число, на которое будет умножаться первое число:" << endl;
cin >> b;
c = a * b;
cout << "Произведение чисел равно: " << c << endl;
goto main_menu;
}
else if (num == 4) {
cout << "Введите число, которое будет делиться:" << endl;
cin >> a;
del:
cout << "Введите число, на которое будет делиться первое число:" << endl;
cin >> b;
if (b = 0) {
cout << "На ноль делить нельзя! Введите второе число заново." << endl;
goto del;
}
else {
c = a / b;
cout << "Деление дало результат: " << c << endl;
goto main_menu;
}
}
else if (num ==0) {
exit(0);
}
else {
cout << "Число введено неправильно! Попробуйте ещё раз." << endl;
goto main_menu;
}
}
system("pause");
return 0;
}
Правильно ли я всё сделал?
> вполне работающий код
> #include "stdafx.h"
> #include <conio.h>
> #include <process.h>
У меня твой "вполне работающий" код даже не скомпилируется. Уноси свой спермокод отсюда.
#include "stdafx.h" - необходимая параша для компиляции в Visual Studio (в моей версии).
#include <conio.h> и #include <process.h> для работы кода вообще нахуй не нужны, если ты об этом. Просто привычка совать это в любую парашу - мало ли, вдруг функционал пригодится.
>#include "stdafx.h"
precompiled headers выключи и все будет работать без этого.
>#include <conio.h>
нинужно
>#include <process.h>
нужно, но не тебе
Оп, спасибо за совет. Не знал, что их можно отключить. Кстати, а зачем они вообще в студии?
Чтобы не парсить один и тот же хедер, который инклудится 1000 раз в большом проекте.
Потому что разные типы данных?
У doubl'а есть лицензия на работу с очень большими числами, а у инта -- нет.
Потому что double хранит числа не точно. По сути он хранит небольшое число и степень, в которую число нужно возвести.
Отсюда появляется такое дерьмо:
double i = pow(2, 68);
assert(i == (i + 1));
Иногда один С++ заебывает, хочу почитать для развития что-нибудь про алгоритмы и организацию самих железок. Есть что-нибудь для ньюфагов, но без воды?
Вы видите копию треда, сохраненную 14 августа 2016 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.