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.
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.
I didn't know about that. If it doesn't violate standard behaviour, it at least violates my expectations.
I suppose the effect would be quite violent if I were using regular expressions. Which is not really relevant on a µC, but in a regular C program I wouldn't want to do without them.
But almost anyone writing a #include with "..\.." in it, is likely to get hurt when they another day have "\bios" or "\network" or similar, and ends up with one of the C escape sequence replacements instead.
So use of a single "\" in an #include on the MS-DOS/Windows platform have caught lots of developers. And probably a number of people on other platforms too.
But both "\" and "\\" ends up in language standard texts either claiming "undefined" or "conditionally supported". While "/" is almost always supported even if the language standard doesn't require it. But "/" is part of POSIX.
POSIX is a good example why standards are less relevant than user expectations.
There's no sane fix for this, the error was using \ as a path delimiter. Because it already was established as the escape character in all computing environments.
Most C/C++ developers on Windows/.NET I know, also use / as a path delimiter in their code.
Was it?
I would say \ had a much weaker standing 1983 when MS-DOS 2.0 with directory support was relased than it has now for use as break character.
And / were used in MS-DOS 1.0 to specify a command line parameter.
View all questions in Keil forum