Must __FILE__ be a narrow string literal?

[xmllmx]

It seems true, but I can't find any exact statement on this in the C
or C++ standard.

The C and C++ standard states:

"__FILE_ The presumed name of the source file (a character string
literal)."

However, what the term "character string literal" means is not exactly
defined. It can be interpreted as a string "C:\\HelloWorld.cpp" or a
wide string L"C:\\HelloWorld.cpp".

So, I think __FILE__ can be interpreted as a wide string by the
implementation, which still conforms to the standard.

Am I right? Any comment?

 

[Gianni Mariani]

It seems true, but I can't find any exact statement on this in the C
or C++ standard.

The C and C++ standard states:

"__FILE_ The presumed name of the source file (a character string
literal)."

However, what the term "character string literal" means is not exactly
defined. It can be interpreted as a string "C:\\HelloWorld.cpp" or a
wide string L"C:\\HelloWorld.cpp".

So, I think __FILE__ can be interpreted as a wide string by the
implementation, which still conforms to the standard.

Am I right? Any comment?

You could do it like so:

#define _CAT(A,B) __CAT(A,B)
#define WSTR(A) _CAT(L,A)

int main()
{
wchar_t x[] = WSTR( __FILE__ );
}

 

[Miguel Guedes]

It seems true, but I can't find any exact statement on this in the C
or C++ standard.

The C and C++ standard states:

"__FILE_ The presumed name of the source file (a character string
literal)."

However, what the term "character string literal" means is not exactly
defined. It can be interpreted as a string "C:\\HelloWorld.cpp" or a
wide string L"C:\\HelloWorld.cpp".

So, I think __FILE__ can be interpreted as a wide string by the
implementation, which still conforms to the standard.

Am I right? Any comment?

__FILE__ holds an ANSI string containing the name of the source file.
I'm not completely sure if this holds true for all platforms but I'm
guessing so.

If you wanted to convert it to wide char format you'd have to do
something like:

#define WSTR2(s) L##s
#define WSTR(s) WSTR2(s)
#define __WFILE__ WSTR(__FILE__)

 

[Alf P. Steinbach]

* xmllmx:

It seems true, but I can't find any exact statement on this in the C
or C++ standard.

The C and C++ standard states:

"__FILE_ The presumed name of the source file (a character string
literal)."

However, what the term "character string literal" means is not exactly
defined. It can be interpreted as a string "C:\\HelloWorld.cpp" or a
wide string L"C:\\HelloWorld.cpp".

So, I think __FILE__ can be interpreted as a wide string by the
implementation, which still conforms to the standard.

Am I right? Any comment?

The standard uses the term "character string literal" as a synonym for
"narrow string literal", but although it gives examples of "character
string literal" it does not define the term, implicitly or explicitly.

 

[Robert Bauck Hamar]

__FILE__ holds an ANSI string containing the name of the source file.

There is no concept of 'ANSI string' in the C++ standard.

I'm not completely sure if this holds true for all platforms but I'm
guessing so.

AFAIK, the term 'ANSI string' is only used in a small number of platforms.

If you wanted to convert it to wide char format you'd have to do
something like:

#define WSTR2(s) L##s
#define WSTR(s) WSTR2(s)
#define __WFILE__ WSTR(__FILE__)

This is undefined behaviour. The name __WFILE__ contains two consecutive
underscores.

 

[Robert Bauck Hamar]

You could do it like so:

#define _CAT(A,B) __CAT(A,B)

1. This is undefined behaviour. _CAT starts with an underscore followed by a
capital letter. Such names are reserved for the implementation. In
addition, _CAT is in the global namespace, and names beginning with
underscore in the global namespace is reserved.
2. __CAT has not been declared. Declaring it yourself would be undefined
behaviour too, because it contains two consecutive underscores, and names
containing two consecutive underscores are reserved for the implementation.

#define WSTR(A) _CAT(L,A)

int main()
{
wchar_t x[] = WSTR( __FILE__ );
}

 

[Miguel Guedes]

This is undefined behaviour. The name __WFILE__ contains two consecutive
underscores.

Darn old MsVC accepts everything you throw at it...

Thanks for pointing that out, as I now know that in C++ "reserved
identifiers include keywords with two consecutive underscores (__), all
that start with an underscore followed by an uppercase letter, and some
other categories of reserved identifiers carried over from the C library
specification." [1]


[1] http://en.wikibooks.org/wiki/C++_Programming/Getting_Started

 

[Gianni Mariani]

Gianni Mariani wrote: ....
1. This is undefined behaviour. _CAT starts with an underscore followed by a
capital letter. Such names are reserved for the implementation. In
addition, _CAT is in the global namespace, and names beginning with
underscore in the global namespace is reserved.
2. __CAT has not been declared. Declaring it yourself would be undefined
behaviour too, because it contains two consecutive underscores, and names
containing two consecutive underscores are reserved for the implementation.

oops - I cut-n-pasted the wrong thing...

 

[Jack Klein]

It seems true, but I can't find any exact statement on this in the C
or C++ standard.

The C and C++ standard states:

"__FILE_ The presumed name of the source file (a character string
literal)."
Correct.

However, what the term "character string literal" means is not exactly
defined. It can be interpreted as a string "C:\\HelloWorld.cpp" or a
wide string L"C:\\HelloWorld.cpp".

Yes, it is well defined, see quotation from the C++ standard below,
and no it cannot be interpreted as a wide string.

6.4.5 P2:

"A character string literal is a sequence of zero or more multibyte
characters enclosed in double-quotes, as in "xyz". A wide string
literal is the same, except prefixed by the letter L."

So, I think __FILE__ can be interpreted as a wide string by the
implementation, which still conforms to the standard.

Am I right? Any comment?

If you mean "do you think what you have stated that you think", then
you are probably right, but only you know for sure.

If you mean whether you are right about an implementation being
allowed to expand the macro __FILE__ to a wide string literal, no you
are incorrect.T

he standard specifically defined "character string literal" and "wide
string literal" as two different things in the quoted paragraph above.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[Alf P. Steinbach]

* Jack Klein:

Yes, it is well defined, see quotation from the C++ standard below,
and no it cannot be interpreted as a wide string.

6.4.5 P2:

"A character string literal is a sequence of zero or more multibyte
characters enclosed in double-quotes, as in "xyz". A wide string
literal is the same, except prefixed by the letter L."

Sorry, that's incorrect: that's from the C standard, not the C++ standard.

 

[xmllmx]

Thank you, Jack.

That's just what I'm looking for.

 

[Alf P. Steinbach]

* xmllmx:

Thank you, Jack.

That's just what I'm looking for.

Please don't top post.

And note that that is not from the C++ standard (it's from the C standard).

 

[xmllmx]

* xmllmx:




Please don't top post.

And note that that is not from the C++ standard (it's from the C standard).

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

OK. Alf. Thank you for your correcting.

I looked it up in the C standard. I always think the C++ standard
inherits almost all from the C standard, so, I think everything in the
C standard always conforms to the C++ standard, but not vice versa.