|
Thanks Albert,
hereafter i will use this page to ask questions related.
Regards,
A. Gopinath.
|
|
|
|
|
With some algorithm you should pick 2 points that are far enough from each other. After this you can create a line object using these 2 points. The line object can be used to easily determine the distance of the other points from this line and you can accept distances less then a defined epsilon value.
An O(n) algorithm to determine the 2 endpoints (assuming that the points are in a line) before your create the line object:
Initialize an empty bounding AABB and then expand it by adding all points. Declare six point variables and each of them should store the last point that was used to expand the AABB in +x,-x,+y,-y,+z,-z directions (note: the first point should fill all the six variables).
When this is done choose a dimension in which the size of the AABB is the biggest (x, y, or z). If the biggest dimension is zero (or near zero) then all points are located at the same spot.
Lets say its x: in this case the two endpoints (from the previously mentioned 6 point variables) are the points that were stored when the AABB was expanded last time in -x and +x directions.
|
|
|
|
|
That it's simple: if all the points are on a straight line then use two of them to compute the straight line equation.
Once you have such equation, test if the other points lie on the line too.
Veni, vidi, vici.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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..
|
|
|
|
|
For wrapping C header files into C++ you do this:
#ifdef __cplusplus
extern "C" {
#endif
#ifdef __cplusplus
}
#endif
#endif
More extern "C" [here] and [here].
[List] of GUI libraries.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
Hi i have a program to do with ray casting and i am really struggling tryng to code the void view::RayCast function. I have covered the code with comments to help you understand the code, I have looked all oevr the web for help but no success. If there is anyone that is capable of doing this, it would mean the world to me
void view::RayCast( float fRayStartX, float fRayStartY, unsigned int uViewingAngle )
{
float fDX, fDY;
int nGridX = 0;
int nGridY = 0;
int nTextIndex = 0;
unsigned int nColumnAngle = m_nViewColAngStart;
for (int nColumn = 0; nColumn < m_nViewWidth; nColumn++)
{
if (nColumnAngle == 0) { nColumnAngle++; }
float fRayX = fRayStartX;
float fRayY = fRayStartY;
while( true )
{
float fXCrossX, fXCrossY;
float fYCrossX, fYCrossY;
double dXDistSq = 0.0;
double dYDistSq = 0.0;
if (dXDistSq < dYDistSq) {
if ( m_pViewWorld->m_pWorldTextures[nGridX][nGridY] != NULL)
break;
} else {
if ( m_pViewWorld->m_pWorldTextures[nGridX][nGridY] != NULL)
break;
}
}
|
|
|
|
|
Did you mean to ask some sort of a question and then forgot?
Why is common sense not common?
Never argue with an idiot. They will drag you down to their level where they are an expert.
Sometimes it takes a lot of work to be lazy
Please stand in front of my pistol, smile and wait for the flash - JSOP 2012
|
|
|
|
|
Here's a good [tutorial] about raycasting.
|
|
|
|
|
I have got the following in a header file for a class:
#include <vector>
#include <math.h>
In the class description, I have the following protected member:
vector<Point2D> samples;
Point2D is defined as a class
during compile time I get lots of errors (C2143, C4430 and C2238)
Any ideas?
|
|
|
|
|
Try
std::vector<Point2D> samples;
whenever you use a vector in a header file, you should include the std:: prefix.
What the errors mean. (C2143, C4430 and C2238)
error C2143: syntax error : missing ';' before '<'
error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
error C2238: unexpected token(s) preceding ';'
modified 6-Aug-12 13:50pm.
|
|
|
|
|
Make sure the file where you defined this vector also knows that Point2D is a class. So don't forget to include the header where the class is defined within this file. That may be your problem...
|
|
|
|
|
How to ensure the file which I download and the file on the server is the same one?How can I get the file's MD5 value or CRC value before I download it?If file server give this value to me.Will it make the file server too much pressure?(forgive my bad english)
|
|
|
|
|
Both protocols have their advantages but I think http is more modern and often better. I also favor http because I often build in cgi scripts to perform certain tasks on the server side.
About the CRC: None of these protocols support getting crc. I would use the file time to check if the files are up to date on the client or not. With http you can use HEAD requests to get only the head part of a full request without data, that contains the filetime, size, etc... If you can put in cgi scripts into your http server then you can build in a crc calculator/getter cgi but I think putting heavy load on the server is generally a bad idea. In ftp I don't know if getting crc is possible but my guess is no.
modified 6-Aug-12 10:47am.
|
|
|
|
|
Thanks a lot,now I solved this problem.The file is uploaded by java in web service and a crc32 value is
calculated after that.I juust send a message to server.It get me the value.So I know this value.I download the file,calculate the file's crc32 value.At last,I compare two crc32 values.
|
|
|
|
|
All well that ends well. Forgot to mention that you can solve it easily with pure HTTP + cgi script as well. If you have the crc3 values precalculated on your sever lets say in x.txt.crc32 for x.txt then the cgi script could handle HEAD requests and it could send a response back to the client that has a custom response header like crc32=blahblah. But its OK if you found a similar solution, java web containers are quite flexible if you used tomcat or something like that...
|
|
|
|
|
[This] is an informative read on FTP vs. HTTP.
|
|
|
|
|
Nice fight between FTP vs HTTP.
I would remove the 'Never chunked encoding "overhead"' point from the list of advantages of FTP because the chunked encoding is a feature of HTTP that shouldn't be used in case of fixed sized files - and usually it isn't used at all in such cases. On the other hand some problems - like streaming an unknown sized log file incrementally (one that isn't closed and finished yet) can only be solved with chunked encoding. So it is a feature that is overhead only if abused.
|
|
|
|
|
Another 2 things I like more in HTTP:
1. It uses just one connection, while FTP uses separate command/data channels.
2. HTTP is usually less bothersome when it comes to firewalls.
|
|
|
|