QNX.ORG.RU

Разработка => Перенос приложений в QNX => Тема начата: kim от Октября 17, 2002, 06:57:00 pm



Название: CppUnit порт для QNX6
Отправлено: kim от Октября 17, 2002, 06:57:00 pm
Может кто использует subj? Поделитесь опытом переноса в QNX.
У меня все собирается ОК, но вот сами тесты при запуске . memory fault


Название: CppUnit порт для QNX6
Отправлено: lestat от Октября 17, 2002, 07:19:00 pm

Может кто использует subj? Поделитесь опытом переноса в QNX.
У меня все собирается ОК, но вот сами тесты при запуске . memory fault

Там библиотекой сделано или линкуется прямо с программой ? Если первое, то видать ты неправильно собрал библиотеку, смотри, на форуме, тут уже раза 3 эта тема поднималась - про правильность сборки библиотеки.


Название: CppUnit порт для QNX6
Отправлено: kim от Октября 17, 2002, 11:02:00 pm
Все верно - неправильно собрал библиотеку (и я напоролся на эти грабли), спасибо, lestat.


Название: Re: CppUnit порт для QNX6
Отправлено: da-nie от Августа 02, 2018, 08:24:16 am
А нет ли у кого готовой сборки для QNX 6.3? Я попробовал собрать текущую версию, но она жаждет компилятор с Си++ 11.


Название: Re: CppUnit порт для QNX6
Отправлено: da-nie от Августа 02, 2018, 08:43:56 am
Хотя, пока вопрос снимается - 1.13 собралась вроде бы. Осталось понять, как с ней работать. :)


Название: Re: CppUnit порт для QNX6
Отправлено: da-nie от Августа 02, 2018, 11:48:08 am
А не, не получилось. Не линкуется. У меня тест в файле CUnitTest. После компиляции всех файлов возникает вот такая вот проблема, как на картинке. Вот тут (http://qnx.org.ru/forum/index.php?topic=5879.15) есть что-то про глюки компилятора:
Цитировать
2.95.3 компилятор собирает всё, но когда доходит до тестов валится при линковке с кучей не найденных имён классов в libstdc++.so.5, от 2.95.3 другого ожидать не приходится.
3.3.5 компилятор всё собрал: и make и make check.
У меня в 6.3 SP 3, как я понимаю, 2.95.3.
Интересно, это вот оно обсуждалось в той теме?

Upd. Собрал CppUnit с помощью 3.3.5. И проект тоже им же. Всё равно проблемы с линковкой. Странно, вроде и libcppunit.so указал, а всё равно что-то не то.
Кстати, ни у кого нет готовой сборки gcc 3.3.5 и выше (что, конечно, лучше)? Хоть в исходниках (но только что б они в QNX 6.3 собирались :) ). В 6.3 SP 3 есть gcc3.3.5, а без SP только 3.3.1. А я загружаю 6.3 SP 3 и выбираю раздел с 6.3 без SP. Потому как в SP3 работать невозможно - IDE тормозит на порядок больше и даже отключение анализатора не помогает. Кстати, может, кто ещё знает, как в этом самом IDE файлы проекта по папкам раскидать? А то я держу все файлы h и cc в одном каталоге. У неё странная логика сканировать каталог и компилировать то, что она насканировала. И в каталогах насканированное она не компилирует ни в какую. А правильно было бы чтобы файлы вручную добавлялись в проект, как в Visual Studio, Code Block и тому подобных IDE. Из-за этого приходится все файлы держать, как в помойке в одном каталоге.

Upd2. Скачал gcc 4.2.1 и binutils-2.17 с community.qnx.com . Распаковал в Qnx 6.3 SP3 (вроде как ставили в 6.5, как я понял, но у меня её нет). Выполнил qcc -V. В IDE появился новый компилятор. Указал в проекте компилятор 4.2.1. Дальше неприятное: "hello word" собрался, но только если на stdio и printf. Стоит подключить хотя бы просто iostream и всё - у компилятора проблемы со сборкой библиотек. Про stl уж и не говорю.


Название: Re: CppUnit порт для QNX6
Отправлено: PoP от Августа 03, 2018, 11:39:43 am
GCC поновее можно посмотреть тут Foundry27 (http://community.qnx.com/sf/search/do/results/guid7bad8b3c3eea8be3ea0e2970/Frs?_pagenum=1).
Исходники можно раскидать по разным папкам (как внутри проекта, так и снаружи) и  добавлять выборочно (но только папку целиком): Project->Properties->QNX C/C++ Project->Compiler->Category->Extra sources paths (Extra include paths).


Название: Re: CppUnit порт для QNX6
Отправлено: da-nie от Августа 03, 2018, 11:42:52 am
Спасибо, я просто только что обновил сообщение с допиской, что я скачал 4.2.1, но он не работает, как надо в QNX 6.3.

Цитировать
Исходники можно раскидать по разным папкам (как внутри проекта, так и снаружи) и  добавлять выборочно (но только папку целиком): Project->Properties->QNX C/C++ Project->Compiler->Category->Extra sources paths (Extra include paths).

Хм. Я так делал для каталогов CPPUnit, но для своих каталогов не догадался. ::) Попробую. Спасибо!
Правда, а там случайно не абсолютный путь прописывается? Нужен-то относительный. Хотя, если получится задать путь через ./ и оно это съест, то проблема решится. :)


Название: Re: CppUnit порт для QNX6
Отправлено: PoP от Августа 03, 2018, 12:11:23 pm
Там есть всякие $(PROJECT_ROOT) и т.д. Внутри workspace всё переносимо.
По gcc - может всёже собирать на host машине ? И новые компиляторы будут работать, и IDE гораздо шустрей.


Название: Re: CppUnit порт для QNX6
Отправлено: da-nie от Августа 03, 2018, 12:21:10 pm
Цитировать
Там есть всякие $(PROJECT_ROOT) и т.д. Внутри workspace всё переносимо.

То есть, путь можно указывать типа $(PROJECT_ROOT)/Unit?

Цитировать
По gcc - может всёже собирать на host машине ? И новые компиляторы будут работать, и IDE гораздо шустрей.

Может быть. :)


Название: Re: CppUnit порт для QNX6
Отправлено: da-nie от Августа 03, 2018, 01:27:24 pm
Цитировать
Исходники можно раскидать по разным папкам (как внутри проекта, так и снаружи) и  добавлять выборочно (но только папку целиком):

Файлы в папках компилируются, но эта чудесная IDE пытается сразу после компиляции из этих файлов из папки собрать проект. Что, естественно, не получается, так как в проекте объектников слегка больше, чем модулей в папке. Как ей объяснить, что линковку делать надо потом, я не представляю.  8)


