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
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.
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.
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.