Quark, Я не в курсе архитектуры вашей библиотеки. Из приведенных исходников трудно сделать каких-то выводов.
Когда вы создаете библиотеку, то у вас есть некоторые экспортируемые типы, данные и функции (методы), которые должны быть видны из вне (пользователям библиотеки). А так же есть другие типы, данные и функции, которые являются внутренними для библиотеки и их не надо показывать на ружу.
В связи с этим у вас должен быть заголовочный файл (или несколько файлов) для внешних пользователей (для программ, которые будут использовать библиотеку) и другие заголовочные файлы для внутреннего использования (они нужны только для сборки самой библиотеки).
Вы сами, как разработчик библиотеки, определяете, что надо экспортировать, а что не надо.
Во внешней программе, использующей библиотеку нужно подключать только файлы заголовков для экспорта, внутренние заголовки вообще не нужны внешней программе и они должны/могут быть не доступны во время сборки внешней программы.
Если библиотека не большая, то в принципе, может не быть внутренних типов и данных, тогда нет смысла во внутренних заголовочных файлах.
Еще несколько замечаний:
Использовать etxern C не логично для классов и структур С++, т.к. в Си нет классов и структуры там отличаются от структур в С++. Если вы хотите, что бы ваша библиотека могла использоваться в программах на Си, то нужно поступать несколько по другому. А плюсовые программы смогут использовать вашу библиотеку и без extern C.
Не зачем в классе/структуре для каждого метода писать модификатор доступа (public), это же не Java.
Quark, Кто вам мешает оставить в заголовке только объявления.
А все определения (или только те, что считаете нужным) оставить в cpp? Вообще стандартная практика так-то.
PS: В прошлом посте ошибся с определениями, конечно. Исправился.
lukepker, Я в шоке :-)
Можете начать отсюда: https://softclipper.net/soft-skachat/clipper-5-2e-...
Помнится в середине 90х как раз закончил работу на клиппере на этой версии. С тех пор не приходилось его использовать. Но впечатления остались самые положительные.
Вы попали на самый неудачный вариант для создания графического приложения - с использованием чистого WinAPI. Как уже было сказано - это мучительно и неудобно, а главное надо хорошо понимать что вы делаете, т.к. это нижний уровень GUI, а у вас с этим проблемы.
На самом деле, вам стоит подумать - а нужно ли вам в принципе приложение с граф.интерфейсом, т.к. задача у вас примитивная, если не надо рисовать графики, то все остальное прекрасно делается в консольном приложении. А кроме того это гораздо проще.
Если же сильно хочется GUI, рекомендую использовать Qt. И может быть даже не MSVS, а QtCreator.
Ruslan, да и провайдер далеко не факт что в принципе сможет это сделать, т.к. возможно маршрут изменен где-то на промежуточном этапе, который не зависит от твоего провайдера.
Может на вашем компе появился какой-нить процесс который: занимает канал связи, занимает процессорное время, отжирает память.
Может нагрузка на облаке выросла или DDOSят его. Может в прошлый раз облако было ближе к вам, а сейчас переехало на край света.
Причин увеличения задержки и помимо провайдера может быть очень много.
Читайте внимательно мой первый пост.
Бесполезно выполнять эти команды на ВПН сервере - он и так имеет доступ к гугловским ДНСам.
Причину не работы, я описал в этом же посте. На вопросы вы не ответили.
Сергей, Начните с того, что покажите конфиг ВПН сервера. Используете ли в нем опцию: push "redirect-gateway def1 bypass-dhcp"
Именно она прописывает на клиенте ВПН сервер как шлюз по умолчанию.
Я первый способ пробовал
Вы где выполняли эти команды?
как фаервол может работать в качестве маршрутизатора
Правилами фаервола можно перенаправлять пакеты на другой интерфейс и т.п., а это прямое управление маршрутизацией. В т.ч. можно отправить пакеты на NAT, например.
Сергей, Как ВПН сервер сам попадает в интернет? Что является шлюзом в интернет для него?
Дело в том, что шлюз вашего ВПН сервера ничего не знает о ВПН сети. Поэтому он не знает куда слать полученные ответы и он их отбрасывает (или пересылает на свой шлюз по умолчанию).
Есть 2 варианта решения проблемы:
1. простой, но не всегда применимый: настроить на шлюзе статический маршрут до ВПН сети через ваш ВПН сервер.
2. чуть более сложный: поднять на ВПН сервере NAT на интерфейсе в сторону шлюза в интернет, отправлять на NAT все пакеты от ВПН клиентов в интернет с помощью правил фаервола. В этом случае пакеты от ВПН клиентов в интернет будут попадать на шлюз с адресом ВПН сервера, а не ВПН клиентов.
Не занимаюсь геймдевом.
Язык программирования - это только инструмент. Все ООП ЯПы плюс-минус похожи. Изучите один, следующий пойдет как по маслу. Самый сложный ООП ЯП это, наверное, С++.
Купите толстую книжку учебник по выбранному ЯПу, читайте и делайте примеры из нее. По С++ - Лафоре подойдет.
Дальше нужна еще книга по алгоритмам и структурам данных. Именно тут зарыта суть программирования, а вовсе не в ЯПе. Книжка Кормена, говорят, норм.
Сложные темы из программирования, которые используются вообще во всех сферах программирования - сетевое программирование (передача данных) и параллельное программирование. На это стоит заострить внимание. В геймдеве это все то же активно используется. Но в обычных учебниках про это пишут совсем чуть чуть. Нужно что-то более специализированное.
Из математики в геймдеве нужна линейная алгебра и тригонгометрия, на сколько я знаю.
В самом программировании мат.анализ нафиг не нужен. Он нужен в каких-то предметных областях, где он используется. Возможно, немного дискретной математики.
Ну а дальше берете понравившийся движок и начинаете его изучать и делать свой проект. Это можно начинать уже после освоения первого учебника по выбранному ЯПу, параллельно со всем остальным. За одно, свой проект, начнет добавлять вам вопросов для дальнейшего изучения.
Подтверждаю. Надо просто выбрать toolset с суффиксом xp в свойтсвах проекта. Он идет вместе со стандартным. Версия toolset для xp такая же, как и дефолтного. Другое дело, что сам MSVS может не встать на XP.
Но тут можно поставить MS Build Tools, а в качестве IDE использовать QtCreator.
В параметрах компилятору, надо будет вручную указывать нужный toolset. Как это делать написано тут: https://stackoverflow.com/questions/46325589/compi... https://stackoverflow.com/questions/52152135/how-t... https://social.msdn.microsoft.com/Forums/azure/en-...
Если у вас будет (наверняка) другая версия toolsetа, то просто проведите эксперимент - в MSVC создать простейший проект собрать его со стандартным toolsetом и с xp вариантом и сравнить параметры командной строки, которые выдаются для запуска cl и link.
Дмитрий Королев, Ты в курсе, что такое static переменные? Что будет, когда она определена так как у тебя в заголовочном файле? Уверен, что тебе именно такое поведение требуется?
На мой взгляд, если есть потребность в static переменной, то такой переменной самое место в *.c файле.
Можешь оставить в заголовке определение структуры, а определение переменной перенести в *.c.
Допускаю, что возможен какой-то вариант использования статической переменной, определенной в заголовке, но это что-то довольно экзотическое.
Дмитрий Королев, Ну и делайте документацию в заголовке. Если планирует распространять в виде библиотеки, то вместе с бинарником библиотеки необходимо передавать и заголовок, так что документации там самое место.
Не понял, что такое "статическая структура". Все определения переменных должны быть в *.c файле. Если какие-то переменные должны быть доступны не только библиотеке, то в заголовочнике объявите их как extern.
Когда вы создаете библиотеку, то у вас есть некоторые экспортируемые типы, данные и функции (методы), которые должны быть видны из вне (пользователям библиотеки). А так же есть другие типы, данные и функции, которые являются внутренними для библиотеки и их не надо показывать на ружу.
В связи с этим у вас должен быть заголовочный файл (или несколько файлов) для внешних пользователей (для программ, которые будут использовать библиотеку) и другие заголовочные файлы для внутреннего использования (они нужны только для сборки самой библиотеки).
Вы сами, как разработчик библиотеки, определяете, что надо экспортировать, а что не надо.
Во внешней программе, использующей библиотеку нужно подключать только файлы заголовков для экспорта, внутренние заголовки вообще не нужны внешней программе и они должны/могут быть не доступны во время сборки внешней программы.
Если библиотека не большая, то в принципе, может не быть внутренних типов и данных, тогда нет смысла во внутренних заголовочных файлах.
Еще несколько замечаний:
Использовать etxern C не логично для классов и структур С++, т.к. в Си нет классов и структуры там отличаются от структур в С++. Если вы хотите, что бы ваша библиотека могла использоваться в программах на Си, то нужно поступать несколько по другому. А плюсовые программы смогут использовать вашу библиотеку и без extern C.
Не зачем в классе/структуре для каждого метода писать модификатор доступа (public), это же не Java.