C / C++ / MFC

C pre increment and post increment

15-Dec-17 2:51

I would expect a meaningful error message if one the parameters is wrong.

That generic message might indicate that it is networking problem. Because you are using localhost (127.0.0.1) it is probably not due to blocking by a firewall. You should check the port number and ensure that it is the port on which your server is listening.

Depending on the operating system, you might also us a command line utility to show listening ports (as root/adminstrator: Linux: lsof -nPi, Windows: netstat -ban).

Anonygeeker13-Dec-17 23:27

13-Dec-17 23:27

Hi,
int x=11;
printf("%d %d %d ", x++,++x,++x);

It prints 13 14 14, But I thought 13 14 15
Why ?

Richard MacCutchan13-Dec-17 23:52

Richard MacCutchan

13-Dec-17 23:52

Because you should never use such expressions. The compiler writers are allowed to handle the order of incrementation in any way they like, so the results may or may not be what you expect. Bottom line: don't do it.

Anonygeeker14-Dec-17 1:05

14-Dec-17 1:05

I agree. but my doubt was how it happens.

Jochen Arndt14-Dec-17 0:01

14-Dec-17 0:01

It is executed in this order here:

C++

// Pre-increment is executed first
++x; // 12
++x; // 13
// push first parameter on the stack: 13
push x; 
// post increment
x++; // 14
// push 2nd and 3rd parameter on the stack: 14
push x; 
push x;

Anonygeeker14-Dec-17 1:05

14-Dec-17 1:05

Good explanation..Thanks

leon de boer14-Dec-17 6:16

leon de boer

14-Dec-17 6:16

It isn't a good answer it's wrong the result is undefined.

Try it on VS2017 and you will likely get "13 13 13 " because of the way the optimizer works.

In vino veritas

Daniel Pfeffer14-Dec-17 2:00

Daniel Pfeffer

14-Dec-17 2:00

This expression is undefined by the C Standard, meaning that the compiler can do anything with it, including formatting your disk or causing demons to fly out of your nose. You should consider yourself lucky that the compiler only incremented 'x' in a weird manner. Smile | :)

Note that even changing the compiler options (e.g. optimization) might change the printed results, so even if this "appears to work properly" on your system - DON'T DO IT!

(On comp.std.c and comp.lang.c they used to refer to a notional system, the DeathStation 9000, that would actually create Nasal Demons when it encountered undefined expressions Smile | :)

)

If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.

--Winston Churchill

Anonygeeker14-Dec-17 17:15

14-Dec-17 17:15

thank you .. Smile | :)

wchar_t in C

Anonygeeker13-Dec-17 22:18

13-Dec-17 22:18

Hi,

Is there a data type wchar_t in C?If so, how it differ from char?

CPallini13-Dec-17 22:44

CPallini

13-Dec-17 22:44

Quote:
Is there a data type wchar_t in C?

Yes, apparently[^].

Quote:
If so, how it differ from char?

It is compiler dependent.

Jochen Arndt13-Dec-17 22:50

13-Dec-17 22:50

Yes, since C90.

See wchar_t - C++ Reference[^] and Wide character - Wikipedia[^].

Because it is implementation defined (compiler and platform dependant), there is no general answer to how it differs from a char.

Anonygeeker13-Dec-17 23:51

13-Dec-17 23:51

Thanks. I tried finding size of it and got 4 bytes. If so, It should be able to take something like "abc". But its not happening. Why?

Jochen Arndt14-Dec-17 0:09

14-Dec-17 0:09

Because "abc" is a char* string and not a wchar_t which represents a single character.

wchar_t are used to store fixed length Unicode characters like UTF-16 or UTF-32 while char can store fixed length ASCII or ANSI characters (with an associated code page) or variable length characters like UTF-8 or Microsoft multi byte characters.

jschell14-Dec-17 8:48

14-Dec-17 8:48

Jochen Arndt wrote:
wchar_t are used to store fixed length Unicode characters like UTF-16 or UTF-32

Just noting that statement is somewhat of a generalization.

For starters, unicode, for those bit sizes never represents all characters via single character. One needs to go to 128 bits for a full representation. Maybe that isn't even big enough.

Additionally it is not limited to unicode. Although perhaps these days that would be the predominant usage in the western world.

Jochen Arndt14-Dec-17 11:46

14-Dec-17 11:46

Quote:
"wchar_t are used to store fixed length Unicode characters like UTF-16 or UTF-32"

