Talk:Bit field

Critisism

Is this text really correct? Isn't it too harsh?

However, bit members in structs have potential practical drawbacks. First, the ordering of bits in memory is cpu dependent and memory padding rules can vary between compilers. In addition, less well optimized compilers sometimes generate poor quality code for reading and writing bit members and there are potentially thread safety issues relating to bit fields because most machines cannot manipulate arbitrary sets of bits in memory, but must instead load and store whole words

abelson (talk) 12:54, 8 April 2010 (UTC)

IMO, this article could use a non-code example to improve clarity.OlyDLG (talk) 23:44, 22 November 2015 (UTC)

Misc

I'm quite surprised about this statement:

unsigned int likesIceCream : 1;

I guess it means "create an unsigned int with the size of 1 bit", so would

unsigned int myVar : 4;

create a 4-bit unsigned int variable by the name myVar? Is this colon operator defined in the ANSI C standard? --Abdull 19:08, 26 January 2007 (UTC)

Isn't the first thing ("|= flag") a bitmask, and only the second thing ("unsigned int a:1") a bit field? exe 11:42, 10 June 2007 (UTC)

This entire article seems quite bizarre, given that the term "bitfield" has a standard meaning in C, which is quite different than the meaning used in the article, and the examples are all in C.... (and indeed, use C bitfields). I've honestly never come across the term used in the sense the article describes (whereas the standard C meaning is quite widespread, at least in circles where C is used).

[Oh, and Abdull: yes the ": 4" syntax is quite standard, and has been in C for a very, very long time; that's exactly what a C bitfield is.]

--Snogglethorpe (talk) 12:50, 6 August 2008 (UTC)

I know I'm a bit late to the party but, to be honest, a Wikipedia article isn't the place to try to learn a programming language. If you're interested in knowing the detail of this type of construct, I'd suggest referring to the standard texts on the C programming language if you want to know more about this. Cosimo193 (talk) 14:48, 14 December 2022 (UTC)

Thread safety issue is not specific to bitfields. Many compilers allow command-line, #pragma or built-in switches to align structure differently than architecture expects. E.g. the following structure will have the same thread safety issues (GCC-specific example):

struct foo
{
  unsigned char flag;
  unsigned short counter;
} __attribute__ ((packed));

Bit field can be used to reduce memory consumption when it is known that only some bits would be used for a variable. Bit fields allow efficient packaging of data in the memory.

As we know, integer takes two bytes(16-bits) in memory. Some times we need to store value that takes less then 2-bytes. In such cases, there is wastages of memory. For example, if we use a variable temp to store value either 0 or 1. In this case only one bit of memory will be used rather then 16-bits. By using bit field, we can save lot of memory. — Preceding unsigned comment added by 118.102.246.178 (talk) 11:55, 25 May 2016 (UTC)

Stargazer3p14 (talk) 08:27, 29 April 2010 (UTC)

Found it: the current ISO/IEC standard ( http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf ) defines bit-fields in 6.7.2.1.8 . --Abdull (talk) 08:39, 10 June 2010 (UTC)

Easier readability, recommended by whom?

From the original article, after the first C example code block (emphasis mine):

the use of the bit shift operator (1 << 3) with an incrementing shift operand is recommended for easier readability.

While I have no doubt that it is more readable, I must question whether such a practice is actually recommended, and by whom, since I believe most programmers that use bit fields would (and should) be familiar enough with hex numbers to use them instead (0x01, 0x02, 0x04, 0x08, 0x10 ...). I have changed the word "recommended" to "used", but if anyone can find a notable source for such a recommendation, please feel free to change the wording back. C xong (talk) 03:25, 19 July 2010 (UTC)

Not only is the question of recommendation at issue, I dispute that it is easier to read. What the statement using a shift operator says is "take the number 1 and shift it 3 positions to the left". It says nothing about bits and does say something about an action when in fact no action is desired! I totally agree with C xong that a programmer writing code at the bit level must be familiar with the 0xZZ format. In fact, if the field were 3 bits wide, I would be surprised to find code like 1<<5 + 1<<6 + 1<<7 considered easier to read than 0xE0. The only time that there might be any justification for using the shift format is when the code is searching for a bit in a looping construct so that the position of the bit being examined was the loop index. DGerman (talk) 11:55, 14 August 2021 (UTC)

Confusing usage of "Bitfield"

This article ought to have a link in it (unfortunately I don't know how to do it correctly) to "Bitfield (C)" because this is very confusing. A C bitfield is different than this mess, and, as mentioned earlier, it is maximally unfortunate that this page uses examples in C that use the C bitfield (and some that don't). Perhaps the most useful edits would be to change all the examples to pseudo-code (and don't use C bitfields) and put a link up top to a separate disambiguated page "bitfield (C)". Perhaps I'll start working on this if it gets on my nerves enough soon. --Limited Atonement (talk) 15:13, 12 March 2011 (UTC)

Drawbacks of the structure-based approach

I recommend removing the example and commentary completely. The lack of thread-safety is not a "bitfield" problem, but related to the fact that two members of a structure are updated by two separate statements and the result is therefore non-atomic. This would be equally true of two integers, etc. Peter Flass (talk) 11:57, 22 June 2012 (UTC)

Error

The section stating "Obtaining the value of a particular bit can be simply down by left shifting (≪) 0, n amount of times" is incorrect. Shifting 0 will always yield 0. Could someone please correct this. 80.42.91.53 (talk) 01:11, 9 January 2014 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Bit field. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20070428213243/http://libbit.sourceforge.net:80/ to http://libbit.sourceforge.net/

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 09:01, 3 November 2016 (UTC)

False assertion

"A bit field is distinguished from a bit array in that the latter is used to store a large set of bits indexed by integers". It depends on language... Comparing text strings and text array in Javascript: is the same thing — changes only the "syntax sugar", a String method or array-like access, str[123] and str.charAt(123).

Significantly Outdated

Changes have been made to the requirements on bit-fields in structs in modern C++ standards (C++14 ->) which make it incorrect to conflate C and C++ in this article. — Preceding unsigned comment added by Cosimo193 (talk • contribs) 14:51, 14 December 2022 (UTC)