[ d ] [ b / cu / dev ] [ r ] [ a / ts ] [ ci ] [ gnx / int ] [ misc ] [ dev / stat ]
[Burichan] [Futaba] [Gurochan] [Tomorrow] [Архив-Каталог] [Главная]

Файл: cpp_furudo_erika.png -(754 KB, 800x800, cpp_furudo_erika.png)
754 No.17934  
Учим C++ за 21 день всем чиочаном.
Можно показывать крутой или страшный код, просить помочь с лабами и контрольными, помогать другим, а главное - много кодить.

Пополняемый список полезностей тут: https://docs.google.com/document/d/1rPPbiViiLSR2PlPnQWpZyk9Sz6-J7ucyM7HR6wvsYKk/edit?usp=sharing
>> No.8273  
Файл: Cpp1.gif -(2 KB, 491x314, Cpp1.gif)
2
Привет, ты ведь знаешь много компиляторов c++?
Я хочу наконец-то слезть со своего c++ Builder 6 и перейти на что-нибудь современное. Работаю я с OpenGL-графикой и обработкой огромных массивов данных, а требования у меня примерно такие:
Венда, да. Кроссплатформенность приветствуется, но не обязательна.
Бесплатное и свободное ПО. Продавать программу не собираюсь, но всё равно не хочется когда-нибудь начать париться с лицензиями.
Поддержка 64-бит (хочется спокойно загружать в программу файлы без ограничения на размер).
Желательно наличие конструктора форм. Хотя в крайнем случае те же кнопочки и бегунки проще будет написать на чистом OpenGL'е.

Немного ознакомлен с MS Visual C++ и Qt, но переходить не спешу. Студия пугает привязкой к .net и несвободной лицензией, по поводу Qt не знаю, подходит ли он.
В общем, очень прошу, подскажите мне что-нибудь подходящее, или убедите сделать выбор в пользу Visual Studio или Qt.
Заранее спасибо.

Первый раз в dev, местных традиций не знаю. Если задел чьи-то чувства — прошу прощения.
>> No.8274  
Файл: 5ce854d98562f99ef5d6a18bac4a165d.jpg -(355 KB, 1260x1400, 5ce854d98562f99ef5d6a18bac4a165d.jpg)
355
Если хочешь рисовать формочки для C++, думаю нужно выбрать Qt. У microsoft, afaik, сейчас все gui тулкиты на .NET, а managed c++ - это недоразумение.
Из свободных компиляторов, собирающих Qt, есть g++ и clang. Насколько хорош clang, я не знаю, icc хватает.
>> No.8276  
>>8274
Автобусну рыжую мадоку.
QT Builder, наверное, будет идеальным вариантом. Только, то, что ты называешь "компилятор" на самом деле называется Integrated Development Environment.
>> No.8277  
>>8276
QT Creator.
http://qt.digia.com/Product/Developer-Tools/
>> No.8280  
>>8274
>>8276
>>8277
Спасибо. Значит, всё-таки qt. Попробуем-с.
>> No.8282  
Файл: f1da931c3fc779332d7efa0a2ea33975.jpg -(312 KB, 800x1100, f1da931c3fc779332d7efa0a2ea33975.jpg)
312
А я плюсану Visual Studio. И Visual Assist к ней. Все-таки стандарт разработки под венду, от ее же производителя. Хотя WinForms и привязан к .NETу и managed коду, практика показала, что довольно легко сделать гуй в управляемом классе, а всю логику вынести в набор неуправляемых, написанных уже классическим способом классов - это еще и приучает использовать шаблон MVC:3

Раз уж речь зашла про OpenGL, то можно вместо системного гуя использовать glfw + CEGui, например, чтобы формочки были красивыми и быстрыми(и кроссплатформенными, кстати).

Стивы, а поясните по QT: там используется свой компилятор, gcc, или микрософтовский? (при разработке под венду, естейственно)

И еще, воспользовавшись тредом, задам вопрос ОПа, только для линукса, так как мало с ним опыта имел - какую IDE посоветуете и почему?
>> No.8283  
>>8282
> А я плюсану Visual Studio.
Там уже появилась система сборки?

>там используется свой компилятор, gcc, или микрософтовский?
Можно использовать и mingw и msvc. В обоих случаях в процесс сборки включается некий дополнительный этап кодогенерации.

> какую IDE посоветуете и почему
Из юзабельных есть eclipse и QtCreator. Мне достаточно vim и cmake.
>> No.8284  
>>8282
> практика показала, что довольно легко сделать гуй в управляемом классе
Ох уж эти практики. C++ и так один из самых уродских языков, а managed - это вообще выкидыш-мутант. И находятся люди, которые на этом пишут и просят ещё.
>> No.8285  
Голосую за Qt.
Qt-няша
>> No.8287  
Файл: shot0260.png -(698 KB, 1280x720, shot0260.png)
698
> Работаю я с OpenGL-графикой и обработкой огромных массивов данных
> наличие конструктора форм
Выкинь из головы этот быдлопринцип привязывать главный алгоритм к гуям, сходи к венеролгу и прям так и скажи, «<имярек> подцепил билдер, что делать?»
> кнопочки и бегунки проще будет написать на чистом OpenGL'е.
Так ты формочки лепишь или огромные массивы данных обрабатываешь, я не пойму?
> В общем, очень прошу, подскажите мне что-нибудь
1. Отдели в своём мозгу компилятор и библиотеки от IDE;
2. gcc @ icc — вот твой выбор (у тебя же не амд?);
3. Забей на поддержку 64 бит. Даже Firefox дропнул поддерживать x86_64 сборки для венды, потому что тот пиздец, что там творится, не поддаётся описанию. По хорошему, чтобы открывать файл, используется вызов к операционной системе, и все языковые fopen() и ей подобные — лишь обёртки над системными вызовами. Соот-но если ось и/или её ФС не поддерживает оперативку и/или файлы на диске объёмом 4 GiB, ты с этим ничего не поделаешь;
4. Qt — жирный неповоротливый фреймворк для рюшечек. Я понимаю, почему ты хочешь взять именно это (сам такой был лет пять-шесть назад), но за то, где ты собираешься его применять, надо бить по щщам.
5. Есть полно других IDE, фреймворков и просто библиотек, начни с малого, я бы советовал попробовать писать интерфейсы на gtk2, не для того, чтоб потом этим зарабатывать, хотя это возможно, а для того, чтобы понять, как оно должно выглядеть без мегабайтов ненужного. А ещё есть WxWidgets и Code::Blocks например;
6. Вообще, никакой IDE не нужно, есть емакс.

