C++ middleware with GUI in C
-
Hi, I am new to this forum but i hope i am at the right place. I am working on a project which has to be upgraded from the base project written in C++. We have decided to use emwin from segger as GUI which is written in C. The big heck is we have our base project middle ware still in C++. Please suggest me whether its a wise idea to keep middleware in C++ and go ahead with GUI in C. The GUI library is written with Extern C so we will not have problem calling the library function. But how can we get the data from C++ middleware application. Thanks Om
-
Hi, I am new to this forum but i hope i am at the right place. I am working on a project which has to be upgraded from the base project written in C++. We have decided to use emwin from segger as GUI which is written in C. The big heck is we have our base project middle ware still in C++. Please suggest me whether its a wise idea to keep middleware in C++ and go ahead with GUI in C. The GUI library is written with Extern C so we will not have problem calling the library function. But how can we get the data from C++ middleware application. Thanks Om
[Here] is a good place to start.
-
Hi, I am new to this forum but i hope i am at the right place. I am working on a project which has to be upgraded from the base project written in C++. We have decided to use emwin from segger as GUI which is written in C. The big heck is we have our base project middle ware still in C++. Please suggest me whether its a wise idea to keep middleware in C++ and go ahead with GUI in C. The GUI library is written with Extern C so we will not have problem calling the library function. But how can we get the data from C++ middleware application. Thanks Om
Member 8399769 wrote:
But how can we get the data from C++ middleware application.
This question is not clear, what data, where is it held and where is it going? On a more basic point there is no problem using C-based libraries from C++ programs; after all the entire Windows API, including the GDI section, is written in C and used extensively from C++ programs.
One of these days I'm going to think of a really clever signature.
-
Hi, I am new to this forum but i hope i am at the right place. I am working on a project which has to be upgraded from the base project written in C++. We have decided to use emwin from segger as GUI which is written in C. The big heck is we have our base project middle ware still in C++. Please suggest me whether its a wise idea to keep middleware in C++ and go ahead with GUI in C. The GUI library is written with Extern C so we will not have problem calling the library function. But how can we get the data from C++ middleware application. Thanks Om
What i would do first is create wrapper classes around the C widgets. and use C++ from then on... wrapping will take a bit more time to develop but it will be worth the effort since then on you can use the wrapper classes not only in the particular but any other project after that..
-
Member 8399769 wrote:
But how can we get the data from C++ middleware application.
This question is not clear, what data, where is it held and where is it going? On a more basic point there is no problem using C-based libraries from C++ programs; after all the entire Windows API, including the GDI section, is written in C and used extensively from C++ programs.
One of these days I'm going to think of a really clever signature.
Thanks for the response. My question was any body can provide some sample code in C++ from where we can access GUI which is written in c. I have GUI button click call back function also written in c language itself. how can we pass that to a c++ application.?
-
Hi, I am new to this forum but i hope i am at the right place. I am working on a project which has to be upgraded from the base project written in C++. We have decided to use emwin from segger as GUI which is written in C. The big heck is we have our base project middle ware still in C++. Please suggest me whether its a wise idea to keep middleware in C++ and go ahead with GUI in C. The GUI library is written with Extern C so we will not have problem calling the library function. But how can we get the data from C++ middleware application. Thanks Om
-
Thanks for the response. My question was any body can provide some sample code in C++ from where we can access GUI which is written in c. I have GUI button click call back function also written in c language itself. how can we pass that to a c++ application.?
Member 8399769 wrote:
some sample code in C++ from where we can access GUI which is written in c.
How can we provide sample code to a GUI that we do not have? Use the documentation for your library to access the various functions that you are using.
Member 8399769 wrote:
I have GUI button click call back function also written in c language itself. how can we pass that to a c++ application.?
The same way you would pass it to a C function. The syntax for both languages is exactly the same.
One of these days I'm going to think of a really clever signature.
-
Hi, I am new to this forum but i hope i am at the right place. I am working on a project which has to be upgraded from the base project written in C++. We have decided to use emwin from segger as GUI which is written in C. The big heck is we have our base project middle ware still in C++. Please suggest me whether its a wise idea to keep middleware in C++ and go ahead with GUI in C. The GUI library is written with Extern C so we will not have problem calling the library function. But how can we get the data from C++ middleware application. Thanks Om
I tend to find that microcontroller guys are usually gravitating towards C from C++ and I feel something like that in your words. Rewriting a project from C++ to C is usually a downgrade especially in terms of software design if you don't have a strong reason to do that. I was also skeptic about c++ for a long time (I came from assembly, and C, pascal) but believe me that C++ allows you to write much more easy to maintain/clear and bug free code than C. Many ppl think that the only way to communicate between C and C++ compilation units is by calling from C++ to C. This is not true. You can put a function into a cpp file and can declare it as extern "C". In this calse you can call this C++ function from a C file but you can't use C++ types in the function declaration (like bool or pointers/refs to C++ classes), but inside the function body you can use pure C++ with classes/templates... My advice: If you have an option to choose a C++ gui library than choose that and continue writing the project in C++. If you want to go on with your current C library then you should create wrapper classes around the stuff your gui has (buttons, editboxes, labels, dialogs, etc...) and then go on writing the project in C++ and use the gui library as C++ through its wrapper classes. Any more questions? :-)
-
I tend to find that microcontroller guys are usually gravitating towards C from C++ and I feel something like that in your words. Rewriting a project from C++ to C is usually a downgrade especially in terms of software design if you don't have a strong reason to do that. I was also skeptic about c++ for a long time (I came from assembly, and C, pascal) but believe me that C++ allows you to write much more easy to maintain/clear and bug free code than C. Many ppl think that the only way to communicate between C and C++ compilation units is by calling from C++ to C. This is not true. You can put a function into a cpp file and can declare it as extern "C". In this calse you can call this C++ function from a C file but you can't use C++ types in the function declaration (like bool or pointers/refs to C++ classes), but inside the function body you can use pure C++ with classes/templates... My advice: If you have an option to choose a C++ gui library than choose that and continue writing the project in C++. If you want to go on with your current C library then you should create wrapper classes around the stuff your gui has (buttons, editboxes, labels, dialogs, etc...) and then go on writing the project in C++ and use the gui library as C++ through its wrapper classes. Any more questions? :-)
Thanks a ton :)really useful stuffs. One more thing if i use wrapper around c code to use in c++ then do we encounter any performance issue? as we will not have direct call to function we increase the code by adding one more wrapper call.
-
Thanks a ton :)really useful stuffs. One more thing if i use wrapper around c code to use in c++ then do we encounter any performance issue? as we will not have direct call to function we increase the code by adding one more wrapper call.
Of course everything has a cost, but does an extra function call count that much in a GUI? The more intensive parts (gui update, draw, ...) are still doing the work in the C layer. What you do through the C++ layer is basically the setup of the gui, and receiving events. These don't happen often. I always say that first keep the project clean and easy to maintain by keeping software design nice and clean, this can not be accomplished without object oriented design in a huge codebase (lets say few hundred thousads LOC). After this if you have performance issues lets start profiling and spot out the most critical parts and start fixing those until you get reasonably good performance. Optimization sometimes results in hard to understand code, if you write the whole code focusing on optimization then your whole code becomes a mess, and often the result is bad performance!!! surprise!!! The 2 most common reasons of performance issues are: algorhitmic problems, hardware related issues (often cache misses). The latter can be caused by a lot of other things: order of execution of subsystems, bad multithreading, ... Of course if you have a very low end hardware you might want to save every piece of cycle, but even in that case I would consider whether it worth sacrificing good software design for a small performance impact... Not to mention that some good compilers can optimize out (inline) such small wrapper function calls (link time code generation in VC++). The long and short of it is: make smart design decisions and dont overoptimize at the beginning if you dont have a good reason to do so. Performance problems come last usually from unexpected spots of your codebase.