Название: Re: CppUnit порт для QNX6
Отправлено: da-nie от Августа 06, 2018, 02:13:29 pm
Задал этот интересный вопрос с раскидыванием проекта по папкам на kpda.ru.
Посоветовали в common.mk (как я понял) вписать EXTRA_OBJS+=$(PROJECT_ROOT)/ ну и тут путь к объектникам. Но ни фига не работает - во-первых, оно желает видеть в EXTRA_OBJS не путь к папке, а сами файлы объектников. А во-вторых, если я туда прописываю имя файла, оно не компилирует этот файл, а просто ругается, что нет правила для его сборки.
Дурацкая IDE, конечно. :(


Название: Re: CppUnit порт для QNX6
Отправлено: da-nie от Августа 06, 2018, 05:51:47 pm
Новая информация от kpda. Оказывается, не OBJ надо добавлять, а EXTRA_SRCVPATH+=$(PROJECT_ROOT)/ . Завтра проверю. И, надеюсь, заработает.


Название: Re: CppUnit порт для QNX6
Отправлено: da-nie от Августа 07, 2018, 07:18:41 pm
Всё оказалось очень просто. Настроить дополнительные папки можно прямо из IDE. Она сама заполняет EXTRA_SRCVPATH и EXTRA_INCVPATH.
НО (!) вот в чём фишка: при незаполненных EXTRA_INCVPATH компиляция идёт в каталоге $(PROJECT_ROOT)/src. Если же я добавляю папку, то почему-то про каталог src система забывает. А я-то думал, он изначально по-умолчанию указан как основной. Вот и вся проблема. Нужно просто указать так же в EXTRA_SRCVPATH и EXTRA_INCVPATH и каталог $(PROJECT_ROOT)/src. И всё начинает работать, как надо.

Я разбил проект по папкам с иерархией (41 папка) и теперь почему-то он автоматически компилирует и debug-реализацию, хотя в настройках проекта стоит только release.  ::) Как так вышло, ума не приложу.  :-\

Upd. Оказалось, IDE на каком-то этапе создала makefile в папке, где формируется debug-реализация (o-g, там не было makefile). А убрать его в соответствии с настройками проекта она не пожелала.


Название: Re: CppUnit порт для QNX6
Отправлено: PoP от Августа 08, 2018, 11:12:31 am
Всё оказалось очень просто. Настроить дополнительные папки можно прямо из IDE. Она сама заполняет EXTRA_SRCVPATH и EXTRA_INCVPATH.
Вам об этом и писали. Читайте внимательнее ответы.
Исходники можно раскидать по разным папкам (как внутри проекта, так и снаружи) и  добавлять выборочно (но только папку целиком): Project->Properties->QNX C/C++ Project->Compiler->Category->Extra sources paths (Extra include paths).


Название: Re: CppUnit порт для QNX6
Отправлено: da-nie от Августа 08, 2018, 12:34:09 pm
Там не в этом дело, PoP. Там вся мякотка в том, что после указания каталога как дополнительного, IDE забывает про каталог src, который у неё был основной для исходников (до добавления отдельных каталогов, IDE с src работала). То есть, я-то думаю, что добавляю каталог к уже существующему в списке каталогов с исходниками src, а на самом деле src в список тоже надо после такого добавлять самому.


Название: Re: CppUnit порт для QNX6
Отправлено: PoP от Августа 09, 2018, 01:02:23 pm
Всё оказалось очень просто. Настроить дополнительные папки можно прямо из IDE. Она сама заполняет EXTRA_SRCVPATH и EXTRA_INCVPATH.
Я про это.
И видимо никто не будет спорить что IDEшка кривая. И тормозная. Особенно найтивная.
Но ведь ничто не мешает взять любой устраивающий Вас редактор и написать makefile.
Я знаю людей, которым удобнее писать тесты в винде, сохранять в разделяемой (через самбу) папке и компилить в 4-ке. Помоему там только адекватная парсилка ошибок не прикручена.
Кстати, ещё к 6.2 (вроде)  был third-party ISO с кучей всего, включая вполне приличные обёртки для GDB (и под фотон, и консольные).


Название: Re: CppUnit порт для QNX6
Отправлено: da-nie от Августа 09, 2018, 08:55:00 pm
Так "про это" я с самого начала делал. Но этого оказалось мало.

Что касается своего makefile: здорово, наверное, быть знатоком UNIX-систем, но это не про меня от слова совсем. :) У меня от остального-то голова пухнет (да хотя бы от новых стандартов Си++ и непоняток, как всё-таки правильно по современным подходам писать ПО). То есть, makefile такого уровня, как в common.mk я не напишу никогда.
Вот пример доступного для меня по пониманию makefile для досовского Watcom 10:

Код:
# MEMBFUN

pump: .SYMBOLIC pump.exe

objects =main.obj &
cedit.obj &
cmain.obj &
cautomat.obj &
cbutton.obj &
vesa.obj &
ciodata.obj &
cwindow.obj &
font.obj &
cdevice.obj &
cgraphic.obj &
clistbox.obj &
ckbd.obj &
cvideo.obj &
clexeme.obj &
cla.obj &
csa.obj &
tga.obj

cpp_options = -s -5r -5s -fp3 -otiarnlm -bt=dos

!include ../cppexamp.mif

Вот его я понимаю. :)

А вот такое, уже слабо понимаю:

Код:
TARGET=$(shell basename `pwd`)
CC=g++
CFLAGS+=$(shell pkg-config --cflags libusb-1.0)
LDFLAGS=$(shell pkg-config --libs libusb-1.0)
SOURCES=main.cpp cflironecontrol.cpp tga.cpp
OBJECTS=$(SOURCES:.cpp=.o)
EXECUTABLE=flirone

all: $(SOURCES) $(EXECUTABLE)

$(EXECUTABLE): $(OBJECTS)
$(CC) $(LDFLAGS) -o $@ $(OBJECTS) $(LDFLAGS) -lm -Wall 

.cpp.o:
$(CC) $(CFLAGS) -c $< -o $@

clean:
rm -f cflironecontrol.o main.o tga.o flirone


Название: Re: CppUnit порт для QNX6
Отправлено: darkelf от Августа 10, 2018, 10:08:58 am
Так "про это" я с самого начала делал. Но этого оказалось мало.

Что касается своего makefile: здорово, наверное, быть знатоком UNIX-систем, но это не про меня от слова совсем. :) У меня от остального-то голова пухнет (да хотя бы от новых стандартов Си++ и непоняток, как всё-таки правильно по современным подходам писать ПО). То есть, makefile такого уровня, как в common.mk я не напишу никогда.
Вот пример доступного для меня по пониманию makefile для досовского Watcom 10:

Код:
# MEMBFUN
...

Вот его я понимаю. :)

А вот такое, уже слабо понимаю:

Код:
TARGET=$(shell basename `pwd`)
CC=g++
CFLAGS+=$(shell pkg-config --cflags libusb-1.0)
LDFLAGS=$(shell pkg-config --libs libusb-1.0)
SOURCES=main.cpp cflironecontrol.cpp tga.cpp
OBJECTS=$(SOURCES:.cpp=.o)
EXECUTABLE=flirone

all: $(SOURCES) $(EXECUTABLE)

$(EXECUTABLE): $(OBJECTS)
$(CC) $(LDFLAGS) -o $@ $(OBJECTS) $(LDFLAGS) -lm -Wall 

.cpp.o:
$(CC) $(CFLAGS) -c $< -o $@

clean:
rm -f cflironecontrol.o main.o tga.o flirone
прошу прощения, что вмешиваюсь, но второй, имхо, как-раз более понятный и главное более стандартный, чем первый. Например, такой его синтаксис поймёт и nmake от Microsoft.