>>8283
> Из юзабельных есть eclipse и QtCreator
Ты ещё NetBeans приплети, который жрёт по 700 метров на крохотный проект, падает по два раза в сутки, и при этом не имеет функции автосохранения из коробки.
>> No.8288  
Файл: tumblr_li8kl7tpjH1qa8ti8o1_500.jpg -(77 KB, 500x453, tumblr_li8kl7tpjH1qa8ti8o1_500.jpg)
77
>>8287
> Вообще, никакой IDE не нужно, есть емакс.
> емакс.

А туда уже добавили текстовый редактор?
>> No.8289  
Файл: 1286369096_kinopoisk_ru-luc-besson-1206812.jpg -(70 KB, 450x540, 1286369096_kinopoisk_ru-luc-besson-1206812.jpg)
70
>>8288
>> No.8290  
>>8287
>привязывать главный алгоритм к гуям
ОП похоже что-то визуализирует. Как ты собираешься отвязать алгоритм визуализации от гуёв?
> Qt — жирный неповоротливый фреймворк для рюшечек.
ОП собирается использовать OpenGL. Лучшей интеграции с OpenGL нет ни у одного другого тулкита, кроме каких-нибудь CEGUI/MyGUI. Почитай на досуге про QGL.
>есть емакс.
Этот раздутый комбайн в свою очередь не нужен, поскольку есть vim.
>Ты ещё NetBeans приплети
"Женский" аргумент. См. "Двенадцать приемов литературной полемики", пункт 7.
>> No.8291  
ОП на связи.
Моя задача — обсчитывать и сравнивать огромные файлы, а также визуализировать результаты в реальном времени. Данные общим объёмом превышают 32-битное ограничение.
Есть решение хранить всё на диске, строить оптимизацию и держать в памяти только то, что нужно для непосредственной обработки, но это и реализовывать будет неудобно, и жёсткий диск захлёбывается. Скорее всего, в таком случае работа в реальном времени невозможна.
Гуи мне определённо нужно, даже если его придётся «рисовать» самому, в окне OpenGL. Не проще ли использовать готовое решение?
Протестировал 32-битный Qt. Выглядит красиво, изящно. Очень многого не знаю, куча времени уйдёт на переучивание (пришлось искать в мануалах даже такие элементарные вещи, как преобразование числа в строку и обратно).
Сделал простой тест — сколько памяти выделяет программа (на 32-битном Qt): результат не отличается от Builder'а. Протестировал и Visual C++ — там раза в 4 меньше и жуткие тормоза. Таким образом не вижу строгой необходимости пока уходить с Билдера, если не найду чего-то объективно лучшего: с лицензиями меня никто трогать не будет, программу я не продаю.
Также обнаружил, что готовой 64-битной Qt под Windows нет, но её можно (!) собрать самому:
http://habrahabr.ru/post/79233/
Повторюсь, что местных традиций не знаю. Если здесь ненавидят этот сайт — прошу не бить.
Это вообще реально? Игра стоит свеч? Или кто-нибудь может предложить мне свежую идею?

Заранее спасибо.
>> No.8292  
ОП тролль. Зачем тебе какой-то там гуи тулкит если твоя задача - именно визуализация. Будь мужиком - используй голый openGL и не выпендривайся.
>> No.8293  
Файл: shot0086.png -(763 KB, 1280x720, shot0086.png)
763
>>8290
> ОП похоже что-то визуализирует.
Неочевидно.
> ОП собирается использовать OpenGL.
Если ты вдруг соберёшься прыгать в окно, это ничего не скажет о рациональности твоего поступка.
> поскольку есть vim.
Если на то пошло, ненастраиваемое бибикающее бинарное и ненужно.
> "Женский" аргумент. См. "Двенадцать приемов литературной полемики", пункт 7.
Иначе говоря, защитить Eclipse, Qt Creator и NetBeans ты не можешь. Ок.

>>8291
> а также визуализировать результаты в реальном времени
Ты там трёхмерную карту звёздного неба проецируешь или цифорки в огромном списке гоняешь?
> но это и реализовывать будет неудобно, и жёсткий диск захлёбывается.
Естессно захлёбывается, если ты пытаешься моментально прогнать через него пару гигабайт. Померяй ему среднюю пропускную способность каким-нибудь hdparm и поймёшь сколько реально он может считать в секунду. После подгрузки основного можно догрузить про запас ещё плюс-минус сколько-то для плавности. Хотя если заказчик хочет штоббыстромнетут, требуй от них систему, на которой можно было бы при запуске заталкивать весь каталог в оперативку и в ней уже гонять. Хотя я сомневаюсь, что Оп так сделает.
> Таким образом не вижу строгой необходимости пока уходить с Билдера, если не найду чего-то объективно лучшего
Как пить дать тормоза билдера и культей упираются в I/O, но культи, если они с gcc, можно было хотя бы подточить под машинку-то если это не 486.
>> No.8296  
Не могу понять, о чем вы тут трындите, наркоманы. Со старого сибилдера нужно переходить на новый. Собственно, всё.
>> No.8298  
Файл: motivationalnecromancy.jpg -(59 KB, 600x750, motivationalnecromancy.jpg)
59
>>8296
>Со старого сибилдера нужно переходить на новый.

Датс мах бой! Как говорится, похрен, что девушка не дышит, если она хорошо выглядит - можно трахать.
Борланд уже давно помер, и ембаркадера скорее всего последует его примеру.
>> No.8299  
>>8298
> DOS давно помер, и Windows 7 скорее всего последует его примеру. Пишите под линупс.
Логика настоящего программиста.
>> No.8300  
Под винду есть несколько С++ компиляторов:
Из часто используемых - MSVC, icc, MinGW
clang под винду пока что не очень жизнеспособен, даже транк.

По поводу 64 бит: У меня не было проблем с MSVC вообще, интел тоже работает, но с ним нужно быть аккуратнее: можно попасться на алиасинг и странные баги с -O2, если ОП знает что это такое. Правда это будет что с 32 битами, что с 64. Про мингв и 64 бита я ничего не знаю.
По поводу привязки студии к .нету - это ложь и провокации. Если тебе дотнет не нужен, то ты его просто не используешь. Если нужен, то используешь.
По поводу системы сборки у мсвц - вообще-то их есть аж 2,5 штуки, если ты не знал.
По Qt - своего компилятора там нет - там есть свой препроцессор.
>> No.8301  
Файл: 1477892-lady_death.jpg -(417 KB, 1111x864, 1477892-lady_death.jpg)
417
>>8299
>DOS давно помер, и Windows 7 скорее всего последует его примеру

