<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title><![CDATA[Авионика и Софт &mdash; Кодировка символов в версиях для ОС Windows и Linux]]></title>
		<link>http://www.forum.aviosoft.ru/viewtopic.php?id=216</link>
		<atom:link href="http://www.forum.aviosoft.ru/extern.php?action=feed&amp;tid=216&amp;type=rss" rel="self" type="application/rss+xml" />
		<description><![CDATA[Недавние сообщения в теме «Кодировка символов в версиях для ОС Windows и Linux».]]></description>
		<lastBuildDate>Mon, 11 Mar 2019 11:17:17 +0000</lastBuildDate>
		<generator>PunBB</generator>
		<item>
			<title><![CDATA[Re: Кодировка символов в версиях для ОС Windows и Linux]]></title>
			<link>http://www.forum.aviosoft.ru/viewtopic.php?pid=398#p398</link>
			<description><![CDATA[<p>Спасибо за подробное объяснение! <br />Применение префикса ‘u’ для строк по стандарту С++11 создаёт строки с символами в кодировке UTF-16, а это некорректно по отношению к функциям стандартной библиотеки языка С в ОС Linux, которые, по сути, ожидают символы в кодировке UTF-32. И у нас нет никаких идей, что с этим можно сделать в рамках языка С. И это касается не только функции vswprintf, но и других функций работы с Unicode строками, используемых нами в файле GraphLibImpl.c, например, wcscpy, wcscmp, wcsstr и др.. Т.е. проблемы могут появиться не только при форматировании строк в САПР, но и при применении других встроенных функций вычислителя САПР, предназначенных для работы со строками.<br />Всё, что приходит на ум, это запись моделью во входную структуру размера символов сохранённых в неё строк, и конвертация строк отображающей частью, если размер символов не совпадает. Но это всё, к сожалению, потеря производительности.</p>]]></description>
			<author><![CDATA[null@example.com (Admin)]]></author>
			<pubDate>Mon, 11 Mar 2019 11:17:17 +0000</pubDate>
			<guid>http://www.forum.aviosoft.ru/viewtopic.php?pid=398#p398</guid>
		</item>
		<item>
			<title><![CDATA[Re: Кодировка символов в версиях для ОС Windows и Linux]]></title>
			<link>http://www.forum.aviosoft.ru/viewtopic.php?pid=397#p397</link>
			<description><![CDATA[<p>Мы стараемся настроить кодогенерацию максимально похожей для двух ОС: Windows и Linux. Идеальным случаем (но не обязательным) считаем создание такого профиля кодогенерирования, что бы сгенерированый единожды код можно было собрать в любой обозначенной ОС в виде библиотеки (.so для Linux; .dll для Windows).<br />Поскольку отрисовка GL-объекта предполагается удаленно относительно модели расчета параметров входной структуры, то требуется состыковать их между собой. Модель должна собрать в входную структуру набор параметров для GL-объекта. Отображение должно получить входную структуру и перерисовать GL-объект. <br />Во время выполнения каждая из сторон не знает на базе какой ОС работает другая сторона. Например, модель может работать на базе ОС Linux, а отображение на ОС Windows. Связь между отображением и логикой может быть по сети. <br />Разница в размерах одного символа приводит к невозможности корректной передачи структуры, так как при этом сдвигаются поля входной структуры. <br />Нам удалось сократить различия в профилях кодогенерации до следующих вводных:<br />1) Изменили заголовок GraphLib.h (для обоих профилей):<br /></p><div class="codebox"><pre><code>#include &lt;wchar.h&gt;
typedef wchar_t char_un;   /* для Unicode строк */</code></pre></div><p>=&gt;<br /></p><div class="codebox"><pre><code>typedef unsigned short int char_un;   /* для Unicode строк. Измененный тип wchar_t на unsigned int */</code></pre></div><p>2)Заменили «префикс строк» для профиля Linux c «L» на «u». Профиль Windows использует префикс «L».</p><p>Это позволило генерировать код схожим образом для Linux и Windows. Позволило устранить разницу в размерах символов (в обоих ОC по 2 байта на символ).<br />Удается правильно отображать статичный текст (заданный заранее). Удается задавать и корректно отображать динамичный текст (являющийся, например, параметром входной структуры GL-объекта).<br />Возникла всего одна проблема, которую пока не получилось решить. Она связана с текстом, который проходит процедуру форматирования где-то в проекте. Например, когда в самом проекте используется код такого вида:<br /></p><div class="codebox"><pre><code>format(&quot;%02d:%02d:%02d&quot;, 1, 12, 3)</code></pre></div>]]></description>
			<author><![CDATA[null@example.com (be10ved)]]></author>
			<pubDate>Mon, 11 Mar 2019 07:55:10 +0000</pubDate>
			<guid>http://www.forum.aviosoft.ru/viewtopic.php?pid=397#p397</guid>
		</item>
		<item>
			<title><![CDATA[Re: Кодировка символов в версиях для ОС Windows и Linux]]></title>
			<link>http://www.forum.aviosoft.ru/viewtopic.php?pid=396#p396</link>
			<description><![CDATA[<p>Здравствуйте!<br />Нам кажется, что решить эту проблему со стороны САПР вряд ли получится. Здесь, вроде бы, всё правильно. Если в одной ОС функция <em>vswprintf</em> в качестве строки принимает массив символов по 2 байта, а в другой по 4, то тут ничего не поделаешь, и необходимо передавать массив символов такого размера, который требуется для <em>vswprintf</em> в данной конкретной ОС. Т.е. это должны быть два отдельно сгенерированных кодогенератором и скомпилированных программных кода.<br />Давайте попробуем подойти к проблеме с другой стороны. Опишите, пожалуйста, более подробно, что и как вы делаете, а также, что у вас не получается при создании платформонезависимого решения.</p>]]></description>
			<author><![CDATA[null@example.com (Admin)]]></author>
			<pubDate>Thu, 07 Mar 2019 12:36:34 +0000</pubDate>
			<guid>http://www.forum.aviosoft.ru/viewtopic.php?pid=396#p396</guid>
		</item>
		<item>
			<title><![CDATA[Кодировка символов в версиях для ОС Windows и Linux]]></title>
			<link>http://www.forum.aviosoft.ru/viewtopic.php?pid=395#p395</link>
			<description><![CDATA[<p>Здравствуйте.<br />Заметил особенность в размерах символов между версиями для ОС Windows и Linux.<br />При кодогенерации использование типа wchar_t приводит к размеру 2 байта в Windows. С другой стороны, ОС Linux считает размер wchar_t как 4 байта.</p><p>Это приводит к проблеме, если создается платформонезависимое решение, которое должно общаться с сгенерированными графическими объектами.</p><p>Пробовал решить проблему с помощью изменения заголовка GraphLib.h. А именно изменением строк:<br /></p><div class="codebox"><pre><code>#include &lt;wchar.h&gt;
typedef wchar_t char_un;   /* для Unicode строк */</code></pre></div><p>=&gt;<br /></p><div class="codebox"><pre><code>#include &lt;uchar.h&gt;
typedef char16_t char_un;   /* для Unicode строк. Измененный тип wchar_t на char16_t */</code></pre></div><p>или<br /></p><div class="codebox"><pre><code>typedef unsigned short int char_un;   /* для Unicode строк. Измененный тип wchar_t на unsigned int */</code></pre></div><p>При замене префикса с &quot;L&quot; на &quot;u&quot; по-началу все отображалось хорошо. Но потом возникла новая проблема. В одном из проектов у графического объекта используется функция форматирования текста:<br /></p><div class="codebox"><pre><code>format(&quot;%02d:%02d:%02d&quot;, 1, 12, 3)</code></pre></div><p>При кодогенерации это приводит к вызову C-функции vswprintf, которая подразумевает использование только типа wchar_t:<br /></p><div class="codebox"><pre><code>int vswprintf (wchar_t * ws, size_t len, const wchar_t * format, va_list arg );</code></pre></div><p>Графический симптом проблемы выглядит как отображение строки %02d:%02d:%02d на экране.</p><p>Подскажите, пожалуйста, как можно сделать размер входной структуры одинаковым в обоих ОС и что бы при этом на экране корректно отображался форматированный текст?</p><p>Заранее спасибо за ответ.</p>]]></description>
			<author><![CDATA[null@example.com (be10ved)]]></author>
			<pubDate>Wed, 06 Mar 2019 12:41:25 +0000</pubDate>
			<guid>http://www.forum.aviosoft.ru/viewtopic.php?pid=395#p395</guid>
		</item>
	</channel>
</rss>
