macOS ??) displays as ]

[jared_kipe]

UILabel.text = @"sin(??)";
gives output: sin(]

UILabel.text = @"??/H";
gives compiler warning about unknown escape string

What is going on? I could probably get around this by doing something like..
NSString *unknownString = @"??"; // I know @"??" displays fine
UILabel.text = [NSString stringWithFormat: @"sin(%@)", unknownString];


BUT I don't want to, I have to work with a lot of ??s in strings, and I need them to not frack up all the time.
I've have tried searching extensively and looking at articals on escaping strings, but cannot figure out the real reason behind this mystery. Probably because Google appears to ignore the ?? in "?? NSString" or "?? escape character"

 

[kainjow]

Maybe try escaping them?

UILabel.text = @"sin(\?\?)";

 

[jared_kipe]

Maybe try escaping them?

UILabel.text = @"sin(\?\?)";

This worked, I attempted escaping the first one and it resolved one but not all of my problems.

\??* worked
\?\?* works too
\??) doesn't work
\?\?) does work.

What is damned odd is that if you take out one question mark
?) works
What is the ?? characters actually doing?

 

[harry65]

Trigraphs

Check out the following page:

http://en.wikipedia.org/wiki/Digraph_(computing)

Never ran into this before; hmm. Not exactly sure how you turn off the trigraph feature in Xcode. Sounds like it's automatically turned on when you use the -ansi and/or -std=<> gcc flags, which I think Xcode does by default. Good luck with this one...

 

[jared_kipe]

Check out the following page:

http://en.wikipedia.org/wiki/Digraph_(computing)

Never ran into this before; hmm. Not exactly sure how you turn off the trigraph feature in Xcode. Sounds like it's automatically turned on when you use the -ansi and/or -std=<> gcc flags, which I think Xcode does by default. Good luck with this one...

Thank you SOOOO much. When I got to the section on Digraphs, I remember reading about those in one of my programming book. That is, the digraphs, I've NEVER seen trigraphs before.

What is still amazing to me is that googling "??) c string" does me no good. Oh and don't bother with the first link, NSFW!
Googling for every combination of ??) and the like turned up nothing either.

EDIT: Programming in Objective-C 2.0 by Stephen Kochan has Digraphs on p505, Trigraphs on p561.

 

[Sander]

This is one of those things which probably should have been gotten rid of long ago, but then that "new" C would break some program written long ago by someone with a weird keyboard without a ] key...

The C standard doesn't prescribe ASCII. There is a definition for the "source character set", where some characters are "optional" and can be replaced by trigraphs. Note that also the $ and @ characters are not in this set, so they are invalid in C identifiers.

 

[jared_kipe]

I should rewrite all my source code replaceing the Obj-C [x] calls with ??(x??)

It is so much more readable don't you think. Oh and the if statements and method curlys

if ( ??(myObject isTrue??) ) ??<
int i=1;
??>

I love it!

I think something like this could probably fix it.
#ifndef ??
#define ?? \?\?
#endif

 

[lee1210]

I think something like this could probably fix it.
#ifndef ??
#define ?? \?\?
#endif

I was thinking of something like that, too, but from what i read the trigraphs are handled by the preprocessor, so you'd be gaming when the preprocessor performed particular steps, and you may or may not get what you're hoping for.

-Lee

 

[Catfish_Man]

I believe there's a checkbox in the build settings to turn trigraphs off.

 

[jared_kipe]

The more I think about it, the more I think trigraphs/digraphs should be removed from the C spec.

Their ability to confuse and hurt programmers outweighs the need to keep them around.

What is the likeliness that code requiring trigraphs/digraphs is still needing to be compiled?
Any code requiring trigraphs/digraphs could be updated with a simple search and replace trip through an editor OR they can compile it on an older version of GCC or whatever.

 

[Sander]

The more I think about it, the more I think trigraphs/digraphs should be removed from the C spec.

Their ability to confuse and hurt programmers outweighs the need to keep them around.

Good, send an email to the C standardization committee. I'm sure they have been hoping that someone would think about it some more, and will be happy to update the specification according to your insights. While you're at it, perhaps you can ask them to remove octal constants too (another fun source of confusion).

Any code requiring trigraphs/digraphs could be updated with a simple search and replace trip through an editor OR they can compile it on an older version of GCC or whatever.

That is not the point. C specifies the "source code character set" and that happens to be not the same as ASCII. Remember that C is also used on "obscure" embedded platforms and weird CPUs.

I didn't want to sound harsh. I personally agree that they probably should have been removed, specifically when going to C99, but apparently the standardization committee decided otherwise and they're a bunch of much smarter guys than all of us combined.

Note that GCC ignores trigraphs by default, and only enables them in standards-conforming modes. You can explicitly enable support for them using the -trigraphs compiler switch. You could try adding -no-trigraphs to your project settings. If I try this on the command line, gcc seems to swallow this option...

 

[gnasher729]

That is not the point. C specifies the "source code character set" and that happens to be not the same as ASCII. Remember that C is also used on "obscure" embedded platforms and weird CPUs.

It's not just about weird and obscure platforms. The gcc compiler on your Mac supports source files in Utf-8 format. Try printing strlen ("äöüÄÖÜ"). Hint: The result is not six.

Basically the rule is: If your source code contains a string with the sequence ??, then replace it with \?\?. Except when the source code really wanted a trigraph character, then replace it with the right character. That way your code will work correctly and without warnings whatever the compiler thinks about trigraphs.

 

[jared_kipe]

This is a PRECOMPILER directive. Does not affect how the machine code will run.

All the substitute characters are in ASCII, they are just for keyboards that didn't have # ] characters when the original source was written.

I do not believe removing this from the C standard would make it harder to develop C software for imbedded or "weird" platforms.

 

[gnasher729]

This is a PRECOMPILER directive. Does not affect how the machine code will run.

All the substitute characters are in ASCII, they are just for keyboards that didn't have # ] characters when the original source was written.

I do not believe removing this from the C standard would make it harder to develop C software for imbedded or "weird" platforms.

Question 1: If this was removed from the C standard, is it possible that some program would not compile anymore?

Question 2: If this was removed from the C standard, is it possible that some program would malfunction?

A change like that is very, very dangerous.

 

[jared_kipe]

Question 1: If this was removed from the C standard, is it possible that some program would not compile anymore?

Yes. Though it would be simple to fix, or they could compile it with an earlier complier.

Question 2: If this was removed from the C standard, is it possible that some program would malfunction?

A change like that is very, very dangerous.

Not the way I see it. Previously compiled programs would be fine (obviously, they are machine code already). Recompiling code that used them will not compile, thus they wouldn't get malfunctioning machine code, they would get compile errors and no machine code.

OK so maybe not remove it, but make it so it isn't the standard/default way Xcode or other compilers operate.

 

[Sander]

Sorry to resurrect an old thread, but I recently came across this:
http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2009/n2910.pdf

The deprecation of trigraphs is up for voting, but the authors in this paper argue against it.