Я даже не буду врать, что мне неприятно тебя расстраивать. Вот, посмотри на картинку с тетенькой раздетой.
( последняя версия винды уже 8, а она "немножко" отличается от привычных окошек )
>> No.8302  
>>8300
Не ложь и не провокации. Будешь писать на винапи - полысеешь и ослепнешь.
M$ вроде бы довольно давно намикает, где он видал тех, кто не пишет под .NET.
>> No.8308  
>>8302
А кто заставляет писать тебя на винапи?
Есть куча мультиплатформенных фрейморков, MFC тот же. Просто не обязательно лезть в дотнет. А если даже и лезть, то интерфейс куда проще и удобнее писать на C#, благо из дотнета дллки вызываются очень просто и безболезненно.
>> No.8309  
>>8300
> вообще-то их есть аж 2,5 штуки, если ты не знал.
С этого места подробнее. Я слышал про аналог make и видел эту xml-ную непереносимую гадость, адаптированную для мышководства. Аналог CMAKE/SCONS, который бы сам находил пути к библиотекам и инструментам и которым можно было бы управлять скриптами там есть?
>> No.8310  
>>8309
> аналог make
> xml-ную непереносимую гадость
ну и ещё одна версия оной

вот и 2.5 штуки, ты ж сам их знаешь.
Алсо, первая штука тоже непереносима же.
С библиотеками и прочим в любом случае под виндой придётся страдать, тут делать нечего, увы.
>> No.8311  
>>8310
Среди тех жопных затычек, что я перечислил, нет ни одной системы сборки. Значит в студия так и не обзавелась этим необходимым инструментом. Окошки-то хоть красивее стали? И да, что там с c++11?
>> No.8319  
>>8311
По поводу автоматического поиска библиотек под виндой - а искать-то их негде. В винде нет /usr/, /usr/local/ и прочего ведь. Как ты в таком хламе будешь искать библиотеки? Для того же cmake эти пути придётся прописывать руками.
Алсо, пара библиотек под виндой собираются мсовской nmake, я сам собирад.

По поводу С++11 - похуже, чем у clang и gcc, но они движутся вперёд. В последнем CTP появились variadic templates. Вообще, по С++11 статусу есть чудная табличка http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport
>> No.8321  
>>8319
> По поводу автоматического поиска библиотек под виндой - а искать-то их негде.

Я пользовался такой маргинальщиной как waf, так тот умел находить библиотеки CUDA и Qt, узнавая полный путь к nvcc и moc (при условии, что те прописаны в PATH). Boost, конечно, приходилось руками подключать.
>> No.8322  
>>8321
P.S. Ещё он умеет хитрым образом встраивать себя в студию, заменяя тамошнюю систему сборки.
>> No.8324  
>>8321
CUDA при установке прописывает себя в системные переменные окружения. Qt по-моему тоже. Так что это всё не считается.

>>8322
А в студии система сборки по-моему вполне выполняет свои цели, если не нужно кросплатформенность. А если нужно, то cmake умеет генерить студийные проекты. Правда я для этого им ни разу не пользовался.
>> No.8325  
>>8324
> Так что это всё не считается.
Так система сборки vs и переменные окружения-то не читает, по крайней мере по умолчанию.
>> No.8334  
>>8325

Ну так это и вызвано тем, что не предусматривает система стандартных путей для библиотек и стандартных названий переменных окружения. Что, в общем то, не удивительно для системы, в которой изначальный способ распространения программ - бинарники, а не сорцы.

С другой стороны, я подозреваю, что и в nix системах придется точно так же страдать, если понадобится установить несколько разных версий библиотеки и использовать разные версии в разных проектах. Точно так же придется положить собранные версии где-нибудь в home и руками тыкать билд-систему туда. Я не специалист по cmake, но беглая поиск не показывает, что в find_package можно указать версию - следовательно, надо указывать путь поиска к установленной библиотеке.
Возможно, вышеназванный пример не часто встречается в мелких проектах. Зато в так называемом "энетерпрайз" версии библиотек фиксируются и все пишется и тестируется относительно строго заданного списка. И я всеми руками за то, чтобы прямо указать нужную версию из нужной папки, вместо того, чтобы полагаться на какую-то версию, установленную в системе, которая завтра может обновиться вместе с пачкой всего остального софта в системе.

В своей практике использования visual studio, чтобы не повторять у себя на машине этот процесс настройки местоположения зависимостей много раз, я делал один раз property page с путями к библиотеками, сохранял в отдельный файл foo.props и затем подключал его ко всем необходимым конфигурациям всех нуждающихся проектов. Или даже по файлу на каждую отдельльную библиотеку и ее конфигурацию. Возможно, есть более удобный способ. Мне хватало этого.
Сборка из консоли/скриптов также возможна. devenv /build выручит отца русской демократии. Сам не использовал, но судя по логам студия вызывает то же самое.

Билд-система - штука важная в ide, конечно. Но не самая. Настройка билда пишется один раз. Потом по мере необходимости правится. В больших проектах этим, в идеале, занимается отдельный человек.
И если на настройку билда уходит время, сопостовимое на написание самого проекта - проблема не в ide. Просто выбранный инструмент используется не по назначению. И это не проблема молотка, что им очень сложно пилить.

Я же нахожу более важным в ide удобство работы с кодом, удобство отладки. И я пока что не видел ничего удобнее связки visual studio/visual assist. Более-менее интеллектуальные дополнения, быстрые преходы и поиск использования очень помогают. И, также, я не видел ничего удобнее для визуальной отладки. В студии легко настроить отображение именно того, что нужно и показывать все это вместе.
>> No.8343  
>>8325
Я для своего проекта, который зависит от BOOST, MPI и ещё некоторого количества всякой математической фигни делаю зависимости в студии (2010, 2012) через переменные окружения. В смысле, укажите пжалст пути, куда вы поставили MPI, куда для бууста сделали b2 install, ну итд.
Линукс-билд собирается cmake.

> И, также, я не видел ничего удобнее для визуальной отладки. В студии легко настроить отображение именно того, что нужно и показывать все это вместе.
*this
Особенно для С++ отладка в студии лучшая. Для С тоже. Правда надо уметь этой студией пользоваться, большинство фишек отладчика на поверхности не лежат. Настройка визуализации в студии конечно менее гибкая, чем питон в gcc, но ей довольно легко пользоваться. А в 2012 эту штуку даже задокументировали и сделали xml-based конфигурацию.
>> No.8344  
>>8334
>Что, в общем то, не удивительно для системы, в которой изначальный способ распространения программ - бинарники

Бинарных дистрибутивов линукса полно. Source-based - меньшинство.

>С другой стороны, я подозреваю, что и в nix системах придется точно так же страдать, если понадобится установить несколько разных версий библиотеки и использовать разные версии в разных проектах.

В gentoo с этим проблем вообще нет благодаря системе слотов. В других дистрибутивах несовместимые версии библиотек тоже можно использовать, но более костыльно.