Название: Re: CppUnit порт для QNX6
Отправлено: PoP от Августа 10, 2018, 11:34:41 am
И make из дистрибутива Watcom под windows (ну и под всё другое) - есть опыт писания на Watcom для доса и винды.
Первое скорее всего кусок, который включится в какойто дефолтный makefale инклюдом.


Название: Re: CppUnit порт для QNX6
Отправлено: ob1 от Августа 10, 2018, 11:55:21 am
И видимо никто не будет спорить что IDEшка кривая. И тормозная. Особенно найтивная.

Во-первых, можете попробовать IDE 7.0 вместо IDE 4.7 (для QNX 6.5, а уж для 6.3 я не помню версию IDE), не зря же выпускают новые версии IDE. Во-вторых, любая IDE будет тормозить, мне неизвестны не тормозящие IDE.

Но ведь ничто не мешает взять любой устраивающий Вас редактор и написать makefile.

В-третьих, редактор и IDE немного (на самом деле нет) разные вещи. Редактор это только одна из функций IDE. Конечно, если из всех функций IDE нужен только редактор, то пользоваться IDE (вероятно) излишне.

Кстати, ещё к 6.2 (вроде)  был third-party ISO с кучей всего, включая вполне приличные обёртки для GDB (и под фотон, и консольные).

Со времён 6.2 акцент разработки уже окончательно сместился в сторону кросс-разработки. Какой смысл разрабатывать нативно, когда под ляпихом куча (бесплатных) редакторов, обёрток и прочих свистелок? Вопрос, конечно, риторический.


Название: Re: CppUnit порт для QNX6
Отправлено: PoP от Августа 10, 2018, 06:51:40 pm
У меня в 6.3 SP 3, как я понимаю, 2.95.3.
Кусь....
Upd2. Скачал gcc 4.2.1 и binutils-2.17 с community.qnx.com . Распаковал в Qnx 6.3 SP3 (вроде как ставили в 6.5, как я понял, но у меня её нет). Выполнил qcc -V. В IDE появился новый компилятор. Указал в проекте компилятор 4.2.1. Дальше неприятное: "hello word" собрался, но только если на stdio и printf. Стоит подключить хотя бы просто iostream и всё - у компилятора проблемы со сборкой библиотек. Про stl уж и не говорю.
Ну, хочется человеку найтивно... А может, подругому никак...


Название: Re: CppUnit порт для QNX6
Отправлено: da-nie от Августа 10, 2018, 07:56:55 pm
Цитировать
Ну, хочется человеку найтивно... А может, подругому никак...

Так для кросскомпиляции придётся таскать ещё отдельный компьютер. Настраивать его. Беречь от вирусов (а в QNX я спокойно сую любые флэшки и даже не задумываюсь). Да и, если честно, приятно в чистом UNIX работать. Просто приятно. Вот чисто эстетически. :) Можно, конечно, под Linux работать, но вот его-то я как раз не люблю: вот эти pkg-config --cflags libusb-1.0 в makefile появились потому, что в разных дистрибутивах библиотеки раскидывались в разные каталоги, что меня так просто выводит из себя. Ну и почему в unistd в linux нет delay я тоже понять не могу. ::) Портировали тут часть моей QNX-программы под Astra-Linux, релиз "Орёл". И оказалось, delay-то отсутствует в системе. 8)
Впрочем, вот купят QNX 6.5 и попробую кросскоспиляцию. (я надеюсь. А то есть подозрение, что QNX 6.5 вояки не разрешат. ГК, конечно, уверенно кричал, что поставим, что нам надо на ноутбуки (туда 6.3 и 6.4 не поставить), когда я его предупреждал под что будет написано ПО, но я думаю, он себя переоценил, и всё это зарубят на присвоении литеры. Переписывать под этот "Орёл" на QT программу с кучей фотоновской графики и специфических QNX-вещей - да проще послать их всех нафиг).

Цитировать
но второй, имхо, как-раз более понятный

Ну вот так получилось, что у меня наоборот. :)

Цитировать
Первое скорее всего кусок, который включится в какойто дефолтный makefale инклюдом.

Ну, не совсем. Там есть ещё cppexamp.mif (подключаемый в тот makefile):

Код:
# cppexamp.mif
#
# This file is always included by makefiles's in sample sub-directories.
#
# Note: the file includes local.mif from this directory; local.mif is empty
#       as shipped.  It can be used for any customization required in a
#       particular installation.
#


!include ../local.mif

.extensions:
.extensions: .exe .lnk .obj .cpp .c

!ifndef cpp_compiler
!   ifdef __NTAXP__
!       define cpp_compiler wppaxp
!       define c_compiler wccaxp
!   else
!       define cpp_compiler wpp386
!       define c_compiler wcc386
!   endif
!endif

!ifndef linker
!   define linker wlink
!endif

!ifndef link_cmds
!   define link_cmds linkpgm.lnk
!endif

!ifndef cpp_options
!   define cpp_options -zq -xs -d1
!   define c_options -zq -d1
!endif

.cpp.obj: .AUTODEPEND
    $(cpp_compiler) $(cpp_options) $[*

.c.obj: .AUTODEPEND
    $(c_compiler) $(c_options) $[*

pump.exe: $(objects) $(link_cmds)
    $(linker) @$(link_cmds)

linkpgm.lnk: $(__MAKEFILES__) ../local.mif
    @%create $^@
    @%append $^@ NAME    pump
    @%append $^@ OPTION  quiet, eliminate, map, show
    @%append $^@ DEBUG   all
    @for %i in ($(objects)) do @%append $^@ FILE    %i

clean: .SYMBOLIC
    @if exist *.exe del *.exe
    @if exist *.lnk del *.lnk
    @if exist *.obj del *.obj
    @if exist *.map del *.map
    @if exist *.err del *.err

Ну и запускает компиляцию wc.bat:

Код:
@echo off
set __opath=%path%
set path=c:\lang\watcom10\bin;c:\lang\watcom10\binw
set __oinc=%include%
set include=c:\lang\watcom10\h
set watcom=c:\lang\watcom10\.
del pump.exe
wmake

Вот и всё.

Но, впрочем, например, для приставки PSP я свои проекты собирал таким makefile:
Код:
TARGET = 3dengine
OBJS =ccontrol.o cdecorator_cisector.o cengine_base.o vram.o cengine_gportal.o cgraph.o ciengine.o cisector.o ckeyboard.o cmouse.o common.o cplayer.o csimplybridge.o csimplydoor.o csimplyplatform.o csimplysector.o csimplyteleport.o cswitchsector.o ctexturefollow.o cunit.o cvideo.o localmath.o cwallmap.o main.o
INCDIR =
CFLAGS = -O3 -G0 -Wall
CXXFLAGS = $(CFLAGS) -fno-exceptions -fno-rtti
ASFLAGS = $(CFLAGS)
LIBDIR =
LDFLAGS =
LIBS =-lpspgum -lpspgu -lm -lstdc++ -lpspaudiolib -lpspaudio -lpsprtc
EXTRA_TARGETS = EBOOT.PBP
PSP_EBOOT_TITLE = 3dengine
PSP_EBOOT_ICON = ICON.PNG
PSP_EBOOT_ICON1 =
PSP_EBOOT_UNKPNG = PIC.PNG
PSP_EBOOT_PIC1 =
PSP_EBOOT_SND0 =
PSPSDK=$(shell psp-config --pspsdk-path)
include $(PSPSDK)/lib/build.mak

В целом, он тоже мне почти понятен.

Цитировать
Во-первых, можете попробовать IDE 7.0 вместо IDE 4.7

А у меня в 6.3 версия IDE 2.2.  :D

Цитировать
любая IDE будет тормозить, мне неизвестны не тормозящие IDE.

CodeBlocks не тормозит.  ::) Visual Studio 6 и 2010 (я выше не ставил) не тормозит. А IDE Momentics обожает замирать на минутку-другую, пытаясь разобрать файл исходника (чем больше в файле ошибок, тем больше она тормозит. Со временем она набирает кодовую базу что ли и тормозит уже меньше. А потом у неё сбой кодовой базы и приходится стирать один файлик в workspace. Тогда всё начинается заново. Причём, тормозит она больше всего на фотоновских приложениях - там, видно, куча библиотек;пока все обегаешь в поисках функций...). Изменил буковки, нажал Save и можно отдыхать. И это как бы на на хорошем таком промышленном компьютере. :)

