legotron

why? :blink: Вот нормально работающий кусок... проверено. U16 TEMFClass::EMF_ScanRecords(const U8 * PData, U16 Size) { ENHMETAHEADER * MainHeader; EMR * Header; int i; if(PData != NULL) { MainHeader = (ENHMETAHEADER *)PData; // вот тут Header = (EMR *)PData; for(i=0; i<MainHeader->nRecords; i++) // тут обращение к полю { //EMF_LUT.AddItem(Header); //EMF_LUT.CountItems(); #if DEBUG printf ("#%d - addr: %p value: %d \n",i,Header,Header->iType); #endif Header = (EMR *)((U8 *)Header + Header->nSize); } return 0; } else return 1; }

Б.Р.Е.Д! Ой каюсь-каюсь я был в перегреве, когда писал это сообщение! Лучше поздно чем никогда! Уважаемый dxp писал: "чтобы можно было работать с объектом класса, указатель на него должен "знать" о строении (структуре) класса." тут Также и со структурой: struct A {...}a; int * Ptr; struct A * Ptr2; Ptr = (struct A *)&a; // сделать можно (и даже 1 поле структуры можно получить, если типы совпадут) :)))) Ptr->(поле); // так сделать нельзя (будет ругаться компилятор) Ptr2 = &a; // всё тип-топ Ptr2->(поле); // анологично

Я делал когда-то таким образом: Был массив, который представлял собой файл EMF формата. Там структуры записаны. У меня было несколько разных типов структур и 1 указатель, который я каждый раз приводил к типу той структуры, которая мне нужна. И получал доступ к их полям. Тока с упаковкой структур (надо/ненадо) нужно быть внимательнее.

Проблема есть. :( Теперь по порядку: IDE/компилятор: Keil 166 EC++. Проц Infineon XC167. List.h... template <class T> class TList { struct _SList { T * item; struct _SList * next; struct _SList * prev; }; typedef struct _SList SList; public: SList * base; SList * NewItem; TList(void) {base = NULL; NewItem = NULL;}; void AddItem(T * PRec); U16 CountItems(void); }; List.cpp... #include <stdio.h> /* standard I/O .h-file */ #include <stdlib.h> #include <intrins.h> #include <absacc.h> // Absolute Memory Access #include "main.h" #include "gl.h" #include "ec_error.h" #include "Graph.h" #include "List.h" //------------------------------------------------------------------------------ template <class T> void TList<T>::AddItem(T * PRec) { SList * Current; if(base != NULL) { Current = base; while(Current->next != NULL) Current = Current->next; NewItem = new SList; Current->next = NewItem; NewItem->next = NULL; NewItem->prev = Current; NewItem->item = PRec; } else { base = new SList; base->next = NULL; base->prev = NULL; base->item = PRec; } } //------------------------------------------------------------------------------ template <class T> U16 TList<T>::CountItems(void) { U16 i = 0; SList * Current; if(base != NULL) { Current = base; while(Current->next != NULL) { Current = Current->next; i++; } } return i; } //------------------------------------------------------------------------------ Test.cpp... void Test(void) { U16 cnt; TList<U16> A; cnt = A.CountItems(); // Без этой строчки никаких ошибок вообще нет! } P.S. Если ф-ции члены класса делать inline внутри класса - ошибок тоже нет Вот, если не затруднит гляньте плз :)

Да правильно, имелось ввиду АObj! :) Но ошибка не в этом! Это я накосячил во время составления поста. В проекте у меня совсем все подругому названо... Я для простоты переделал в А, B, C.

Добрый день! Помогите разобраться в чем ошибка? Код следующий... template <class T> class A { public: void Func(); }; template <class T> void A<T>::Func() { } void TestTemplate(void) { A<int> AObj; // Создаем объект тип А для int AObj.Func(); // Эта строка приводит к ошибке линкера (исправил было A вместо AObj) :) } Этот код компилирутся без ошибок. Ошибка возникает на этапе ликовки... *** ERROR L127: UNRESOLVED EXTERNAL SYMBOL SYMBOL: Func__12SAS__tm__2_cFv_v MODULE: EMF.obj (EMF) *** ERROR L128: REFERENCE MADE TO UNRESOLVED EXTERNAL SYMBOL: Func__12SAS__tm__2_cFv_v MODULE: EMF.obj (EMF) ADDRESS: 16E8H Target not created Какие есть соображения по этому поводу?

Да безусловно эти вещи потенциально опасны! Но как мне кажется, с ними порой получается изящней. А то ведь строгое соответствие типов - это Паскаль. Там компилятор 100 раз обругает, чтобы ни-ни... Ну, ничего не попишеш - дисциплина важная вешь! :) Думаю, что я еще ни разу хорошенько не погорел на этом, поэтому люблю поизящнее. А мастерство, это когда практично! :) Спасибо за ценный совет, я думаю, что шаблоны это как раз то, что мне надо!

Абсолютно с вами согласен. Но всё-таки можно и switch - case конструкцией обойтись(в некоторых случаях). Хотя по сравнению с механизмом полиморфизма она кажется несовершенной. Неболшой оффтопик: У меня возник такой вопрос: Есть класс А. Он наследутся классом В. В обеих классах есть виртуальная функция Draw. class A { ... virtual void Draw(); ... }; class B : public A { ... virtual void Draw(); ... }; A *PObjA; // указатель на базовый класс B ObjB; // Создан объект класса В void * Ptr; Ptr = (A *)PObjA; // может лишнее Ptr = &ObjB; Ptr->Draw(); // будет ли вызвана ф-ция Draw класса В? Можно ли вообще так сделать? Этот вопрос возник из желания сделать универсальный связанный список с полем Item типа void * для любых объектов? :)

Прошу прощения, что вклиниваюсь в столь жаркую дискуссию! :) Каков смысл статических функций класса? Зачем их следует использовать?