> Настройка билда пишется один раз.
Переношу я свой проект на новый компьютер или распространяю по сети...

> Я же нахожу более важным в ide удобство работы с кодом, удобство отладки. И я пока что не видел ничего удобнее связки visual studio/visual assist. Более-менее интеллектуальные дополнения, быстрые преходы и поиск использования очень помогают. И, также, я не видел ничего удобнее для визуальной отладки. В студии легко настроить отображение именно того, что нужно и показывать все это вместе.

Правильно настроенный и обмазанный плагинами vim не менее удобен (дополнение делается clang'ом, получается не хуже VAX). Отладчиком я почти не пользуюсь (тем более для CUDA он работает через раз). В целом, переход на linux был самым счастливым моментом в моей программистской жизни.
>> No.8348  
>>8343
>Особенно для С++ отладка в студии лучшая. Для С тоже
Не соглашусь. В эклипсе к gdb довольно приятная морда, студя после нее кажется жутко неудобной и перегруженной.
>> No.8360  
>>8301
Я ЖУТКО извиняюсь, но когда успела выйти Винда версии 8? Последний раз когда я проверял, выходила только какая-то NT 6.2

_быдлокожу в мсвц, рекомендовать ничего не буду_
>> No.8361  
>>8360
October 26, 2012 согласно крези-лесбо-ресурсу под названием википедия.
>> No.8362  
>>8361
Но это же и есть NT 6.2? При чем тут восьмая версия? Если считать все дробные версии, то их больше восьми наберется, а маркетинговое название... Ну это название, не больше того.
>> No.8364  
>>8362
Извини, я сразу не понял, что тебя интересует не "windows 8", а восьмой по счету релиз. Крези-лесбо-непонимание~

Быть может тебе нужна nt 3.51? Она вышла в крези-лесбо-1995-м году
>> No.8395  
>>8364
Меня интересует виндовс восьмой версии, упомянутый в посте, на который я сослался, когда спрашивал. Не более того.
>> No.8396  
Файл: [artyfox &amp; hotFlash] Toradora! - 08 [DVDRip 84.jpg -(56 KB, 449x603, [artyfox &amp; hotFlash] Toradora! - 08 [DVDRip 84.jpg)
56
>>8395
>Меня интересует виндовс восьмой версии
Но ты же сам сказал, что это nt6.2 и что она тебя как раз не интересует. Я запутался.
>> No.8397  
>>8396
Но там не про нт6.2, там про мифическую восьмую версию. И её малые отличия от предыдущих.
>> No.8398  
>>8397
Нет, в википедии как раз про nt6.2 (ее кстати еще называют windows 8). Так что ничего мифического в ней нет, ты что-то путаешь.
>> No.8399  
Морда сдулась. Я надеялся тебя на больше хватит
>> No.8400  
>>8398
Для слепых - цитирую. Для тупых - обесняю.

>последняя версия винды уже 8, а она "немножко" отличается от привычных окошек
Явная импликация того что версия-то уже ОГОГО, а всё ничего не меняется. Хотя по факту между всеми мажорными версиями было достаточно много отличий, а последняя мажорная версия - 6.

Ня.
>> No.8401  
>>8400
Да знаю я. Я с тобой заигрывал, а ты взъелся. Фу.
>Ня.
A в итоге-то не ня
>> No.8402  
>>8400

Слушай, я дам тебе совет. Если ты не знаешь отличий версии "ядра" от версии "дистрибутива" то не пытайся умничать. Или у тебя дистрибутивы линукса все сплошняком версии 2.x или 3.х? Или может быть весь функционал какой ты используешь тебе дает исключительно "йадро"?

> а всё ничего не меняется

Меняется, только не там где нужно. Как пример: восьмерка дропнула поддержку некоторых d-linkовских железяк, а поддержка сети в ней лучше не стала. "штатными" средствами раздать через нее интернет в домашней локалке до сих пор подвиг.
Виндобыдло такое виндобыдло вобщем.
>> No.8415  
>>8402
Если тебе это важно, то скажу, что твой пост я прочитал.
>> No.8416  
>>8415
слив защитан
>> No.8417  
>>8402
> "штатными" средствами раздать через нее интернет
Ну и кто тут быдло. Может еще про недостатки блокнота с паинтом покукарекаешь?
>> No.8418  
Файл: Popcorn_02_Stephen_Colbert.gif -(1146 KB, 330x248, Popcorn_02_Stephen_Colbert.gif)
1146
>> No.8422  
>>8417
Блокнот вообще-то самая пиздатая программа в поставке (вероятно ее сам бил гейтс писал кровью христианских младенцев-девственниц). А вот паинт действительно говно. Там интерфейс не как в фотошопе и слоев нет.
>> No.8423  
>>8422
Пайнт в виндовс 7 стал ня и каваии. В нем появилась возможность обрезать по выделению!
>> No.8431  
>>8422
> Блокнот вообще-то самая пиздатая программа в поставке (вероятно ее сам бил гейтс писал кровью христианских младенцев-девственниц).
Ты им хоть пользовался? Он же тупо половину файлов не может нормально открыть. То не распознает переводы строк и весь текст в кашу, то не распознает юникод и каждая буква через пробел. Не может в кодировки, в результате любуешься мусором вместо текста. Паинт по сравнению с таким хламом - слепящее совершенство.
>> No.8433  
Файл: 1311747338112.jpg -(407 KB, 1920x1200, 1311747338112.jpg)
407
>> No.15488  
Файл: CPlusPlus.jpg -(36 KB, 433x455, CPlusPlus.jpg)
36
Привет. Тут такое дело. В общем, мне 22 года, я закончил бакалавриат по направлению информатика и вычислительная техника, и мой профиль - это соверменный С++ (С++11/14). Проблема в том, что в моём городе полторы вакансии на С++ разработчика, причём одна из компаний мне не особо нравится. Такая ситуация навевает мысли о фрилансе, и тут назревает главный вопрос: котируется ли на фриланс биржах что-то кроме веб-программирования? Могу ли я зарабатывать там, используя свои знания по С++?
>> No.15490  
Подписался на обновления.
>> No.15491  
https://freelansim.ru/tasks?q=c!plus!plus
>> No.15492  
>>15491
Хотелось бы что-то про личный опыт услышать.
>> No.15504  
>>15492
Увы, рассказать нечего. Работаю по специальности уже почти 10 лет.
>> No.15532  
Фрилансил лет десять назад, в т.ч. на крестах (в веб я не могу). Уже тогда было мало годноты, домашки всякие и т.д. На фрилансерских сайтах сидят а) физлица, которым надо делать домашки либо мелкую автоматизацию труда, б) оче маленькие бизнесы, чаще всего из одного человека. И тем, и другим обычно надо быстро (в разработке) и дешево, тяп-ляп и в продакшн, что с крестами не совместимо.

В исключительно редких случаях нужно что-то ускорить, и там может помочь переписывание кода на кресты, хотя в большинстве этих редких случаев, как обычно, алгоритмические оптимизации дадут гораздо больший прирост производительности. Ускорить код в миллиард раз можно только изменив алгоритм, и как правило после этого уже неважно, на крестах он исполняется или на жс.
>> No.15543  
>>15532
Ну, сейчас вроде немного получше.
https://www.upwork.com/o/jobs/browse/skill/c-/
>> No.17944  
Файл: DOeqVA4X4AIuLrj_jpg_large-b-0ee9.jpg -(82 KB, 700x466, DOeqVA4X4AIuLrj_jpg_large-b-0ee9.jpg)
82
А расскажите динозавру, изучавшему кресты в прошлом веке, про все эти новые конструкции из С++11, С++14, С++17 и прочее. Применяете ли вы их на практике и почему?
>> No.17945  
>>17944
Конечно, в C++11 вообще очень много необходимых вещей типа тредов добавили и даже самые слоупоки уже под этим стандартом пишут.
>> No.17946  
Файл: x538.jpg -(30 KB, 500x375, x538.jpg)
30
>>17944
В прошлом веке размер списка доставался за O(n), а теперь за O(1). До чего стандарт дошёл!
http://www.cplusplus.com/reference/list/list/size/
>> No.17947  
>>17944
Если счётчик в цикле не нужен, использую range-based for loop с auto в нём. Передаю лямбды в колбеки. Для безопасности, удобства и оптимизаций находчивые указатели пригождались. Функторы и rvalue-ссылки тоже были нужны, уже не помню как.
>> No.17952  
>>17947
> Функторы
Ой, это не из нового стандарта, просто экзотическая штука.
>> No.17953  
>>17952
Да не очень-то и экзотическая.
>> No.17958  
Файл: 14202160333530.png -(1228 KB, 1200x1800, 14202160333530.png)
1228
Она всё сделала и прилегла или хочет полежать ещё немножечко, несмотря на количество дел?
>> No.17968  
>>17945
> типа тредов добавили
А чем тебе позиксные треды не угодили?
>> No.17969  
>>17958
Это у неё такие pure virtual мечты.
>> No.17970  
>>17968
Ну, во-первых, > например. Далеко не только треды же добавляли: тот же СТЛ сильно переработали и расширили. А, во-вторых, где сказано, что не угодили? Просто круто, что добавили независимую от платформ поддержку мультитрединга.
>> No.17972  
>>17958
Захотелось вдруг познать visual basic.
>> No.17974  
>>17972
Когда ты её поцелуешь, она превратится в жабу.
>> No.17982  
>>17970
> Ну, во-первых, > например.
Объясни, пожалуйста. Компаратор?
>> No.17983  
>>17982
Нет, это цитата. Только вместо "например" должно быть "типа".
>> No.17985  
Однако выставление приоритета у потоков существует. Только не в стандарте.
>> No.18122  
Файл: 3.png -(5 KB, 90x50, 3.png)
5
http://www.drdobbs.com/cpp/the-c14-standard-what-you-need-to-know/240169034
>> No.18129  
https://hastebin.com/mukusodile.cpp
Поигрался с порядком байтов.
>> No.18139  
Файл: 1512926094814.jpg -(205 KB, 1685x1332, 1512926094814.jpg)
205
キタ━━━(゚∀゚)━━━!!
>> No.18149  
https://www.viva64.com/ru/b/0391/
>> No.18217  
http://www.iecc.com/linker/
Нашёл неплохую книжечку про линкеры.
>> No.18228  
>>18217
Зачем это вообще нужно знать?
>> No.18230  
>>18228
Для общего развития. Ну или чтоб знать, как либы работают, например.
>> No.18236  
Начинаю копать старьё:
https://hastebin.com/axosiwuciq.cpp
>> No.18237  
>>18236
Спасибо, не поняла.
>> No.18242  
>>18237
Просто функция, которая вызывает функцию, которая вызывает функцию.
>> No.18254  
https://hastebin.com/mekaqurojo.cpp
Тут какие-то игрушки с компайл-таймом.
>> No.18274  
>>18254
Хастбин перестал что-то отображать у меня. Пробовал другие ссылки и с другого браузера.
>> No.18300  
>>18139
Последнее - какое-то гонево в любой ОС с защитой памяти. Писать, конечно, можно попытаться куда угодно, но оно либо сразу свалится с access violation, либо умрет вместе с процессом рано или поздно.
>> No.18304  
>>18300
Там скорее всего про эмбед.
>> No.18305  
>>18304
За смарт-пойнтеры в эмбеде по рукам-то вам настучат сразу.
>> No.18309  
>>17968
> А чем тебе позиксные треды не угодили?
Непереносимо.
>> No.18316  
>>17944
вэриадик тимплитс - лучше, чем вэрарг
инишиалайзер_лист - лучше, чем пушить по-одному из С-массива
иф констэкспр - лучше, чем сфинае-лапша и ифдефы
дидакшн гайдлайнз стало больше
стало больше полезных перегрузок для STL
инлайн стэтик мэмбэрз
лэмбда-экспрешнз рулят, использую их много где

Лично мне не хватает модулей, консептся ар эджективс, рэнджес ТС и перегрузки оператора "точка".
>> No.18318  
>>18316

> тимплитс
>> No.18319  
>>18318
Да, перестарался.
>> No.18320  
>>18305
Нет, последний квадратик про эмбедд. Ну или про что-то, что до ОС грузится.
>>18316
> перегрузки оператора "точка".
Зачем? А остальное в близжайших стандартах должны ввести.
>> No.18325  
>>18320
Ну хотя бы для того, чтобы можно было биндить заново, и чтобы можно было иметь смарт-референсы.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4173.pdf
>> No.18330  
Почему std::async по умолчанию не или не всегда асинхронный? Я думаю, чего это у меня время выполнения как без async, а он лениво всё выполнял.
>> No.18331  
>>18330
http://en.cppreference.com/w/cpp/thread/async
>> No.18333  
Файл: 15125000256810.jpg -(383 KB, 1561x2048, 15125000256810.jpg)
383
>>18331
> If neither std::launch::async nor std::launch::deferred, nor any implementation-defined policy flag is set in policy, the behavior is undefined.
И почему тогда флаг необязателен?
>> No.18336  
>>18333
А ты нужную перегрузку выбрал из списка?
>> No.18339  
>>18336
Хм, да, но первый вариант такое же UB.
> 1) Behaves as if (2) is called with policy being std::launch::async | std::launch::deferred. In other words, f may be executed in another thread or it may be run synchronously when the resulting std::future is queried for a value.
То ли это если компилятор видит future, то откладывает до его востребования. Сипипец.
>> No.18341  
>>18333
Потому что могут, очевидно же. Или дело в каких-нибудь сумасшедших трюках для самых умных, но это вряд ли.
>> No.18343  
https://hastebin.com/otorurekow.cpp
Стало интересно и написал, что-то. ЧСХ, синхронный вариант быстрее из-за того, что в асинхнонном замочки юзались. Кстати говоря, почему не компилировалось, когда async вызывался как
std::async(std::launch::async, rea, ifs)
?
>> No.18347  
>>18339
>UB
>If both the std::launch::async and std::launch::deferred flags are set in policy, it is up to the implementation whether to perform asynchronous execution or lazy evaluation.
Результат выполнения вэлл-дифайнд-программы не зависит от того, выполнился асинк в треде или лениво.
>И почему тогда флаг необязателен?
Видимо, потому, что авторы решили, что главное свойство асинка - не прерывать вызывающий поток, и что если флаги не указаны, то можно хоть как. Для сред выполнения с одним ядром это лучше, а остальные пусть флаг указывают.
>>18343
А параметр лист у лямбды где? Что за привычка такая - говорить, что не компилится, а дальше "ебитесь и догадывайтесь сами"? Иногда кажется, что вы специально вообще весь вывод ошибок отключаете и компилите вслепую.
http://coliru.stacked-crooked.com/a/7cef3fb3db4a115a - вот, показывай.
>> No.18348  
>Для сред выполнения с одним ядром это лучше, а остальные пусть флаг указывают.
Точнее, пусть среда, знающая число ядер, сама выберет то, что лучше - ленивость для одноядерных ЦП и параллельность для многоядерных.
>> No.18350  
>>18343
Может, std::ref нужен для ifs.
>> No.18351  
>>18347
> А параметр лист у лямбды где?
На кой хер?
> Что за привычка такая - говорить, что не компилится.
Темплейт не дедуктится.
http://coliru.stacked-crooked.com/a/15d3b9006f4544d9 - показал.