Цитировать
Со времён 6.2 акцент разработки уже окончательно сместился в сторону кросс-разработки.


Есть у меня подозрение, что IDE тормозит из-за каких-то архитектурных особенностей именно QNX. Причём, компьютеры всё мощнее, а тормоза те же. Уж не связано ли это с блокировкой потоков на каком-либо объекте синхронизации, которая привязана с системному такту?
И я подозреваю, что невозможность запустить IDE с приемлемой скоростью и привели к кроссплатформенной разработке. Чтобы жалоб меньше было. :)


Название: Re: CppUnit порт для QNX6
Отправлено: PoP от Августа 13, 2018, 12:14:30 pm
Есть у меня подозрение, что IDE тормозит из-за каких-то архитектурных особенностей именно QNX. ...кусь...
И я подозреваю, что невозможность запустить IDE с приемлемой скоростью и привели к кроссплатформенной разработке. Чтобы жалоб меньше было. :)
Eclipse будет тормозить везде. Гдето больше, гдето меньше (java однако). Найтивный видимо сильно тормозит не из за архитектурных особенностей именно QNX (с) а из за особенностей реализации Java под QNX. Скорее всего к кроссплатформенной разработке всётаки привело то, что на большинстве найтивных машин нет ни экрана, ни клавы с мышю, мало памяти, и хорошо если есть вменяемый по объёму и скорости диск.


Название: Re: CppUnit порт для QNX6
Отправлено: ob1 от Августа 13, 2018, 12:29:49 pm
Ну, хочется человеку найтивно... А может, подругому никак...

Судя по всему, первое.

Найтивный видимо сильно тормозит не из за архитектурных особенностей именно QNX (с) а из за особенностей реализации Java под QNX.

Именно так. В QNX использовалась Java ME специфичной реализации.

Скорее всего к кроссплатформенной разработке всётаки привело то, что на большинстве найтивных машин нет ни экрана, ни клавы с мышю, мало памяти, и хорошо если есть вменяемый по объёму и скорости диск.

Вы ещё не забывайте, что на x86 мир не заканчивается.


Название: Re: CppUnit порт для QNX6
Отправлено: ob1 от Августа 13, 2018, 01:01:41 pm
Так для кросскомпиляции придётся таскать ещё отдельный компьютер.

Один компьютер (ну можно два если с ноутбуком). Зато не надо на каждой системе держать средства разработки. Это ведь и вредно может быть.

Можно, конечно, под Linux работать, но вот его-то я как раз не люблю: вот эти pkg-config --cflags libusb-1.0 в makefile появились потому, что в разных дистрибутивах библиотеки раскидывались в разные каталоги, что меня так просто выводит из себя.

А Вас как простого пользователя Linux как это должно беспокоить? Зачем Вам знать про pkg-config и каталоги? Вопросы опять же риторические.

Ну и почему в unistd в linux нет delay я тоже понять не могу. ::) Портировали тут часть моей QNX-программы под Astra-Linux, релиз "Орёл". И оказалось, delay-то отсутствует в системе. 8)

Ой-вей, Орло-капец какой-то прямо. Во-первых, если бы Вы внимательно прочитали документацию, то знали бы, что delay() это QNX-специфичная функция. Понятное дело, что в других ОС её может не быть, или она может работать иначе, или вообще делать что-то другое. Такие места в коде стоит оборачивать во что-то типа:

Код:
#ifdef __QNX__
    delay(50);
#else
#   error Can't delay()
#endif

Но только кто думает о таких мелочах как кросс-разработка? Это ещё один риторический вопрос. Ну а, во-вторых, аналог delay() на POSIX вызовах делается за 5 минут с учётом гугления.

Впрочем, вот купят QNX 6.5 и попробую кросскоспиляцию. (я надеюсь. А то есть подозрение, что QNX 6.5 вояки не разрешат. ГК, конечно, уверенно кричал, что поставим, что нам надо на ноутбуки (туда 6.3 и 6.4 не поставить), когда я его предупреждал под что будет написано ПО, но я думаю, он себя переоценил, и всё это зарубят на присвоении литеры. Переписывать под этот "Орёл" на QT программу с кучей фотоновской графики и специфических QNX-вещей - да проще послать их всех нафиг).

Вот я даже не знаю, как Вам об этом сказать... Тут некоторые изменения произошли в использовании QNX 6.5 для вояк. Вместо QNX 6.5 вам бы закупить ЗОСРВ «Нейтрино». Оно и с О1, и с Qt в одной коробке идёт. Не говоря уже о множественных обновлениях с момента выхода 6.5.

CodeBlocks не тормозит.  ::) Visual Studio 6 и 2010 (я выше не ставил) не тормозит. А IDE Momentics обожает замирать на минутку-другую, пытаясь разобрать файл исходника (чем больше в файле ошибок, тем больше она тормозит. Со временем она набирает кодовую базу что ли и тормозит уже меньше. А потом у неё сбой кодовой базы и приходится стирать один файлик в workspace. Тогда всё начинается заново. Причём, тормозит она больше всего на фотоновских приложениях - там, видно, куча библиотек;пока все обегаешь в поисках функций...). Изменил буковки, нажал Save и можно отдыхать. И это как бы на на хорошем таком промышленном компьютере. :)

Code::Blocks формально IDE, но фактически не соответствует современным ожиданиям от IDE. Хотя могу ошибаться, с ней особо не работал. Да и сравниваете Вы MSVS 6.0 и 2010 на современном железе под Windows и IDE Momentics 2.2 на урезанной Java под QNX. Некорректное сравнение. Недавно запускал свежий MSVS на виртуалке под Core i5 выделив ей 4 ядра и 8 гигов оперативки — работать нельзя. Даже не на этапе компиляции, а просто проект создать уже тяжко. Хотя с чего бы так тормозить хоть и на виртуалке?


Название: Re: CppUnit порт для QNX6
Отправлено: PoP от Августа 13, 2018, 02:01:21 pm
Вы ещё не забывайте, что на x86 мир не заканчивается.
У нас все PPC и так соответствуют пп 1 - ни экрана ни клавы  :)


