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
Any sane implementation should support '/' to allow compatible transfer of source code.
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.
"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...
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?!