>>18350
И правда. Спасибо, почему-то в голову самому не пришло.
>> No.18360  
>>18351
>На кой хер?
Теперь понял.

Объясните мне теперь, что это за ошибка такая?
>/usr/local/include/c++/7.2.0/future:1712:5: error: no type named 'type' in 'class std::result_of<std::__cxx11::basic_string<char> (*(std::basic_ifstream<char>))(std::basic_ifstream<char>&)>'

Это функция, от стринга, возвращающая указатель на функцию, принимающую референс и возвращающую стринг. Хули он её дедуснуть не может?
http://coliru.stacked-crooked.com/a/4e17247cd426fe88
Какое отношение ссылки в аргументах имеют к result_of?
>> No.18361  
>>18360
http://www.cplusplus.com/reference/fstream/ifstream/ifstream/
> (3) copy constructor (deleted)
fstream объекты не поддерживают копирование.
>> No.18362  
>>18361
Копирование - это как раз без &.
>> No.18365  
>>18362
Да, не посмотрел, где ошибка. Тогда так. http://coliru.stacked-crooked.com/a/b8887c7f9859e0c5 Но ты это и так знал и вопрос в том, почему так? На самом деле, понятия не имею, что это и что ты делаешь.
>> No.18366  
>If the deferred flag is set (i.e. (policy & std::launch::deferred) != 0), then async converts f and args... the same way as by std::thread constructor, but does not spawn a new thread of execution. Instead, lazy evaluation is performed: the first call to a non-timed wait function on the std::future that async returned to the caller will cause the copy of f to be invoked (as an rvalue) with the copies of args...
Так, теперь понятно, почему оно не должно работать - флаг рантаймный, а в одном из вариантов происходит копирование (или в обоих).
>>18351
Да. Осталось только понять, как тип возрващаемого указателя влияет на вычислимость возвращаемого типа. Обрати внимание - я не меняю тип аргумента функции, я меняю тип аргумента функции, указатель на который возвращает функция.
>>18362
Дык там функция принимает ifstream по значению, а возвращает указатель на функцию, которая принимает по ссылке.
>> No.18367  
>>18365
Не я делаю. Он берёт вывод из >>18351 и пытается понять, где ошибка. Не ясно пока, почему работает WAT3.
>> No.18368  
>>18365
Он не я. Спасибо тебе огромное, до меня допёрло. То есть, аргумент для result_of - это и тип Callable и список желамых параметров в одном.
http://coliru.stacked-crooked.com/a/093a22237891f112
Тогда ещё вопрос: почему как мне сделать то же самое с, например, функцией от инт, возвращающей инт? Мне нужно написать int(int)(int), но это оказывается функцией, возвращающей функцию.
>> No.18369  
Я так понимаю, что сделать это без имени типа или иного усложнения не получится.
>> No.18370  
>>18368
> Мне нужно написать int(int)(int)
Нет, нужно написать int(int). Но result_of не для этого.
>> No.18371  
>>18370
Так я уже пробовал до того, как допёр, и это не компилится по названой причине - должен быть коллэбл-тип и скобки со списком араетров.
>> No.18399  
http://www.acodersjourney.com/2017/08/top-20-cplusplus-multithreading-mistakes/
>> No.18434  
>>18399
Оценил.
>> No.18457  
Файл: a.png -(91 KB, 1350x634, a.png)
91
>>18399
Mistake # 21: Showing any weakness to std::async
>> No.18529  
>>18457
Is it about shared_future or what? Looks perfectly normal considering RAII and absence of thread isolation.
>> No.18530  
>>18529
Мне не нужен был возвращаемый результат, передаваемая функция была void, поэтому я вызывал async без future. А потом удивился, обнаружив последовательное выполнение.
>> No.18532  
>>18530
Вот не вижу ничего удивительного в этом, ведь завершение async-функции - это тоже результат. Если тебе нужен detached thread, то тебе нужен detached thread.
>> No.18635  
>>18457
В первом параграфе говорится о shared_future? Как могут несколько future относится к одному shared state?
>> No.18636  
https://hastebin.com/conuvaxiyi.cpp
Попросили сделать реализацию алгоритма Прима. Вроде даже не совсем говнокод.
>> No.18641  
>>18635
https://stackoverflow.com/questions/30810305/confusion-about-threads-launched-by-stdasync-with-stdlaunchasync-parameter
http://scottmeyers.blogspot.ru/2013/03/stdfutures-from-stdasync-arent-special.html

