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
"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.
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?!