OFMT - default awk output format - is "%.6g", from GNU Awk User's Guide

"5.4 Controlling Numeric Output with print
...
The built-in variable OFMT contains the default format specification that print uses with sprintf when it wants to convert a number to a string for printing. The default value of OFMT is "%.6g". The way print prints numbers can be changed by supplying different format specifications as the value of OFMT, as shown in the following example:

 
$ awk 'BEGIN {
> OFMT = "%.0f" # print numbers as integers (rounds)
> print 17.23, 17.54 }'
-| 17 18

According to the POSIX standard, awk's behavior is undefined if OFMT contains anything but a floating-point conversion specification. (d.c.)"

from The GNU Awk User's Guide

'via Blog this'

%#x (or %#llx), in C language format string - Stack Overflow and wpollock

I was looking up %#llx (which I found nowhere, even using SymbolHound).  But this is close enough (for x, # causes value to be prepended by 0x).  It's a new one on me  :-)

Do you know about %#x, in C language format string

up vote3down votefavorite	KdPrint(( "Unknown IoControlCode %#x\n", io_stack->Parameters.DeviceIoControl.IoControlCode )); It's weird. What does sharp mean? c format-string share|improve this question asked Aug 20 '10 at 9:50 Benjamin 1,6521934 85% accept rate
	feedback

3 Answers

activeoldestvotes

up vote3down voteaccepted

The printf documentation says: The character % is followed by zero or more of the following flags: # The value should be converted to an ‘‘alternate form’’. For o conversions, the first character of the output string is made zero (by prefixing a 0 if it was not zero already). For x and X conversions, a non-zero result has the string ‘0x’ (or ‘0X’ for X conversions) prepended to it. For a, A, e, E, f, F, g, and G conversions, the result will always contain a decimal point, even if no digits follow it (normally, a decimal point appears in the results of those conversions only if a digit follows). For g and G conversions, trailing zeros are not removed from the result as they would otherwise be. For other conversions, the result is undefined.conversions, the result is undefined. MSDN docs on the flags are here so %#x the value is simply prefixed with 0x. Where %x would yield 34ab %#x would yield 0x34ab share|improve this answer answered Aug 20 '10 at 9:54 nos 61.9k1173165

Was this post useful to you?

Do you know about %#x, in C language format string - Stack Overflow

And more specifically related to %#llx (new as of C99):

ll   (This is the letters ell-ell and not the digits one-one.)  The same as hh, except ll specifies the argument is a long long or unsigned long long.  (New as of C99.)

printf( "%#llX", 300 );

0X12C

http://wpollock.com/CPlus/PrintfRef.htm

'via Blog this'

Should I use printf in my C++ code? - Stack Overflow

Should I use printf in my C++ code? - Stack Overflow