Да, там о shared.
>> No.18761  
Бампну ради великого правосудия.
>> No.18836  
https://solarianprogrammer.com/2017/12/27/cpp-17-constexpr-everything-as-much-as-the-compiler-can/
Что-то я не понимаю этого. Зачем именно everything? Это же вредит читаемости кода. Почему нельзя констэксприть только очень важные для производительности части кода?
>> No.18837  
>>18836
Как вредит? Вредить разве что компайл тайму может.
>> No.18843  
>>18837
Вредит таким образом, что нужно код переписывать в соответствии с требованиями constexpr.
>> No.18844  
>>18843
Н-е совсем. Скоро сделают, что можно будет действительно везде приписывать, как инлайн, например, а компилятор будет решать. Ну, а если тебе вправду нужно, чтоб функция на компайл тайме считалась, то перепишешь. Компилятор умный, так что это совсем не сложно.
Вообще, не очень понял твоё высказывание. Никто же тебя не заставляет переносить всё в компайл тайм, ну.
>> No.18853  
>>18844
>Никто же тебя не заставляет переносить всё в компайл тайм, ну.
Я уже в нескольких местах видел такое предложение. Ясен хер, меня не заставляют, но мотивы этих людей мне непонятны (они шутят?).
>> No.19004  
Поясните за скрипты линкера. Кто-то писал?
>> No.19017  
>>19004
Пояснился. Осознал, что ничего не знаю, стал плакать в подушку.
>> No.26517  
Файл: Снимок экрана 2022-08-15 в 15_19_37.png -(62 KB, 1964x234, Снимок экрана 2022-08-15 в 15_19_37.png)
62
Какой забавный спам приходит.
>> No.26518  
Файл: Снимок экрана 2022-08-15 в 16_12_11.png -(90 KB, 1822x122, Снимок экрана 2022-08-15 в 16_12_11.png)
90
>>26517
А неплохо.
>> No.26973  
Файл: Adeptus-Mechanicus-deviantart_com-AlexBoca.webp -(619 KB, 1710x900, Adeptus-Mechanicus-deviantart_com-AlexBoca.webp)
619
По мотивам треда для новичков.
>> No.26974  
Файл: Adeptus-Mechanicus-deviantart_com-AlexBoca(2).png -(2897 KB, 1710x900, Adeptus-Mechanicus-deviantart_com-AlexBoca(2).png)
2897
>>26973
Более смешной вариант.
>> No.26978  
Файл: Adeptus-Mechanicus-deviantart_com-AlexBoca.png -(2887 KB, 1710x900, Adeptus-Mechanicus-deviantart_com-AlexBoca.png)
2887
>>26974
Еще более смешной
>> No.26997  
Файл: c358e64dfe86b5b151378e98b4b95597.jpg -(126 KB, 850x1258, c358e64dfe86b5b151378e98b4b95597.jpg)
126
>>26976
Вчера, кстати, пришлось погрустить из-за того, что мапа действительно не умеет сортироваться "автоматически". Мне хотелось иметь контейнер для N объектов, каждый из которых содержит в себе свой поток, живущий отдельной жизнью и в произвольные моменты времени меняющий состояние объекта - причем я планировал периодически находить самый "старый" (давно не менявший состояние) из объектов и заменять другим.