Название: Re: CppUnit порт для QNX6
Отправлено: da-nie от Августа 13, 2018, 02:21:21 pm
Цитировать
Зачем Вам знать про pkg-config и каталоги? Вопросы опять же риторические.

Не всегда ведь проект делается в IDE. Да и вот свежий пример: решил-таки Linux поставить. Смотрим, что у нас есть из популярного:
Fedora
Mint
Ubuntu
OpenSuSe
Mageia
Astra Linux

У всех (кроме Astra) перечисленных графика оформления в стиле современных мультфильмов - примитивизм в дизайне жуткий. Смотреть просто противно. Все эти градиенты чистых цветов просто уродство. Но я помню, 14 лет назад я сидел на Mandrake и Red Hat и там мне решительно нравились темы оформления окон в KDE и вообще общий дизайн. Жаль, больше они не работают на современных системах. А что за хрень штампуют сейчас? Убить этих дизайнеров.
Ubuntu 16.10 отказалась ставить mc по atp install! Не доверяет, говорит, репозиторию! И вылетает в ошибку сразу после загрузки на I5. Копирование на IDE-винчестер шло со скоростью 10...9...8...1.5 Мб/с. Это шутка такая? Windows 7 только что на этом винчестере летала. Ну и дурацкая панель вместо "пуск". То же и у Fedora.
Более-менее Mint нормально работает. Но дизайн всё равно отвратный.
Mageia 3 была ещё ничего. Но Mageia 6... всё тот же отвратный дизайн.
У Astra всё вроде бы есть, но что-то я задолбался её на Уране настраивать. То порты com не видит, то запись в lpt только root имеет (sudo не помогает).
Наверное, всё же Mint поставлю.

Цитировать
Во-первых, если бы Вы внимательно прочитали документацию,

Честно говоря, я поражаюсь памяти присутствующих. :) Я давно забыл, что где и как читал. И что там написано. А вы всё помните. :) Как вам это удаётся?! ::) А так, я был уверен, что delay штатная функция unix. Да она и в ms-dos вроде бы была...

Цитировать
Ну а, во-вторых, аналог delay() на POSIX вызовах делается за 5 минут с учётом гугления.

Сделать-то я сделал, но осадочек остался. :)

Цитировать
Вместо QNX 6.5 вам бы закупить ЗОСРВ «Нейтрино».

А ПО для QNX 6.3 на нём работает? Или там Qt и от фотона одни воспоминания? :) Ну и главная головная боль - ставится и работает ли оно на таком чуде, как бывшая ЕС-1866, а ныне Уран-2.

Хотя, написано "Технологии Qt, GTK, Photon".

Цитировать
Да и сравниваете Вы MSVS 6.0 и 2010 на современном железе под Windows и IDE Momentics 2.2 на урезанной Java под QNX.

Ну уж VC 6 у меня на совсем слабых системах работала гораздо быстрее, чем Momentics 2.2 на современном железе.

Цитировать
Недавно запускал свежий MSVS на виртуалке под Core i5 выделив ей 4 ядра и 8 гигов оперативки — работать нельзя

Это которой 40 ГБ надо? Нет, я такое не использую. К счастью. Потому и остановился на 2010 и Windows XP :)

Цитировать
из за особенностей реализации Java под QNX.

Честно говоря, плохо представляю, что там можно было сделать такого, чтобы сама Java ТАК отжирала процессор. И при этом скорость работы от процессора (начиная с определённых частот) почти переставала зависеть.  ::)


Название: Re: CppUnit порт для QNX6
Отправлено: darkelf от Августа 13, 2018, 02:58:10 pm
Цитировать
Во-первых, если бы Вы внимательно прочитали документацию,

Честно говоря, я поражаюсь памяти присутствующих. :) Я давно забыл, что где и как читал. И что там написано. А вы всё помните. :) Как вам это удаётся?! ::) А так, я был уверен, что delay штатная функция unix. Да она и в ms-dos вроде бы была...

Она была в dos.h, которого под unix-ами нет. В древнем bc 3.1, в справке про эту функцию в разделе portability написано:
Код:
+DOS+UNIX+Windows+ANSI C+C++ Only+
|Yes|    |       |      |        |
+---+----+-------+------+--------+


Название: Re: CppUnit порт для QNX6
Отправлено: ob1 от Августа 13, 2018, 04:46:27 pm
Цитировать
Вместо QNX 6.5 вам бы закупить ЗОСРВ «Нейтрино».

А ПО для QNX 6.3 на нём работает? Или там Qt и от фотона одни воспоминания? :)

Смотря какое ПО. В целом работает. Там Photon, а в нём можно Qt и десктопный OpenGL. Вы, наверное, с QNX 6.6 путаете, там как раз Photon нет.

Ну и главная головная боль - ставится и работает ли оно на таком чуде, как бывшая ЕС-1866, а ныне Уран-2.

Вероятно должно. На какие-то ЕС1866 ставится. Они же разные бывают по начинке, да?


Название: Re: CppUnit порт для QNX6
Отправлено: da-nie от Августа 13, 2018, 05:59:19 pm
Цитировать
Она была в dos.h, которого под unix-ами нет

Логично. :) Просто delay находится в unistd. А "<unistd.h> содержит различные основные функции и константы POSIX". Потому я и думал, что она везде, где POSIX есть должна быть.

Цитировать
Вы, наверное, с QNX 6.6 путаете, там как раз Photon нет.

Наверное. Я дальше 6.5 не смотрел. :)

Цитировать
Вероятно должно. На какие-то ЕС1866 ставится. Они же разные бывают по начинке, да?

Судя по буклету, по которому заказывали, там вариативность небольшая.


Название: Re: CppUnit порт для QNX6
Отправлено: PoP от Августа 14, 2018, 02:36:50 pm
Не всегда ведь проект делается в IDE. Да и вот свежий пример: решил-таки Linux поставить. Смотрим, что у нас есть из популярного:
Fedora
Mint
Ubuntu
OpenSuSe
Mageia
Astra Linux
Debian ?
Если не устраивает новомодная systemd - есть форк с system V.
Если не издеваться над ней подключая репозитории testing - стабильна до безобразия.
Ну а окружений рабочего стола - пактически в любом линухе на любой вкус и цвет.


Название: Re: CppUnit порт для QNX6
Отправлено: da-nie от Августа 14, 2018, 03:27:54 pm
Не, Debian такая же, как и Ubuntu.
Я Mint поставил. Он мне понравился. :)


Название: Re: CppUnit порт для QNX6
Отправлено: PoP от Августа 14, 2018, 05:25:39 pm
Видимо - Cinnamon больше похожа на XP  :).
А так - всё практически тоже, только в профиль.
В основе Ubuntu - ветка unstable  Debian. Свежее общее ПО, главное - драйвера под новое железо появляются раньше. Встречаются коммерческие и не GPL программы в центре приложений. Естественно - слегка меньше стабильность.
Mint основан на Ubuntu, использует репозитории Ubuntu основные изменения - простота начальной установки и окружение по умолчанию.