I was just wondering what people really do if they have to print a lot of hex in their C++ code, and if in addition, they say always want to see a minimum width, which I find ugly and very verbose and error-prone with the cout/streams format.
(e.g.,  std::cout << std::hex << std::setfill('0') << std::setw(8) << x << std::dec << std::endl; )
I feel like there must be a good third solution, or people just use printf, or ???.  I read the above article, and about Boost.Format and all, which looks sorta interesting (although the examples they show don't seem all that brilliant for hex either, to me).  And people point out that for streams, "endl" implies a flush(), which you would otherwise have to do manually... But maybe I liked this answer best  :-)    :

3down vote

Use printf. Do not use C++ streams. printf gives you much better control (such as float precision etc.). The code is also usually shorter and more readable. Google C++ style guide agrees. Do not use streams, except where required by a logging interface. Use printf-like routines instead. There are various pros and cons to using streams, but in this case, as in many other cases, consistency trumps the debate. Do not use streams in your code. share|edit answered Jan 7 '10 at 2:26 Sherwood Hu 75748

+1 for the link. It's no 10 Commandments, but they sure have their heads on straight. – ojrac Jan 7 '10 at 5:07 In my opinion while the Google C++ Style Guide is very good in many respects, the consistency trump they refer to is that of their own code. Remember that Google has been around for 10 years, and they value code consistency (a very good thing). The reason they aren't using printf is because people used it in previous incarnations of their code and they want to remain consistent. If this weren't the case I'm confident that they would be using streams instead. – Geoff Mar 12 '10 at 16:59 Huh?! You have precision control with iostreams, too. – phresnel Feb 9 at 13:17

From the referenced link ( http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Streams#Streams ):

Streams

link▽

Use streams only for logging.

Definition:Streams are a replacement for printf() and scanf().

Pros:With streams, you do not need to know the type of the object you are printing. You do not have problems with format strings not matching the argument list. (Though with gcc, you do not have that problem with printf either.) Streams have automatic constructors and destructors that open and close the relevant files.

Cons:Streams make it difficult to do functionality like pread(). Some formatting (particularly the common format string idiom %.*s) is difficult if not impossible to do efficiently using streams without using printf-like hacks. Streams do not support operator reordering (the %1s directive), which is helpful for internationalization.

Decision:

Do not use streams, except where required by a logging interface. Use printf-like routines instead.
There are various pros and cons to using streams, but in this case, as in many other cases, consistency trumps the debate. Do not use streams in your code.

Extended Discussion

There has been debate on this issue, so this explains the reasoning in greater depth. Recall the Only One Way guiding principle: we want to make sure that whenever we do a certain type of I/O, the code looks the same in all those places. Because of this, we do not want to allow users to decide between using streams or using printf plus Read/Write/etc. Instead, we should settle on one or the other. We made an exception for logging because it is a pretty specialized application, and for historical reasons.
Proponents of streams have argued that streams are the obvious choice of the two, but the issue is not actually so clear. For every advantage of streams they point out, there is an equivalent disadvantage. The biggest advantage is that you do not need to know the type of the object to be printing. This is a fair point. But, there is a downside: you can easily use the wrong type, and the compiler will not warn you. It is easy to make this kind of mistake without knowing when using streams.

cout << this;  // Prints the address
cout << *this;  // Prints the contents

The compiler does not generate an error because << has been overloaded. We discourage overloading for just this reason.
Some say printf formatting is ugly and hard to read, but streams are often no better. Consider the following two fragments, both with the same typo. Which is easier to discover?

cerr << "Error connecting to '" << foo->bar()->hostname.first
     << ":" << foo->bar()->hostname.second << ": " << strerror(errno);

fprintf(stderr, "Error connecting to '%s:%u: %s",
        foo->bar()->hostname.first, foo->bar()->hostname.second,
        strerror(errno));

And so on and so forth for any issue you might bring up. (You could argue, "Things would be better with the right wrappers," but if it is true for one scheme, is it not also true for the other? Also, remember the goal is to make the language smaller, not add yet more machinery that someone has to learn.)
Either path would yield different advantages and disadvantages, and there is not a clearly superior solution. The simplicity doctrine mandates we settle on one of them though, and the majority decision was on printf + read/write.
...

If you need some further ammo, I also liked this guy, he is like a C++ anarchist, but he has some fair points:
http://yosefk.com/c++fqa/io.html#fqa-15.1
...

FQA: Why should I do this, why should I do that, you ask. What kind of manners are these? Do what you are told. Assignment Number 1 - convert all your evil printf("0x%08xn", x)statements to this:

std::cout << std::hex << std::setfill('0') << std::setw(8) << x << std::dec << std::endl; 

Even if you commit the environmental crime of namespace pollution, adding a using namespace std and removing those pesky std::, the verbosity is still amazing. This achievement is not accidental. It follows from one of the basic flaws in the C++ way of thinking: the "everything is a type" axiom. For example, hex has a special type which hexes streams, and so does every other strange object sent to cout.

The FAQ explains why this thinking is good for you. Here's why the FAQ is wrong:

...

;-)

Happy Coding,
Connie

'via Blog this'

Using awk --non-decimal-data for hex calculations... - Stack Overflow

Converting hex to decimal in awk or sed - Stack Overflow:

4down votefavorite

I have a list of numbers, comma-separated: 123711184642,02,3583090366663629,639f02012437d4 123715942138,01,3538710295145500,639f02afd6c643 123711616258,02,3548370476972758,639f0200485732 I need to split the 3rd column into three as below: 123711184642,02,3583090366663629,639f02,0124,37d4 123715942138,01,3538710295145500,639f02,afd6,c643123711616258,02,3548370476972758,639f02,0048,5732 And convert the digits in the last two columns into decimal: 123711184642,02,3583090366663629,639f02,292,14292 123715942138,01,3538710295145500,639f02,45014,50755 123711616258,02,3548370476972758,639f02,72,22322 sed awk decimal hex share|edit edited Jan 6 '11 at 14:26 Jonathan Leffler 158k14128295 asked Jan 6 '11 at 12:13 bernie 6219 53% accept rate

1 To the close-voter: this is a valid question about shell PROGRAMMING. – Jonathan Leffler Jan 6 '11 at 14:27 feedback

2 Answers

activeoldestvotes

up vote2down voteaccepted

Here's a variation on Jonathan's answer: awk $([[ $(awk --version) = GNU* ]] && echo --non-decimal-data) -F, '     BEGIN {OFS = FS}     {         $6 = sprintf("%d", "0x" substr($4, 11, 4))         $5 = sprintf("%d", "0x" substr($4,  7, 4))         $4 = substr($4,  1, 6)         print     }' I included a rather contorted way of adding the --non-decimal-data option if it's needed.

...

'via Blog this'