Конечно, рефлекторным порывом было определить оператор сравнения для объектов по дате изменения и складывать их в std::set - но сразу стало ясно, что оно не будет так работать.

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

https://onlinegdb.com/vfSmqJ6kqO
>> No.26998  
Файл: 14366b0cfc582964cdec7c3fd90a564e.jpg -(270 KB, 915x1214, 14366b0cfc582964cdec7c3fd90a564e.jpg)
270
А еще в нагрузку дали девочку-студентку (не лоли, крупную и потрепанную). Три месяца назад ей дали амбициозное задание сделать свой кастомный видеоплеер для подглядывания за идущими в нейросеть данными. Девочка молодец и многое сделала, но небыстрыми темпами - и я типа должен помочь ей побыстрее закончить.

Теперь она впиливает новые кнопочки и фичи, а я лазаю за ней по коду, исправляя новые сегфолты и утечки памяти. Чувствую себя очень глупо.
>> No.27103  
Файл: 2023-05-17 19_15_25.jpg -(62 KB, 1280x669, 2023-05-17 19_15_25.jpg)
62
Когда ты сочиняешь алгоритм кластеризации прямоугольников на длинной ленте, но тебе лень подключать внешнюю библиотеку для визуализации.
>> No.27132  
>>27103
Когда у тебя нет этой библиотеки под рукой и тебе хорошо знакомой - именно так.
>> No.27141  
Какие-то вы мертвенькие.
>> No.27143  
>>27141
Летние каникулы~
>> No.27223  
Файл: 1470576270668.jpg -(130 KB, 1242x941, 1470576270668.jpg)
130
>>17934
Не подкажите ли, наследники Страуса, можно ли как-нибудь ускорить компиляцию заголовочных файлов с
inline
функциями?
А то мне, падавану, не удалось вынести реализацию таких в функций в .cpp файл. без костылей, как я понял, это невозможно.
>> No.27228  
>>27223
Пока мы ждем рыцарей-джейдаев, хотел спросить, подходит ли тебе вот такой вариант с extern?
https://stackoverflow.com/a/23432044
>> No.27229  
Здравствуйте.
Захотел написать обертку для редис, как часть Rails-подобного C++-фреймворка.
Что думаете по первому впечатлению?
https://github.com/movepointsolutions/activeredis/tree/main
>> No.27230  
>>27223
Нет смысла руками прописывать inline.
Компилятор сделает это лучше тебя.
Выноси большие функции, время выполнения которых много больше 4-5 тактов связки CALL/RET, в .cpp файл, а если хочешь обнять линк-тайм инлайнинг, читай документацию.
>> No.27231  
Файл: 2023-08-25_20-23.png -(70 KB, 900x514, 2023-08-25_20-23.png)
70
>>27228
Не знаю даже, попозже посмотрю, имеет ли это смысл. Сейчас, почитав Вашу ссылку, у меня появились сомнения в использовании встраиваемых функций.
>>27230
>Компилятор сделает это лучше тебя.
Ему же вроде надо подсказать. Нf пикриле доки MS.
>> No.27234  
Файл: 16439095459943.gif -(1290 KB, 700x393, 16439095459943.gif)
1290
>>27229
Да вроде норм.
Кода у Тебя мало, ещё неизвестно, как он себя поведёт при усложнении проекта. Ты лучше пока обдумай, как будет структура классов.
Старайся делать обёртку с нулевыми издержками и не забывать о KeepItSimple,Stupid и DontRepeatYourself.