Название: Re: CppUnit порт для QNX6
Отправлено: da-nie от Августа 14, 2018, 07:19:27 pm
я поставил Mate. :) Меня просто достала windows 7 (я мог бы и XP поставить, но решил в качестве эксперимента всё же перейти хотя бы на семёрку). Она просто неудобная. Тупой проводник без кнопки 'на уровень выше',часто забывающий переключать папку по одинарному щелчку. Тормоза Firefox. Испорченный Paint. Нет, пора на Linux возвращаться после десятилетнего перерыва. :) Правда, вот чего я в линуксах не люблю, так это постоянные изменения с каждым обновлением. Я всё же люблю стабильность... Ну и система пакетов меня раньше доводила до белого каления, когда в системе половина мусора, который используют 1.5 приложения, а этот мусор тащит свои зависимости разных версий. Ставишь из тарбола программу, а ей ещё 100 пакетов надо, а им ещё, а ещё один не совместим с тем, что уже есть. Тут хоть apt работает автоматически. Вроде бы. :)

Цитировать
Ну а окружений рабочего стола - пактически в любом линухе на любой вкус и цвет.

Игра в конструктор меня не прельщает. Потому я и не ставил gentoo. :)


Название: Re: CppUnit порт для QNX6
Отправлено: da-nie от Октября 11, 2018, 07:08:37 pm
Интересная штука получается.
Вот есть у меня базовый класс ошибок CErrorsBased вида:

Код:
class CErrorsBased
{
 public:  
  //конструктор
  CErrorsBased();
  //деструктор
  virtual ~CErrorsBased() {};
 protected:
  virtual void SetState(void)=0;//задать состояние в памяти
};

От этого класса унаследованы классы ошибок конкретного устройства:

Код:
class CErrorsAcs:virtual public CErrorsBased
{
 public:  
  //конструктор
  CErrorsAcs();
  //деструктор
  ~CErrorsAcs();
 public:
  void Acs_SetCANError(uint32_t index,bool state);//установить ошибку "отказ CAN"
  bool Acs_IsCANError(uint32_t index);//получить, задана ли ошибка "отказ CAN"
};
...
//----------------------------------------------------------------------------------------------------
//установить ошибку "отказ CAN"
//----------------------------------------------------------------------------------------------------
void CErrorsAcs::Acs_SetCANError(uint32_t index,bool state)
{
 cErrorsState.cAcs[index].CANError=state;
 SetState();
}
..

А от этих классов ошибок конкретного устройства унаследован общий объединяющий класс ошибок.

Код:
class CErrors:virtual public CErrorsACU,virtual public CErrorsAcs
{
 public:  
  //конструктор
  CErrors();
  //деструктор
  ~CErrors();
 public:
  void ChangeState(uint32_t index,void (CErrors::*set_function_ptr)(uint32_t,bool),bool (CErrors::*is_function_ptr)(uint32_t));//изменить состояние ошибки на противоположное
 protected:
  void SetState(void);//задать состояние в памяти
};

А вот дальше интересно. Функция ChangeState сделана так:

Код:
//----------------------------------------------------------------------------------------------------
//изменить состояние на противоположное
//----------------------------------------------------------------------------------------------------
void CErrors::ChangeState(uint32_t index,void (CErrors::*set_function_ptr)(uint32_t,bool),bool (CErrors::*is_function_ptr)(uint32_t))
{
 if ((this->*is_function_ptr)(index)==true) (this->*set_function_ptr)(index,false);
                                       else (this->*set_function_ptr)(index,true);                                      
 if ((this->*is_function_ptr)(index)==true) printf("true!\r\n");
 else printf("false!\r\n");
}

То есть, она требует два указателя на функции класса CErrors. Всё просто.
Вызываем: cErrors.ChangeState(index,&CErrors::Acs_SetCANError,&CErrors::Acs_IsCANError);

Компилятор напрягся:
Цитировать
pointer to member cast from virtual base 'CErrorsAcs'
will only work if you are very careful


Не понимаю, зачем он сделал это преобразование (а оно оказалось критичным). Эти методы унаследованы CErrors и в целом ему уже принадлежат.
Запускаем программу. И падаем. А дело в том, что функция класса CErrorsAcs вызывает SetState. Но SetState была определена в CErrorsBased и реализована в CErrors. А компилятор сделал преобразование к классу CErrorsAcs. И была вызвана функция без реализации.

Интересно, для чего компилятору понадобилось сделать такое вот преобразование?
Так-то я выбросил почти всё это наследование и сделал агрегацию, но стало интересно, почему же так получилось.

Кстати, что-то найти не могу порядок инициализации переменных (и массивов строк вида a[]="sdfdfsdf"; ) и классов и прочих сложных типов между модулями. Вот если в одном модуле класс создаётся глобально и в своём конструкторе вызывает динамическое создание другого класса, который в уже своём конструкторе желает взять строковую константу, то какие гарантии, что эта константа (определённая в том же модуле, где и конструктор её использующий) уже инициализирована? Для типа std::string - никаких, а вот для вида a[]="sdfdfsdf" есть ли гарантия, что сперва будут инициализированы все простые типы, а лишь потом сложные?. Я знаю, что порядок между модулями не определён, а внутри модуля в порядке описания (если не использовано явное указание компилятору на то, что должно был инициализировано сначала). Но тогда легко получается вышеописанная ситуация. В данном примере я заменил std:string на обычный массив и он стал инициализироваться перед инициализацией классов. В принципе, насколько я помню, секция .data как раз и хранит значения глобальных переменных, а секция .text константы. Следовательно, при запуске эти секции уже есть в программе и они уже инициализированы задолго до вызовов конструкторов любых сложных объектов.


Название: Re: CppUnit порт для QNX6
Отправлено: lastcross от Октября 18, 2018, 07:50:37 pm
Цитировать
Интересная штука получается.
Вот есть у меня базовый класс ...