Микроконтроллеры бывают разные! :) Не хочу поднимать тему сравнения микроконтроллеров и микропроцессоров, но какая разница между вашим домашним компьютером и МК? Непроизводительные издержки С++ в основном в виртуальном механизме. Мощный МК их способен с лихвой покрыть!

ПЛИС необходим для того, чтобы снять с проца задачи, связанные с непосредственным показом изображения. Это приведет к стабильному показу изображения(без мерцаний). Но тем не менее, проц все равно не следует брать слабым. Иначе будут всяческие зависания показа одного и того же кадра.

Вы правы TString на PC имеет несколько другой смысл и в действительности не связан с выводом на экран. Я же думал этот класс заточить под вывод, с виртуальными методами родителей типа MoveTO(для бегущей строки) и.т.д. Но вот настройка самого шрифта(тип, размер...) как-то не вяжется с классовой структурой рисования. Насчет С++Builder, я думаю так: В нем реализованы классы, которые в качестве методов используют функции Win32API, а этот интерфейс не объектный. Вот если бы он был объектным - мне бы оттуда структуру тянуть стоило-бы. А BCB - надстройка. Насколько мне помнится(я имел раньше дело с BCB), в нем с TObject пляшут в смысле графики. Но все-же, в BCB глянуть стоит конечно...

Добрый день! Я занимаюсь написанием графического интерфейса для LCD монитора на 16-разрядном микроконтроллере XC167. Для графики пытаюсь использовать ООП. Опыт работы с ООП совсем небольшой. У меня есть некоторые недопонимания с построением иерархии классов. Например, хотелось бы создать класс TFont. От него наследовать TChar (все что касается отображения символов). Далее от TChar - TString. Но с другой стороны рисования символа состоит из рисования точек. А все, что связано с точками (Line, Circle ...) растет от класса TPoint. Как тут быть? Ведь TFont совсем не связан логически с TPoint (как мне кажется). Использовать множественное наследование? пересмотреть TFont - TChar? Отказаться от связи TChar с классами иерархии TPoint? Пожалуйста пролейте свет на этот вопрос. P.S. Не могли бы вы посоветовать мне какие-нибудь книги или статьи с жизненными примерами ООП. А то, в основном, все примеры которые мне попадались какие-то слишком академичные. Заранее благодарен! :)

