LiptonOlolo , ты всегда в праве оформить свой проект в открытом исходном коде на github. В этом случае там же мы можем продолжить обсуждение в уже более детальном и более развернутом порядке, в формате issue + PR.
aminought , да, это не просто утечка. Это ошибочная инициализация ресурса во время завершения программы.
"__cxa_finalize" говорит именно об этом. Еще видно что он запнулся на работе с std::string.
Но это не та утечка, которую видел я. Отчет куцый, путей к файлам очень нехватает.
aminought , в gtest есть утечка из за неправильной инициализации ресурсов во время завершения программы.
Билли Донехью в ответ на отчет об ошибке сказал что у меня "рожа треснет" и править он ничего не будет.
LiptonOlolo , а ведь именно на этот вопрос отвечают приведенные библиотеки. Но, ок, давай я чуть погодя пороюсь в исходниках Q3 и выложу эти аспекты сюда.
В общем смысле дело обстоит так.
Сокет для общения один. Сетевой стек представляет собой луковицу из декораторов (арх. примитив "Декоратор"), в сердцевине которых (в самом конце) и лежит сокет. Это справедливо как для отправки, так и для приема. Вспомни модель OSI и тебе все станет понятнее.
Стек может быть представлен такими сущностями как: интерфейс сокета, циклический буфер, пточный кодек сжатия трафика, поточный шифратор трафика, сериализатор/десериализатор объектной модели пакетов, диспетчер объектной модели пакетов, фабрика объектной модели пакетов. Может есть что-то еще и я просто забыл об этом.
Естественно создавать это все на каждый пакет не просто бессмысленно, но и тупо тяжело и долго по времени. Глядя на тег "C#" я начинаю понимать о чем ты спрашиваешь. Ответ - нет. Как только создан сокет, он должен быть окружен сетевым стеком до самого верхнего уровня, на верхушке которого стоит диспетчер с делегатами для обработки принятых пакетов и фабрика для производства пакетов на отправку. Считай что это все лучше сделать в синглтоне.
АртемЪ , исключительно субъективно - неудобная штука. :)
ADD, в частности, полезен не только форматированием пространства, но и копированием разделов, способностью расширять имеющиеся разделы, переносить их по пространству винчестера. И он это все делает в режиме сценария.
Т.е. есть как возможность просто задизайнить себе вид разделов перед фактическим разделением, так и возможность выгрузить сценарий и поставить нарезку разделов на поток в автоматическом режиме.
Последним у меня на работе админы промышляют, когда команде из 12 человек вдруг становится необходимо сменить винчестеры.
Pavel K , тебе явно надо идти в политики! У тебя очень хорошо получается дозировать информацию. :)
Вот, может быть лучше дополнительно в вопросе описать еще и ошибку?
Множественное наследование - самая очевидная причина смещения указателя.
К тому же, нередко размер объекта может отличаться от суммарного размера полей класса. Это может быть как по причине стандартного выравнивания полей класса, так и по причине включения служебной информации о типе в список полей.
А это уже может приводить к смещению указателя при приведении к родительским типам даже в случае прямого наследования.
Плюсом Qt. Я не любитель Qt, поэтому не загадываю. Но... Qt. :)
Иными словами, тревогу по тому поводу можно и не поднимать. До поры.
Все работает по правилам вывода шаблонных типов и их интерфейса.
Nexeon , еще для решения этой проблемы используют идиомы строителя (Builder) или фабричной функции (Factory function), именуя последнюю копирующей функцией. Так же я с успехом применял визитера (Visitor) на основе шаблонного типа.
Дизайн этих подходов для решения задачи копирования будет сильно зависеть от уже имеющейся коллекции типов и их устройства.
Pavel K , Антон задал самый правильный вопрос. Без технического обоснования необходимости именно такой записи любой ответ будет тянуть только на попытку ответа, но не на решение.
Saveli Tomak , в твоем случае хорошо будет смотреться хорошая история контрибутора в open source.
Проекты ради портфолио не нужны. Нужны проекты, которыми пользуются люди или которые используешь ты сам на постоянной основе.
Посмотри интересные тебе open source проекты на github, форкни их, разбирайся, пробуй общаться по ошибкам и доработкам с людьми.
Найти партнеров с конструктивным мышлением и высокими навыками для open source проектов очень тяжело. Поэтому каждый толковый контрибутор на вес золота. Работодатели это хорошо понимают.
И это еще только картинки. Простые картинки, Карл! Впереди еще непаханное поле самых прекрасных технологий доставки вредоносов самыми мирными путями.
Дальше продолжать? :)
Александр Казакевич , не, ты точно перетрудился уже. Ну пятый час ночи, спать бы лучше лег пораньше. :)
Смотри, у тебя метод getUser() возвращает объект по значению. А копирование/перемещение у класса User реализовано? Мне кажется, твой User тоже должен передаваться по указателю, как и все остальные сущности. Не?
В целом, когда у тебя составной проект, это не слишком хорошо - оперировать значениями переменных.
User из памяти динамической библиотеки по значению передается в память приложения. Память-то одна и та же - память процесса. Но вот передача по значению... Честно, я не рискну предполагать что там творится. Ни разу сам так не делал и не сталкивался с таким в работе. Но идея мне радикально не нравится.
Лучше все пограничные интерфейсы между библиотекой и приложением исполнять на указателях и через выделение на куче. Или оперировать указателями из статической памяти. Главное - это указатели и абстрактные классы / интерфейсы, никаких значений.
В качестве дополнения подкину одну старенькую, но все еще интересную заметку об использовании STL в динамических библиотеках. rsdn.org?article/cpp/stlproblem.xml
Александр Казакевич , подозреваю, ты малость рановато беспокоишься. Переработал уже, похоже. :)
Судя по второму скрину, ты еще не зашел в область метода getUser(). В этом случае осмотр переменных тебе все что угодно может писать.
Считай так: когда стрелка отладчика смотрит на фигурную скобку, значениям переменных можно временно не верить.
Roman Zhak , очень странный вопрос. Все что приложение должно - это стабильно работать и выполнять все заявленные функции.
Падение у пользователя - признак непрофессионализма разработчиков. Иные мнения - признак непрофесионализма.
Дискуссии по этому поводу быть не может.
Интересно, в каком это городе творятся такие выкрутасы? :)
Я бы на твоем месте задался такими вопросами: Почему мне позвонили? Почему именно мне? Откуда они знают что я использую что-либо из обозначенных продуктов? Как подтвердить подлинность источника звонка?
Прямо в разговоре я бы поинтересовался, есть ли у той стороны ордер на обыск и судебное распоряжение.
Евгений Обыкновенный , да, все так.
Только подобная запись не всегда считается "культурным кодом".
Это уже не стандарт, а культура и гигиена кода. Запись "if( x )" считается культурной только если "x" имеет тип "bool" или является объектом, класс которого имеет перегрузку оператора преобразования "explicit bool".
В иных случаях сокращать не рекомендуется ради сохранения читаемости кода и понятности производимых действий. Т.е. для сохранения культуры и чистоты самого кода.
Junoir C++ developer должен очень хорошо знать язык.
Во-первых - свой родной язык. Девлопер со спичем на форижен сленге мирится со слоу респектом у тиммейтов на ворке. Способность чисто декламировать на родном языке, словами без эмоций пояснять свою точку зрения, приводить (обязательно и только)веские аргументы и (в особенности) понимать чужую речь на родном языке имеет очень большое значение для процесса разработки. А для джуниора - еще более.
Во-вторых - свой язык программирования. Плюсы знать надо на таком уровне, чтобы не задавать простых вопросов. STL надо знать как букварь, это важный момент. Шаблоны и метапрограммирование - хотябы на общем начальном уровне (синтаксис, возможности, правила, type_traits в STL).
3 способа использования слова static знаешь? Почему inline нужен? Что такое константный метод? Почему в деструкторе нельзя вызывать виртуальные методы? А как виртуальный метод все же вызвать, если ну очень хочется? Каким условиям для хеш-функции желательно удовлетворять чтобы эффективно использовать ее в контейнере std::unordered_map? Как правильно мириться с исключениями конструктора? Чем std::deque отличается от std::vector, в каких случаях что эффективнее? Перечислять вопросы можно хоть до второго пришествия.
В третьих - английский язык. Нужно уметь читать документации и доклады, стенографии выступлений и, если понадобится, общаться с сообществом на гитхабе, гиттере, слеке. С ресурсом en.cppreference.com/w нужно не просто подружиться, надо знать что именно там есть все ответы на твои вопросы по языку.
Штука такая, джуниор без знаний языка мало кому нужен, таких на грош с десяток взять можно. Когда с самого старта карьеры ты уже будешь уверенно владеть языком программирования, к тебе и отношение другое будет. И рост у тебя будет быстрее, и знания тебе с самого начала будут по другому предоставлять.
А основная мысль у меня такая: как джуниора, тебя не азам обращения с инструментами должны учить, а сразу передавать тебе наработанную сноровку, алгоритмы, рассказывать про грабли и минные поля.
А пока... С наступающим! :)