А так, продолжай в том же духе и поглядывай на обёртки других библиотек/фреймворков.
>> No.27242  
Файл: 13df57ba04aea789b240fb7f82b89194.jpg -(13 KB, 250x367, 13df57ba04aea789b240fb7f82b89194.jpg)
13
>>27229
>Rails-подобного C++-фреймворка
Звучит так, что у тебя должен быть ActiveCache/ActiveObject/(другое название), который внутри вызывает, например, абстрактный ImdbAdapter. И уже на нижнем уровне должна быть реализация в виде RedisAdapter, наследующегося от ImdbAdapter.

Функция redisContext() уж точно должна быть приватной, иначе непонятно, что именно обёртка должна скрывать.

Интересно узнать, как твой Rails-подобный C++ фреймворк будет работать, в частности, какие практики из "convention over configuration" ты хочешь применить. В отличие от Ruby, язык не динамический и имеет меньше возможностей для метапрограммирования.
>> No.27287  
>>27223

Очевидные C++-модули.
>> No.27307  
Файл: F9JpzlNWEAAZhHz.jpg -(23 KB, 983x602, F9JpzlNWEAAZhHz.jpg)
23
>>17934

Всех приветствую. Делаю задание для шараги, нужно написать прогу которая способна сжимать и растягивать файл алгоритмом LZW. Сам алгоритм предполагает наличие начального словаря, который по ходу сжатия файла(нахождения в нём новых последовательностей байтов) расширен. То есть для того чтобы в дальнейшем растянуть файл обратно, нужно знать словарь. И вообще понять, подлежит файл растягиванию или же это просто белиберда из битов. Пока такие соображения: первые биты в сжатом файле сделать что-то типа сигнатурных, чтобы можно было сходу определить можно ли растянуть файл. И после сигнатурных битов будут биты сжатого файла, а потом будет магическое число типа как "разделитель" между файлом и словарём. Насколько хорошая идея использовать магическое число как разделитель? Или же лучше будет выделить под сжатый файл первые 4 бита как сигнатурные, где помимо метки сжатия файла будет ещё число под оффсет, как количество битов после которых заканчивается сжатый файл и будут пары ключ-значение из словаря? Или может быть лучше сделать по-другому как-то?
>> No.27313  
>>27307

>Делаю задание для шараги, нужно написать прогу которая способна сжимать и растягивать файл алгоритмом LZW.

Нахрена нужен ещё один LZ*-алгоритм, их и так как собак нерезанных.

#include <zstd.h>
и пошли нафиг. Требуемые возможности в нём есть. А неподдерживаемую самоделку, которую самим же и развивать придётся, в прод тащить - себе дороже. Мелкошарага - это не FAANG, чтобы свои алгоритмы компрессии общего назначения тянуть.
>> No.27314  
>>27313
Вполне возможно, речь идёт не про фирму, а про университет.
>> No.27315  
>>27307 >>27314
Ну раз курсовая работа....

>растягивать файл алгоритмом LZW.
>Сам алгоритм предполагает наличие начального словаря, который по ходу сжатия файла(нахождения в нём новых последовательностей байтов) расширен. То есть для того чтобы в дальнейшем растянуть файл обратно, нужно знать словарь. И вообще понять, подлежит файл растягиванию или же это просто белиберда из битов. Пока такие соображения: первые биты в сжатом файле сделать что-то типа сигнатурных, чтобы можно было сходу определить можно ли растянуть файл. И после сигнатурных битов будут биты сжатого файла, а потом будет магическое число типа как "разделитель" между файлом и словарём. Насколько хорошая идея использовать магическое число как разделитель? Или же лучше будет выделить под сжатый файл первые 4 бита как сигнатурные, где помимо метки сжатия файла будет ещё число под оффсет, как количество битов после которых заканчивается сжатый файл и будут пары ключ-значение из словаря? Или может быть лучше сделать по-другому как-то?

Строение формата: разделить стрим, словарь и контейнер. Все числа - little endian! Файл маппится в память целиком через либу mio, дальше работаешь с std::span и структурами. Стрим состоит из заголовка стрима и стрима. Без сигнатуры. Контейнер состоит из сигнатуры, глобального заголовка, содержащего длину области контейнера и смещения областей стрима и словаря в ней ОТНОСИТЕЛЬНО КОНЦА ЗАГОЛОВКА. После следуют области, сначала область словаря, потом область стрима, потом конец файла. Ты провершь это при загрузке файла. Размеры вычислишь как разницы этих смещений.

Начальный словарь может иметь смысл хранить в отдельном файле для переиспользования, поэтому область словаря - это может быть просто CRC32-хэш от файла словаря, который при операциях надо задать явно. Также начальный словарь можно
хранить внутри контейнера или использовать захардкоденный. Поэтому сначала 1 байт перечисление. 0 - хардкод, 1 - файл, 2 - внутри. Если 0 - то инициализируем хардкодом. Если 1 - берём имя файла, добавляем ".dic" - вот и наш словарь. Проверяем наличие файла. Маппим его. Проверяем формат словаря. Поскольку задача учебная, то для твоего удобства в его редактировании это просто массив, сериализованный в BSON/bencode. Поскольку тебя просили сделать только компрессию, то ты волен для словаря юзать другие либы. Если 2 - то сначала 8 бит длина, потом - блоб словаря.

Дальше идёт область стрима.

>Насколько хорошая идея использовать магическое число как разделитель?

Абсолютно идиотская. Тебе задачу делать надо, или извращаться? Ты либо делаешь всё максимально просто, либо огребаешь проблем немеренно. Что если у тебя в блобе словаря случайно встретится разделитель? Сигнатура используется исключительно для проверки принадлежности файла конкретному формату. Она располагается строго в начале и занимает строго либо 4 байта, либо 8 и не будет меняться никогда. Если планируется много версий формата - делается заголовок с версиями, формат которого не будет меняться вообще никогда. Вся информация, необходимая для парсинга структуры, должна быть известна ДО начала её парсинга.

При проектировании формата рекомендую использовать Kaitai Struct. Парсер получишь бесплатно.
>> No.27369  
Наткнулся при компиляции на ошибку вот в этой строчке
> typedef int Check[sizeof(A) == sizeof(int) + sizeof(bool) ? 1 : -1];
Долго думал, что это за ерунда такая, а потом как понял.
Структура А определена как
> struct A {bool b; int a;};
Оказалось, что это проверка на отключение выравнивания в структурах -fpack-struct=1.



[ d ] [ b / cu / dev ] [ r ] [ a / ts ] [ ci ] [ gnx / int ] [ misc ] [ dev / stat ]
[Burichan] [Futaba] [Gurochan] [Tomorrow] [Архив-Каталог] [Главная]