Asp Forum - AutoCad 2006 - microsoft.public.dotnet.framework.aspnet.caching

tobiectz

12/4/2009 8:48:00 PM

can u plz find me d activation code for following
Request code is: Q3DN DW5A AFAT NH61 00HC
KJSY KP37
serial no: 343-05147881
plz i need it urgently...
Thanks

11 Answers

Keith Thompson

10/20/2009 7:20:00 PM

Eric Sosman <Eric.Sosman@sun.com> writes:
> Francois Grieu wrote:
>> Is the following program correct?
>>
>> /* SOF on this line 1 */
>> #ifndef TABLE
>> char *gStr[] = {
>> #define TABLE( str, num1, num2 ) str,
>> #include __FILE__
>
> Sneaky, but I think there are at least two potential problems:
>
> First, the mapping of __FILE__'s expansion to a header file name
> is implementation-defined (6.10.2p4). So even if __FILE__ expands
> to "foobar.h" it is not necessarily the case that #include __FILE__
> and #include "foobar.h" work identically.
>
> Second, the expansion of __FILE__ is only the "presumed" name of
> the current source (6.10.8p1). A footnote suggests that "presumed"
> is an allowance for #line directives, but there's also the possibility
> that the source has no name, or no useful name. I recall a compiler
> that could store headers in a "library file" containing individual
> "members;" the library was a file and had a name, but the headers
> themselves were not files and didn't have file names; __FILE__ in
> such a header expanded to the concatenation of the library name and
> the header name, like "HEADERS.TLB(FOOBAR)" for "foobar.h" found in
> the HEADERS.TLB library.
>
> So: Sneaky, cute, even ingenious, but ...

One of the winners of the 1988 IOCCC was the following entry by
Diomidis Spinellis:

#include "/dev/tty"

The point being that #include on the same name won't necessarily
give you the same content twice in a row.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.ne...
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Tim Rentsch

10/20/2009 7:46:00 PM

Eric Sosman <Eric.Sosman@sun.com> writes:

> Francois Grieu wrote:
>> Is the following program correct?
>>
>> /* SOF on this line 1 */
>> #ifndef TABLE
>> char *gStr[] = {
>> #define TABLE( str, num1, num2 ) str,
>> #include __FILE__
>
> Sneaky, but I think there are at least two potential problems:
>
> First, the mapping of __FILE__'s expansion to a header file name
> is implementation-defined (6.10.2p4). So even if __FILE__ expands
> to "foobar.h" it is not necessarily the case that #include __FILE__
> and #include "foobar.h" work identically.

The provision in 6.10.2p4 doesn't apply. The __FILE__ macro
expands to a character string literal, not to a sequence of
preprocessing tokens with (") characters around it. Thus
it's already a single preprocessing-token, with no need to
have to combine anything to get a header name.

> Second, the expansion of __FILE__ is only the "presumed" name of
> the current source (6.10.8p1). A footnote suggests that "presumed"
> is an allowance for #line directives, but there's also the possibility
> that the source has no name, or no useful name. I recall a compiler
> that could store headers in a "library file" containing individual
> "members;" the library was a file and had a name, but the headers
> themselves were not files and didn't have file names; __FILE__ in
> such a header expanded to the concatenation of the library name and
> the header name, like "HEADERS.TLB(FOOBAR)" for "foobar.h" found in
> the HEADERS.TLB library.

Presumably this concern doesn't apply in this case, where the
source file is created by the programmer and not put into the
compiler's "library file". An implementation that expands a call
on __FILE__ into a name [*] that isn't a name that would work
with #include is arguably already non-conforming, but even if it
were allowed, such an implementation is brain-damaged and should
be avoided like the plague.

[*] assuming the name is "simple", eg, eight alphabetic
characters plus a single alphabetic character extension,
and the name hasn't been changed by a #line directive.

> So: Sneaky, cute, even ingenious, but ...

.... portable only to that subset of C implementations that
are sane.

Francois Grieu

10/20/2009 8:14:00 PM

Eric Sosman a ?crit :
> Francois Grieu wrote:
>> Is the following program correct?
>>
>> /* SOF on this line 1 */
>> #ifndef TABLE
>> char *gStr[] = {
>> #define TABLE( str, num1, num2 ) str,
>> #include __FILE__
>
> Sneaky, but I think there are at least two potential problems:
>
> First, the mapping of __FILE__'s expansion to a header file name
> is implementation-defined (6.10.2p4). So even if __FILE__ expands
> to "foobar.h" it is not necessarily the case that #include __FILE__
> and #include "foobar.h" work identically.
>
> Second, the expansion of __FILE__ is only the "presumed" name of
> the current source (6.10.8p1). A footnote suggests that "presumed"
> is an allowance for #line directives, but there's also the possibility
> that the source has no name, or no useful name. I recall a compiler
> that could store headers in a "library file" containing individual
> "members;" the library was a file and had a name, but the headers
> themselves were not files and didn't have file names; __FILE__ in
> such a header expanded to the concatenation of the library name and
> the header name, like "HEADERS.TLB(FOOBAR)" for "foobar.h" found in
> the HEADERS.TLB library.
>
> So: Sneaky, cute, even ingenious, but ...

OK, I see #include __FILE__ may not properly refer to the
current file; and that maybe there is no current file
(compiling from stdin..)
But, let use assume that I change that to #include "self.c"
and put my source in some file such that #include "self.c"
refers to that file (which is how I actually use this);
or equivalently that, on the system under consideration,
#include __FILE__ does refer to the current file.

Is there something wrong with the fact of including the
current file, and/or a file in the stack of currently
included files?

Francois Grieu

Eric Sosman

10/20/2009 8:47:00 PM

Tim Rentsch wrote:
> Eric Sosman <Eric.Sosman@sun.com> writes:
>
>> Francois Grieu wrote:
>>> Is the following program correct?
>>>
>>> /* SOF on this line 1 */
>>> #ifndef TABLE
>>> char *gStr[] = {
>>> #define TABLE( str, num1, num2 ) str,
>>> #include __FILE__
>> Sneaky, but I think there are at least two potential problems:
>>
>> First, the mapping of __FILE__'s expansion to a header file name
>> is implementation-defined (6.10.2p4). So even if __FILE__ expands
>> to "foobar.h" it is not necessarily the case that #include __FILE__
>> and #include "foobar.h" work identically.
>
> The provision in 6.10.2p4 doesn't apply. The __FILE__ macro
> expands to a character string literal, not to a sequence of
> preprocessing tokens with (") characters around it. Thus
> it's already a single preprocessing-token, with no need to
> have to combine anything to get a header name.

In #include "foobar.h" the stuff after #include is a header-name
preprocessing token, something that is recognized only in #include
directives (6.4.7p3).

In #include __FILE__ the stuff after #include is not a header-
name preprocessing token, but an identifier (6.4.2), a macro name.
Nor is its expansion a header-name, because __FILE__ expands to a
string literal (6.10.8p1). A string literal is not a header-name
(6.4p1, 6.4.5, 6.4.7), so it is necessary to apply some kind of
transformation to the expansion of __FILE__ to make a header-name
out of it. 6.10.2p4 says that the transformation is implementation-
defined.

Besides, if 6.10.2p4 did not apply, #include __FILE__ would be
an error right from the start. Delete 6.10.2p4 from the Standard,
and you're left with #include <foo.h> and #include "bar.h" as the
only two valid forms. #include __FILE__ matches neither.

--
Eric.Sosman@sun.com

Eric Sosman

10/20/2009 8:55:00 PM

Francois Grieu wrote:
> [...]
> But, let use assume that I change that to #include "self.c"
> and put my source in some file such that #include "self.c"
> refers to that file (which is how I actually use this);
> or equivalently that, on the system under consideration,
> #include __FILE__ does refer to the current file.
>
> Is there something wrong with the fact of including the
> current file, and/or a file in the stack of currently
> included files?

Since the Standard doesn't forbid it, "recursive inclusion" is
permitted (subject to whatever nesting limits the implementation
might impose). It's quite common to encounter such inclusions in
projects with a lot of interdependent headers; that's why we
write inclusion guards as

#ifndef FOOBAR
#define FOOBAR
/* payload of foobar.h, with #includes */
#endif

and not as

#ifndef FOOBAR
/* payload of foobar.h, with #includes */
#define FOOBAR
#endif

--
Eric.Sosman@sun.com

Francois Grieu

10/20/2009 9:47:00 PM

in some other sub-thread Eric Sosman wrote:

> In #include __FILE__ the stuff after #include is not a
> header-name preprocessing token, but an identifier (6.4.2),
> a macro name.
> Nor is its expansion a header-name, because __FILE__ expands
> to a string literal (6.10.8p1). A string literal is not a
> header-name (6.4p1, 6.4.5, 6.4.7), so it is necessary to apply
> some kind of transformation to the expansion of __FILE__ to
> make a header-name out of it. 6.10.2p4 says that the
> transformation is implementation-defined.

Which is very bad news for the construct in the subject.

And in this thread Eric Sosman also wrote :
> Francois Grieu wrote:
>> [...]
>> But, let use assume that I change that to #include "self.c"
>> and put my source in some file such that #include "self.c"
>> refers to that file (which is how I actually use this);
>> or equivalently that, on the system under consideration,
>> #include __FILE__ does refer to the current file.
>>
>> Is there something wrong with the fact of including the
>> current file, and/or a file in the stack of currently
>> included files?
>
> Since the Standard doesn't forbid it, "recursive inclusion"
> is permitted (subject to whatever nesting limits the
> implementation might impose).

I was afraid it might not work in practice...

> It's quite common to encounter such inclusions in
> projects with a lot of interdependent headers [...]

But now I stand largely reassured, thanks.

Among the other semi-good reasons I use self-inclusion:

- I need to reformat or transpose a table (like in the
example I gave) that logically belongs to the
implementation of foo rather than to the interface of
foo, and would nicely fit a separate file that we could
#include multiple times, but some local make-like tool,
or coding rule, asks that foo.h contains the interface
to foo.c, and that foo.c include only standard libraries
and interface to C files designed according to that rule.

- I have foo.h that defines a struct, and want to alter it
so that the struct now has a filler to some fixed size at
the end, without hard-coding the size of the filler, nor
defining a macro expanding to the fields of the struct
(which could exceed the standard-mandated expanded-size
limit), nor duplicating the definition of the fields of
the struct, nor putting that struct in a union (because
I do not want to break existing code using foo.h that
refers to struct fields, and many C compiler do not
support anonymous members in unions).

#include __FILE__ would have been especially useful in the
later case, because I can't know it the guy using foo.h
will not put it in some folder and include it like
#include "folder/foo.h"

Francois Grieu

Keith Thompson

10/20/2009 10:12:00 PM

Eric Sosman <Eric.Sosman@sun.com> writes:
> Tim Rentsch wrote:
>> Eric Sosman <Eric.Sosman@sun.com> writes:
>>
>>> Francois Grieu wrote:
>>>> Is the following program correct?
>>>>
>>>> /* SOF on this line 1 */
>>>> #ifndef TABLE
>>>> char *gStr[] = {
>>>> #define TABLE( str, num1, num2 ) str,
>>>> #include __FILE__
>>> Sneaky, but I think there are at least two potential problems:
>>>
>>> First, the mapping of __FILE__'s expansion to a header file name
>>> is implementation-defined (6.10.2p4). So even if __FILE__ expands
>>> to "foobar.h" it is not necessarily the case that #include __FILE__
>>> and #include "foobar.h" work identically.
>>
>> The provision in 6.10.2p4 doesn't apply. The __FILE__ macro
>> expands to a character string literal, not to a sequence of
>> preprocessing tokens with (") characters around it. Thus
>> it's already a single preprocessing-token, with no need to
>> have to combine anything to get a header name.
>
> In #include "foobar.h" the stuff after #include is a header-name
> preprocessing token, something that is recognized only in #include
> directives (6.4.7p3).
>
> In #include __FILE__ the stuff after #include is not a header-
> name preprocessing token, but an identifier (6.4.2), a macro name.
> Nor is its expansion a header-name, because __FILE__ expands to a
> string literal (6.10.8p1). A string literal is not a header-name
> (6.4p1, 6.4.5, 6.4.7), so it is necessary to apply some kind of
> transformation to the expansion of __FILE__ to make a header-name
> out of it.

Right so far.

> 6.10.2p4 says that the transformation is implementation-
> defined.

Actually, 6.10.2p4 says:

The method by which a sequence of preprocessing tokens between a <
and a > preprocessing token pair or a pair of " characters is
combined into a single header name preprocessing token is
implementation-defined.

Since __FILE__ expands to a string literal, we don't have 'a sequence
of preprocessing tokens between ... a pair of " characters'.

It's obviously the intent that a macro expanding to a string literal
is permitted; the footnote:

Note that adjacent string literals are not concatenated into a
single string literal (see the translation phases in 5.1.1.2);
thus, an expansion that results in two string literals is an
invalid directive.

is, in the correct sense of the phrase, "the exception that proves the
rule" (i.e., the explicit statement of the exception implies that
there is a rule to which it is an exception).

C90's rules are the same. K&R1 refers to

#include "filename"

without saying that "filename" is a string literal. (It also doesn't
appear to any form other than #include "filename" or #include
<filename>; that was an invention of the C90 committee.)

> Besides, if 6.10.2p4 did not apply, #include __FILE__ would be
> an error right from the start. Delete 6.10.2p4 from the Standard,
> and you're left with #include <foo.h> and #include "bar.h" as the
> only two valid forms. #include __FILE__ matches neither.

Right.

My guess is that, when the C90 committee decided that "filename"
after #include couldn't be a string literal (allowing, for example,
"a\b.h" to refer to a file without a backspace in its name), but
instead is a double quote followed by a q-char-sequence followed by
another double quote, they didn't quite tidy up the wording 100%
correctly. There may have been a lingering assumption that the
output of the preprocessor is a sequence of characters rather than
of preprocessing tokens. In fact, translation phase 3 produces
a sequence of preprocessing tokens and whitespace characters;
#include directives are processed in phase 4.

I think there just needs to be an additional statement that there's an
implementation-defined mapping of a string literal to header name
preprocessing token. I would hope that this mapping would be required
to be the same as the mapping for an explicit #include "filename"
directive, so that this:

#include "filename"

and this:

#define HEADER "filename"
#include HEADER

are required to be equivalent.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.ne...
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Tim Rentsch

10/21/2009 9:09:00 AM

Tim Rentsch

10/21/2009 9:18:00 AM

Keith Thompson <kst-u@mib.org> writes:

> [ considering cases, eg, #define X "x.h" / #include X ]

> I think there just needs to be an additional statement that there's an
> implementation-defined mapping of a string literal to header name
> preprocessing token. I would hope that this mapping would be required
> to be the same as the mapping for an explicit #include "filename"
> directive, so that this:
>
> #include "filename"
>
> and this:
>
> #define HEADER "filename"
> #include HEADER
>
> are required to be equivalent.

As I explained in my last response, the Standard doesn't require a
header-name preprocessing token in a #include directive. A string
literal (that doesn't have a " in it) preprocessing token matches
the form described in 6.10.2p3, and no additional language is
needed to define what happens in such cases. Arguably the existing
text should be clarified, but at worst it's just unclear, not
incomplete.

Tim Rentsch

10/21/2009 9:27:00 AM

Francois Grieu <fgrieu@gmail.com> writes:

> in some other sub-thread Eric Sosman wrote:
>
>> In #include __FILE__ the stuff after #include is not a
>> header-name preprocessing token, but an identifier (6.4.2),
>> a macro name.
>> Nor is its expansion a header-name, because __FILE__ expands
>> to a string literal (6.10.8p1). A string literal is not a
>> header-name (6.4p1, 6.4.5, 6.4.7), so it is necessary to apply
>> some kind of transformation to the expansion of __FILE__ to
>> make a header-name out of it. 6.10.2p4 says that the
>> transformation is implementation-defined.
>
> Which is very bad news for the construct in the subject.

This analysis is flawed; explanation given in my last
response and last last response in this thread. There
may be problems with finding the right file using
a #include __FILE__, but the point up to where the
search is started is well-defined, not implementation-defined.

microsoft.public.dotnet.framework.aspnet.caching

AutoCad 2006

tobiectz

Keith Thompson

Tim Rentsch

Francois Grieu

Eric Sosman

Eric Sosman

Francois Grieu

Keith Thompson

Tim Rentsch

Tim Rentsch

Tim Rentsch

x Login to ForumsZone