Вам следует почитать и изучить вопрос, как хранятся данные при виртуальном наследовании. Тут (https://stackoverflow.com/a/28177191) на английском но все же примерно написано, что не так просто оперировать указателями на члены класса участвующих в таком наследовании.

И вообще, резюмируя - если вы пришли к виртуальному наследованию, то с вероятностью близкой к единице вы архитектурно неправильно представляете свое решение.

Цитировать
Кстати, что-то найти не могу порядок инициализации переменных

Все это можно почитать тут  (https://en.cppreference.com/w/cpp/language/initialization)


Название: Re: CppUnit порт для QNX6
Отправлено: da-nie от Октября 18, 2018, 08:23:38 pm
Цитировать
Вам следует почитать и изучить вопрос, как хранятся данные при виртуальном наследовании. Тут на английском но все же примерно написано, что не так просто оперировать указателями на члены класса участвующих в таком наследовании.

Честно говоря, ни черта не понял, что там написано. :-\
А так, чисто логически, непонятно, почему я не могу создать указатель на унаследованную функцию и вызвав эту функцию не получить преобразование к унаследованному классу.

Цитировать
И вообще, резюмируя - если вы пришли к виртуальному наследованию, то с вероятностью близкой к единице вы архитектурно неправильно представляете свое решение.

Это возможно. Ведь в конечном итоге я всё заменил агрегацией. Мне изначально нужно было, чтобы все классы работали с одной общей структурой и при этом совсем не хотелось передавать при инициализации ссылку на эту структуру в каждый класс, а также все функции этих классов были бы унаследованы объединяющим классом (делегирование делать плохо - этих функций сильно дофига, и я потому и разделил их на отдельные классы). Поэтому я определил структуру в базовом классе и от него унаследовал все остальные. Так как наследование было виртуальным, то базовый класс и эта структура в объединяющем классе CError находятся в единственном числе и все классы работают с одним и тем же экземпляром.

Цитировать
Все это можно почитать тут

О, спасибо!
Если я правильно понял,что там написано, гарантируется инициализация переменных до объектов.


Название: Re: CppUnit порт для QNX6
Отправлено: da-nie от Октября 19, 2018, 08:16:04 am
Нашёл занятное описание проблемы с указателями на функции классов:

Цитировать
Жуткие сведения об указателях на функции-члены

Рассмотрим ограничения, накладываемые на указатели на функции-члены. Во-первых, нельзя использовать указатель на функцию-член для статического метода. В этом случае нужно использовать обычный указатель на функцию (так что название «указатель на функцию-член» несколько некорректно, на самом деле это «указатель на нестатическую функцию-член»). Во-вторых, при работе с классами-наследниками есть несколько особенностей. Например, следующий код будет скомпилирован на MSVC, если оставить комментарии:

class SomeClass
{
  public:
    virtual void some_member_func(int k, char* p)
    {
      printf(“In SomeClass”);  
    };
}

class DerivedClass : public SomeClass
{
  public:
// Если разкомментировать следующую строку, то код в строке * будет выдавать ошибку
// virtual void void some_member_func(int k, char* p) {printf(“In DerivedClass”); };
};

int main()
{
  // Объявляем указатель на функцию-член класса SomeClass
  typedef void (SomeClass::*SomeClassMFP)(int, char *);
  SomeClassMFP my_memfunc_ptr;
my_memfunc_ptr = &DerivedClass::some_member_func; // ----- строка (*)
}

Довольно любопытно, &DerivedClass::some_member_func являтся указателем на функцию-член класса SomeClass. Это не член класса DerivedClass! Некоторые компиляторы ведут себя несколько иначе: например, Digital Mars C++ считает в данном случае, что &DerivedClass::some_member_func не определен. Но если DerivedClass переопределяет some_member_func, код не будет скомпилирован, т.к. &DerivedClass::some_member_func теперь становится указателем на функцию-член класса DerivedClass!

Приведение между указателями на функции-члены – крайне темная область. Во время стандартизации С++ было много дискуссий по поводу того, разрешено ли приводить указатели на функции-члены одного класса к указателям на функции-члены базового класса или класса-наследника, и можно ли приводить указатели на функции-члены независимых классов. К тому времени, когда комитет по стандартизации определился в этих вопросах, различные производители компиляторов уже сделали свои реализации, причем их ответы на эти вопросы различались. В соответствии со стандартом (секция 5.2.10/9), разрешено использование reinterpret_cast для хранения указателя на член одного класса внутри указателя на член независимого класса. Результат вызова функции в приведенном указателе не определен. Единственное, что можно с ним сделать - это привести его назад к классу, от которого он произошел. Я рассмотрю это далее, т.к. в этой области Стандарт имеет мало сходства с реальными компиляторами.

На некоторых компиляторах происходят ужасные вещи, даже при приведении между указателями на члены базового и наследуемого классов. При множественном наследовании использование reinterpret_cast для приведения указателя на фукнцию-член наследуемого класса к указателю на функцию-член базового класса может скомпилироваться, а может и нет, в зависимости от того в каком порядке базовые классы перечислены в объявлении наследника! Вот пример:

class Derived: public Base1, public Base2  // случай А
class Derived2: public Base2, public Base1 // случай Б
typedef void (Derived::*Derived_mfp)();
typedef void (Derived2::*Derived2_mfp)();
typedef void (Base1::*Base1mfp)();
typedef void (Base2::*Base2mfp)();
Derived_mfp x;

В случае А, static_cast<Base1mfp>(x) отработает успешно, а static_cast<Base2mfp>(x) нет. В то время как для случая Б верно противоположное. Вы можете безопасно приводить указатель на функцию член класса-наследника к указателю на функцию-член только первого базового класса! Если вы попробуете все-таки выполнить приведение не к первому базовому классу, MSVC выдаст предупреждение C4407, а Digital Mars C++ выдаст ошибку. Оба будут протестовать против использования reinterpret_cast вместо static_cast, но по разным причинам. Некоторые же компиляторы будут совершенно счастливы, вне зависимости от того, что вы делаете. Будьте осторожны!

Также в Стандарте есть другое интересное правило: можно объявлять указатель на функцию-член класса, до того как этот класс определен. У этого правила есть непредвиденные побочные эффекты, о которых я расскажу позже.

Также стоит отметить, что Стандарт С++ предоставляет указатели на члены-данные. Они имеют те же операторы и некоторые из особенностей реализации указателей на функции-члены. Они используются в некоторых реализациях stl::stable_sort, но я не знаю других значимых применениях этих указателей.


http://rsdn.org/article/cpp/fastdelegate.xml



Название: Re: CppUnit порт для QNX6
Отправлено: lastcross от Октября 19, 2018, 06:29:01 pm
Честно говоря, ни черта не понял, что там написано. :-\
А так, чисто логически, непонятно, почему я не могу создать указатель на унаследованную функцию и вызвав эту функцию не получить преобразование к унаследованному классу.

На самом деле там две проблемы (только из-за специфики кода сразу не заметно было что когда и где вызывается - делайте что-ли упрощенные ссылки на уже компилируемый пример в том-же Coliru (http://coliru.stacked-crooked.com/)).
Проблема номер 1:

 - Наследуемые классы от виртуальных классов из-за специфики "виртуальности" своих родителей вынуждены "объединять" данные родителей. А следовательно адреса по которым располагаются их данные зависят от двух (или возможно более в зависимости от иерархий) смещений - адреса объекта  к которому они принадлежат + адреса родителя к которому они относятся. По этому люди удивляются - как, так ? ведь я передаю адрес объекта - он ведь должен автоматически должен догадаться в поиске метода. Но компилятор совсем путается когда вы даете адресс объекта вызывая сигнатуру метода указанного с учетом смещения другого типа.  Ну как-то так, если я правильно понял объяснение. Сам же я - не уверен на 100%,  что именно по этой причине - но очень именно похоже для вашего случая что так

Проблема номер 2:

Как вы заметили позже дав кусок материала по "делегатам" - с виртуальными методами дело обстоит схожим способом. Они адресуются не просто смещением от адреса объекта - а еще и со смещением в зависимости от виртуальной таблицы ..

Все это компилятору не нравится (да и мне честно говоря то же). Ибо уверен что таким способо найдутся крайние случаи где нельзя точно понять какой метод вы хотите вызвать и гарантировать какой либо порядок исполнения. Поэтому компиляторы явно запрещают такое использование.

Цитировать
Это возможно. Ведь в конечном итоге я всё заменил агрегацией.
Подходы бывают разные, например на уровне интерфейсов и множественного наследования (которое исключает ромбовидное наследование) - думаю тоже можно реализовать подобные вещи.
Но я правда не совсем понял конечную цель, правда и не особо старался. Вообще на первый взгляд - вот так кот путать пользователя передачей обработчиков методов разного уровня наследования .. в данной реализации мне показалась сомнительной.

Цитировать
О, спасибо!
Если я правильно понял,что там написано, гарантируется инициализация переменных до объектов.

Я не понял вашего вопроса. Объекты/переменные - чем отличаются в вашем контексте? А лучше пример.


Название: Re: CppUnit порт для QNX6
Отправлено: da-nie от Октября 19, 2018, 07:29:25 pm
Цитировать
делайте что-ли упрощенные ссылки на уже компилируемый пример

А это мысль. 8) Я как-то про такую возможность не подумал.
Вот: http://coliru.stacked-crooked.com/a/5e8e0c4f76c7cb1a Но в этой системе такое даже не компилируется (вроде бы нигде не опечатался...). :)

Цитировать
Все это компилятору не нравится

Тут проблема веселее, как мне кажется. Вообще, обычно принято делать поведение системы предсказуемым и ожидаемым. В данном случае компилятор себя так не ведёт. Я вполне чётко ему обозначил, что я желаю унаследовать два класса (CErrorsACU и CErrorsAcs) и чтобы каждый из них мог вызывать определённую в их суперклассе (CErrorsBased) и переопределённую в их потомке (CErrors) функцию. Для этого я указал компилятору, что желаю иметь указатель на функцию потомка CErrors. Я ожидаю, что функция, на которую сделан указатель, пусть и определена в классе CErrorsAcs, но была унаследована CErrors и отныне она принадлежит именно ему. Вроде бы достаточно понятное и простое желание. Поэтому я никак не ожидаю от компилятора перенаправления вызова этой функции в класс CErrorsAcs с последующей потерей связи с его потомком CErrors. Всё-таки, какая мне разница, что за проблемы возникают при этом у компилятора?  >:(

Цитировать
Вообще на первый взгляд - вот так кот путать пользователя передачей обработчиков методов разного уровня наследования .. в данной реализации мне показалась сомнительной.

Да там всё просто. Был класс, в котором была куча функций типа "Включить ошибку устройства ..." и "А включена ли ошибка устройства ... ?". Эти функции записывали/считывали флаги большой структуры, которая через разделяемую память передавалась процессам имитации этих устройств. Но на этапе реализации оказалось, что этих функций будет пара сотен. Не, так неудобно. Поэтому я выделил устройства в классы с их функциями и хотел чтобы все те же их функции были просто унаследованы исходным классом. Дальше встал вопрос сделать триггерную функцию "если включено, то выключить, иначе включить". Я это сделал через указатели на функции этого класса. Тут-то компилятор и возопил. :)

Цитировать
объекты/переменные - чем отличаются в вашем контексте?

Тем, что для объектов вызывается конструктор, а переменные просто инициализируются из секций исполняемого файла.
То есть,
char name[]="123"; - инициализируется из секции .data
CErrors cErrors; - инициализируется вызовом конструктора.

Меня интересовал вопрос, инициализируются ли классы строго после все простых типов. Судя по тому, что написано, да.


Название: Re: CppUnit порт для QNX6
Отправлено: lastcross от Октября 20, 2018, 03:31:59 am
Цитировать
Тут проблема веселее, как мне кажется. Вообще, обычно принято делать поведение системы предсказуемым и ожидаемым.
А давайте посмотрим, что может значить запись :
Код:
typedef (CErrors::*set_function_ptr)(uint32_t,bool);
- это синоним set_function_ptr на указатель функции с сигнатурой (uint32_t,bool). При этом мы явно говорим, что метод должен принадлежать классу (не иметь дополнительных каких либо смещений при ссылке на метод). Вот ваш же пример (http://coliru.stacked-crooked.com/a/c45660bee346965f) - в нем добавлен не виртуальный метод doSome() в базовые классы. В мэйне вызывается конкретные методы объекта cErrors. Но нет никакой возможности вызывать непосредственно этот метод без указания типа (смещения) конкретного базового класса. Да, если методы не пересекаются по имени/сигнатуре - это очевидная ошибка компиляции отловить не получится. Но это только потому что мы явно вызываем методы и компилятор точно может определить наши намерения. В вашем случае - вы переводите все в рантайм. Компилятор не сможет различить полную сигнатуру (а именно именную сигнатуру) к каким методам будет применен вызов (на уровне  CErrors::ChangeState - это неизвестно). Он затрудняется гарантировать точные ваши намерения и принимает очевидное решение - сгенерировать ошибку компиляции. Гарантировано он может обеспечить работу только для собственных методов принадлежащих к CErrors (в примере это метод SetError)


Цитировать
Тем, что для объектов вызывается конструктор, а переменные просто инициализируются из секций исполняемого файла.
То есть,
char name[]="123"; - инициализируется из секции .data
CErrors cErrors; - инициализируется вызовом конструктора.

Меня интересовал вопрос, инициализируются ли классы строго после все простых типов. Судя по тому, что написано, да.
Нет, вы не совсем все верно поняли. В описании разделены - константная статическая инициализация и .. другие типы статической инициализации. И в вашем случае порядок инициализации будет в порядке их перечисления. "123" будет лежать где-то в .data как некий литерал, но сам name будет инициализироваться в любом случае в процессе выполнения и раньше  чем cErrors. И наличие конструктора - тут не причем.


Название: Re: CppUnit порт для QNX6
Отправлено: da-nie от Октября 20, 2018, 08:54:37 am
Цитировать
метод должен принадлежать классу (не иметь дополнительных каких либо смещений при ссылке на метод)

Про смещения - это уже проблема компилятора, как он будет искать этот метод. Если я вставил дверь в дом, отныне ручка двери принадлежит дому точно так же, как и двери. Это уже пусть сам компилятор ищет, где там этот метод у кого лежит. И жаль, что он такого не умеет.

Цитировать
Но нет никакой возможности вызывать непосредственно этот метод без указания типа (смещения) конкретного базового класса.

Правильно. В данном случае есть неопределённость и требуется указание, чей именно метод мы вызываем.

Цитировать
Компилятор не сможет различить полную сигнатуру (а именно именную сигнатуру) к каким методам будет применен вызов (на уровне  CErrors::ChangeState - это неизвестно). Он затрудняется гарантировать точные ваши намерения и принимает очевидное решение - сгенерировать ошибку компиляции. Гарантировано он может обеспечить работу только для собственных методов принадлежащих к CErrors (в примере это метод SetError)

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

Цитировать
И наличие конструктора - тут не причем.

Нет-нет, тут другой вопрос был. Итак, у нас есть два модуля.
В первом в *.h объявлен класс CErrors и в *.cpp написано так:

//глобальная переменная
char name[]="123";
//конструктор
CErrors::CErrors(void)
{
 printf("%s\r\n",name);
}

Во втором в *.h объявлен класс CMain и в *.cpp написано так:
//глобальная переменная
CMain cMain;
//конструктор
CMain::CMain(void)
{
 printf("CMain!\r\n");
 CErrors *cErrors_Ptr=new CErrors();
 delete(cErrors_Ptr);
}

Модули разные, поэтому порядок инициализации между ними произвольный. Пусть CMain инициализируется первым. Вопрос был в том, будет к этому моменту инициализирована переменная name или нет. Если name задать как std::string, то точно гарантий нет. А вот если задать массивом, то получается, что да.