Как сказать?...Может я просто не задумывался глубоко при написании объектных программ для ПК. У Keilа по поводу объектного компилятора EC++ написано, что он является надстройкой над С-шным компилером. Т.е. как я понял (может неправильно) что он просто С++ код в итоге преобразует в С-код с последующей С-компиляцией? Еще с 1 проблемой столкнулся: пытаюсь в свой проект вставить .СPP файлы. Компилятся нормально, непонятные ошибки при линковке. Посмотрел в Tutorial-проекты там вообще вместо main() - ECMain(). Это обязательно вообще? Резюме: Посмотрел на версии С и С++ компилеров. На сегодняшний день у С версия 6.08, а у C++ 1.09. Мне кажется слабенький у них пока С++ - много самим дадумывать надо будет :)

Добрый день! У меня возникла задачка: писать мне испльзуя ООП подход или нет? Может ли кто-нибудь дать мне рекомендации? Процессор у меня XC167 Infineon 16-bit. Компилятор Keil 166. Задача создать графический интерфейс с LCD. Контроллер LCD реализован на ПЛИС. То, что драйвер, взаимодействующий с ПЛИС лучше писать на ассемблере у меня вопросов не возникает. А вот точки, линии, и другие графические объекты мне кажется элегантнее было бы написать используя мощь полиморфизма. Конечно сами алгоритмы отрисовки (Брезенхейм и.т.д) я расчитываю тоже писать на ассемблере или С. Но как насчет embedded С++ для объектов посложнее. Как использование С++ отразится на скорости/лаконичности программы? У кого-нибудь есть опыт работы с этим делом? Не могли бы вы посоветовать мне что-нибудь почитать по embedded C++? Все советы приветствуются! :) P.S. uC-GUI могло бы очень помочь, но в моем случае для использования этой штуковины нужно будет перелопатить её драйвер. Немного с ней покопавшись, я пришел к выводу что это для меня сложновато :(

Премного благодарен! Такая штука сразу снимает все возникшие вопросы.

Добрый вечер. Проц: XC167 Монитор: 320х240 цвет. LCD драйвер: на ПЛИС uC-GUI исползовать не собираюсь. Подскажите, как лучше реализовать шрифты: растр/вектор? Может у кого есть хотя бы uC-GUI-FontConvert не Demo

Может быть, но поиском по словам линковка, линк, и.т.д. и.т.п. ничего дельного не нашел. (скажу честно, глубоко не искал). Для себя я варианты процесса внедрения бинарника уяснил. Мне не дает покоя еще 1 возможный вариант - т.е. присоединение файла прямо линкером(или еще чем-то). Потому я и задал вопрос к знатокам процесса компиляции. Хотелось бы поподробнее узнать этот процесс со всеми входны/выходными расширениями файлов(*.с, *.obj, *.lst, *.hex) Кто чё делает короче? А то может быть это вовсе не задача линкера внедрять бинарник.

Просьба к знатокам: Не могли бы вы пролить свет на процесс компиляции С/С++ кода? Думаю глубокое понимание этого процесса никому не помешает!

С этим безусловно поспорить трудно! Но такие фразы не несут информации, поэтому непойму зачем автор их пишет. По делу-то только ниже! Спасибо за помощь! Собственно разобрался как всегда во всем САМ! Варианты помещения бинарников (BMP, JPG, WAV...e.t.c) в ROM: 1 - Перевод бинарника в текстовый файл (*.с). Есть очень удобная программа HEX editor для такой цели, сама все приводит к виду константного массива (и думать не надо) 2 - Перевод бинарника в HEX утилитой BIN2HEX от Keil. Далее возможны варианты: а Соединить этот HEX c програмным hex-ом, затем зашить. б Залить этот HEX в оперативку через Debuger, затем произвести заливку в ROM. Если имеются еще варианты - дополняйте!

Друзья, помогите плз, куда копать? У меня Keil 166. Я хочу поместить любой бинарный файл с компа в итоговый HEX(во флэш как константу). Это вообще возможно? Если да то КАК? Любые обсуждения приветствуются... :)

Для справки, как я понял: Флэшка может быть перезаписана более 20000 раз, но при этом гарантийный срок сохранения данных сокращается до 5 лет! Если нужно, чтобы хранилось 15 лет не стоит перезаписывать более 1000 раз. Спасибо Shandy... Для меня это весьма полезная информация - буду переходить на RAM debug.

Нельзя ли уточнить какой именно этот ресурс, и желательно привести источник откуда эта цифра взята?

:( что-то ссылочка не работает Может у кто-нибудь скинет crack для Keil (желательно под c166v606), хотя кидайте любую!