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
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
No, it isn't Erik.
Keil and IAR may have different extensions for processor-specific functionality.
But they would still implement their compilers based on "normal behavior" for compilers intended to be run in the Windows environment. They don't make a compiler who don't care about paths directly in the #include statements. They don't make a compiler who don't take command-line parameters but just accepts environment variables.
Much of what we do, and how we do it, is because of de facto standards. Not enforced standards, but still "expected" behavior that affects how a customer will respond to a product.
Products tends to differentiate themselves with extension functionality. Not with lack of functionality.
"write PC code for embedded" has nothing to do with availability of path information in #include statements. When writing code for an embedded platform, it should normally only be relevant if "fopen()" in the target program may use path information nor not. And embedded platforms big enough that you run the compiler tools directly on the embedded platform are normally very capable.
Nobody is disputing that.
The point is that a sane implementation wouldn't deliberately make life difficult by failing to recognise '/' in path names on DOS/Win.
Then again, this wouldn't be the only thing that has ever caused anyone to question the sanity of an implementation...
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.
That particular accomplishment is a trivial NOP anyway, because at the system call level, neither DOS nor Windows cares whether you spell paths with '/' or '\'. They're totally interchangeable.
One compiler normally gets the spot as "reference" for a specific platform. Then the other compilers follows suite.
Per, I'm afraid we misunderstood each other.
You're silently assuming that code will only be moved among compilers for the same platform (and BTW, is that the build or target platform?), while I also try to keep the possibility in mind that it might have to be moved to a totally different set of build and target platforms, so compatibility reference compilers for a particular platform might be sufficient.
Because of this, you were pointing out requirements that the implementation is supposed to fulfill to be qualified sane, while 'm trying to point out that it's in the hands of the <p>programmer wether he would be hurt if the implementation failed that sanity check.
The trick is not to put paths into #include directives in the first place. A '/' or '\' separator that was never put into the directive cannot be mis-handled, even by an arguably insane implementation.
No. That does not sound right.
Shame on you. The word trick in a description of coding techniques?!