We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Im new to uvision and programming and im looking at a project that has some headers as, #include "..\..\..\swim\lpc_types.h". How do i give it the correct path to the file?..how is "..\..\..\" supposed to define a path?, ive only seen headers included like #include lpc_types.h
It's just the standard notation for a relative path - same as you'd type on a command line.
The question is, of course, relative to what...?
"ive only seen headers included like #include lpc_types.h"
That is also a relative path - it doesn't state what folder and drive to look in.
Of course Keil supports the relative paths for include. When you fill in the Include Paths box, a compiler command-line option -I "xxx" will be added. For an example, if fill as follow:
..;..\..\..\StellarisWare
equals to add command-line options:
-I.. -I..\..\..\StellarisWare
It means include the upper dir of current project, and also include the upper upper upper then \StellarisWare.
It's just the standard notation for a relative path
Do you mean the dots? Because the backslashes don't look that standard to me. I prefer to use forward slashes most of the time.
Because the backslashes don't look that standard to me.
It's a Microsoft thing.
www.teamits.com/.../slashes.html
It's a Microsoft thing
Yes, it is. But the article you are linking to contains some questionable information. Who knows what else is wrong there?
Unix systems, on the other hand, use the forward slash to indicate folder names. Users commonly see this in web site addresses, since the vast majority of web servers run some form of Unix.
Forward slashes in URL's are used because the standard (www.rfc-editor.org/.../rfc1738.txt and other RFC's that supersede it) mandates this. The fact that many web servers run on Unix is just a coincidence.
But the article you are linking to contains some questionable information.
That was just the first think that showed up on my google search as an example.
Really, I was just suggesting that an application designed to operate under a Microsoft operating system (such as the Keil uVision suite) is likely to use the backslash and being surprised of that use is a surprise.
@Mike Kleshov To my limited knowledge, I think Keil toolchains can only run on Windows OS. I never try to run uVision on other OS, so I can't tell... As for backslashes in Dos/Windows, which have been used for years.
Where have you been?!
Every 'C' compiler I've ever used has allowed forward slashes as path element separators - even on DOS/Win systems.
You could use the "proper" back-slashes, but that gets messy - as the backslash is the "escape" character in 'C':
#include <..\\somefolder\\someheader.h>
It seems that we are confusing what's used by the underlying OS (backslashes for DOS/Win; forward slashes for *nix) with what may be used "internally" by applications running on those systems; eg, compilers & webservers.
As the 'C' standard says,
"There shall be an implementation-defined mapping between the delimited sequence [in the #include directive] and the external source file name"
In the case of all the compilers I've used, that "mapping" has included converting forward slashes to backslashes on DOS/Win systems...
Any sane implementation should support '/' to allow compatible transfer of source code.
Then the implementations also normally have support for the native path format. But that is something that we better avoid using.
Forward slashes are fine in the code and you're right "..\.." is the same as "....", which of course doesn't make sense. So using "../.." is more convenient.
However don't use / in the .uvproj files. Instead use a single \ there. That's of course only relevant if you happen to generate parts of the .uvproj from your code, like I do, or manually edit it. µVision accepts / in the .uvproj, but relative includes (even those in the same directory) don't work any more. Took me quite some time to find out.
Should've read the entire thread before posting. That was slightly redundant.
Actually, no. How the character sequence inside the < > or " " of an #include directive maps to an actual file name is implementation defined. What that means is there is no such thing as a compatible tansfer of source code that has any kind of path names in there. The C standard doesn't even assume that the machine the compiler runs on supports the concept of a directory.
The only halfway sane way to deal with this issue is not go anywhere near it. You #include files by their filename only, and leave handling of direcories, drive letters, volumes, URLs (and any other ingenous way of hiding things out of plain sight) to that part of the compilation set-up that is already platform-dependent: the compiler options, environment settings or whatever.
Note that MS-DOS and Windows-based compilers normally handles "..\.." the same as "..\\.." - they look at character following \ and decides if it is one of the standard C break sequences or not.
"Actually, no. How the character sequence inside the < > or " " of an #include directive maps to an actual file name is implementation defined."
Doesn't really matter how implementation defined something is.
One compiler normally gets the spot as "reference" for a specific platform. Then the other compilers follows suite. You don't compete for market shares by making a compiler that spits too much at the competitors code.
"The C standard doesn't even assume that the machine the compiler runs on supports the concept of a directory."
Actually irrelevant, because the developers cares about support for directories or not. So whatever isn't in the language standard still ends up as de facto standards. It's a question of products getting marginalized if not supporting a minimum level of functionality as expected by the customers.
You don't compete for market shares by making a compiler that spits too much at the competitors code.
totally irrelevant except for the morons that think you can write PC code for embedded.
Erik