Just noting that statement is somewhat of a generalization.

Why? As far as I know wchar_t is not used for variable length encodings.

jschell wrote:
for those bit sizes never represents all characters via single character

While that is true for UTF-16 it is not for UTF-32.

jschell wrote:
One needs to go to 128 bits for a full representation

That is wrong.

The Unicode Blog: Announcing The Unicode® Standard, Version 10.0[^]:
Tuesday, June 20, 2017

Version 10.0 of the Unicode Standard is now available. For the first time, both the core specification and the data files are available on the same date. Version 10.0 adds 8,518 characters, for a total of 136,690 characters. These additions include four new scripts, for a total of 139 scripts, as well as 56 new emoji characters.

Still 14 of 32 bits unused.

jschell16-Dec-17 8:34

16-Dec-17 8:34

Jochen Arndt wrote:
Why? As far as I know wchar_t is not used for variable length encodings.

It is intended for any character set, not just unicode. Most representations are not unicode.

And unicode IS a variable length encoding to some meaning of that definition. There are escape characters in the 8/16/32 bit unicode character sets that allow for the definition of additional characters using multiple 'character' values. So two wchar_t might be needed for a single character.

Jochen Arndt wrote:
While that is true for UTF-16 it is not for UTF-32.

"UTF-32 does not make calculating the displayed width of a string easier, since even with a "fixed width" font there may be more than one code point per character position"

UTF-32 - Wikipedia[^]

I will state that it is unlikely for this to be used.

Jochen Arndt wrote:
That is wrong.

Presumably you are claiming that UTF-32 contains every possible character.

So based on that logic what exactly is in UTF-64? Just UTF-32 for the first half and the empty space for the rest?

Jochen Arndt wrote:
Still 14 of 32 bits unused.

That isn't relevant. It isn't how the character set is defined but rather the extent and how it is used.

There are unused spots in a number of places in unicode in general. No idea why. Perhaps they figure a specific range of the character set might have a few more characters added in the future.

Far as I can recall many character sets beyond 7 bits end up duplicating or adding to a real character set. For example the normal extended ascii set has several dashes and a few mathematical symbols. And that is only using 8 bits.

Jochen Arndt17-Dec-17 0:33

17-Dec-17 0:33

Quote:
It is intended for any character set, not just unicode. Most representations are not unicode.

Examples (I don't know one except when wchar_t is defined as char)?

Quote:
And unicode IS a variable length encoding to some meaning of that definition

There are multiple Unicode encodings where some are fixed length and some are variable length.

Quote:
So two wchar_t might be needed for a single character.

It is intended to be used for single characters. Allowing more than one requires a much more complex implementation (like with the char based Microsoft multi byte character sets).

Quote:
"UTF-32 does not make calculating the displayed width of a string easier, since even with a "fixed width" font there may be more than one code point per character position"

Fonts and there display length is not related to character encoding specifications.

Quote:
That isn't relevant. It isn't how the character set is defined but rather the extent and how it is used.

It is all about the definition regarding the required storage size.

The unused code points are there because the codes are grouped (each script or symbol type has an assigned range). See Unicode block - Wikipedia[^]. So new characters / symbols can be added later to the belonging group (a rather old example is the Euro symbol).

The grouping has been choosen because with 32 bits there is enough room. Unicode already contains nearly all known scripts including ancient ones like Runes and Mayan glyphs and a wide range of symbols.

jschell18-Dec-17 15:30

18-Dec-17 15:30

Jochen Arndt wrote:
The grouping has been choosen because with 32 bits there is enough room. Unicode already contains nearly all known scripts including ancient ones like Runes and Mayan glyphs and a wide range of symbols.

As I said there is a 64 bit definition. Left to you to explain what the purpose of that is.

Jochen Arndt18-Dec-17 21:12

18-Dec-17 21:12

I can't explain the purpose of something that does not exist. There is neither UTF-64 nor UTF-128.

jschell23-Dec-17 12:50

23-Dec-17 12:50

Jochen Arndt wrote:
There is neither UTF-64 nor UTF-128.

I stand corrected - far as I can tell there is no 64 bit encoding.

However there still remains code points in the 32 bit set that require a total of two code points.

Anonygeeker14-Dec-17 17:25

14-Dec-17 17:25

fixed length Unicode characters like UTF-16 or UTF-32-A detailed explanation will be helpful.And any example for them?

Jochen Arndt14-Dec-17 20:48