Макар Герасимов , элементом игрового поля (двухмерного массива) может быть и объект (представлять элемент массивом - лишнее), в котором может храниться некоторая статистика. Минимально необходимыми являются только два поля - символ и булево значение занятости поля (это значение можно выразить и через нулевое значение символа).
Касательно отрисовки поля. Странно что ты задаешься этим вопросом. Визуально поле представлено регулярной сеткой, стало быть индекса ячейки двухмерного массива уже достаточно для правильной отрисовки на канве. Есть ширина клетки, есть (row/col)_index ячейки игрового поля, из этих данных никакого труда не составит выяснить квадрат ячейки на канве. Во время рисования этой ячейки можно спросить активного пользователя, не выделяет ли он именно эту ячейку и залить задник ячейки цветом выделения если надо.
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".
В иных случаях сокращать не рекомендуется ради сохранения читаемости кода и понятности производимых действий. Т.е. для сохранения культуры и чистоты самого кода.
Касательно отрисовки поля. Странно что ты задаешься этим вопросом. Визуально поле представлено регулярной сеткой, стало быть индекса ячейки двухмерного массива уже достаточно для правильной отрисовки на канве. Есть ширина клетки, есть (row/col)_index ячейки игрового поля, из этих данных никакого труда не составит выяснить квадрат ячейки на канве. Во время рисования этой ячейки можно спросить активного пользователя, не выделяет ли он именно эту ячейку и залить задник ячейки цветом выделения если надо.