Tuesday, June 2, 2020

Digest for comp.lang.c++@googlegroups.com - 24 updates in 6 topics

Bart <bc@freeuk.com>: May 27 03:22PM +0100

On 27/05/2020 13:01, Ben Bacarisse wrote:
>> 2 and 1.0)
 
> Yes, but the suggestion was to use 1UL << i, not 2 << i. (I might use
> 1ull to get be sure to get the widest unsigned standard type.)
 
OK, that's probably why it didn't work!
 
Using 1<<i and i<<(level-i-1) worked as far as I could see.
(Calculations all using signed 64 bits in the language I used.)
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 01 11:30PM -0700

On 5/29/2020 3:07 PM, Alf P. Steinbach wrote:
>> `pow`, `cos` and `sin, it can instead call ct_root_gen with just 1
>> call to `pow`, `cos` and `sin`, to get a generator which it then can
>> call repeatedly to more fastishly get the b roots.
 
Using the constant e should help out.
The Real Non Homosexual <cdalten@gmail.com>: Jun 02 02:23PM -0700

e can either mean exponent or the euler constant.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 02 03:18PM -0700

On 6/2/2020 2:23 PM, The Real Non Homosexual wrote:
> e can either mean exponent or the euler constant.
 
The latter.
ram@zedat.fu-berlin.de (Stefan Ram): Jun 02 09:21PM

>10
>11
>so bool and integer type not required. Thanks in advance
 
If you only need a few of those bit pairs, you have no
memory concerns and can use one or even two int objects
to store two bits without hesitation.
 
If you need a lot of those bit pairs, try to hold them in
some kind of array. Then you can pack s * CHAR_BIT bits in
an object of size s. Bit pair p then resides at the array
offset 2 * p /( s * CHAR_BIT ) and the object offset 2 * p
% ( s * CHAR_BIT ), and you can use the operators "&", "|",
">>", "<<", and "=" to read/write a pair of bits.
 
In a real programming language like Pascal, you can simply
write
 
packed array[ 1..n ]of( s00, s01, s10, s11 )
 
or omit "packed" and let the compiler do the detail work.
 
In C++, there is »::std::vector< bool >« which is neither
a vector nor does it contain bool objects. You could use
this as a kind of an array of single bits and do the
combining of pairs of two bits yourself.
Real Troll <real.troll@trolls.com>: Jun 02 04:08AM -1000

Just noticed that these two program give two different results. One is a
C program and other is a C++ program.
 
<**********    C++   ******************>
 
#include <iostream>
 
 
using namespace std;
 
int main(){
   cout << sizeof('a') << endl;
   cout << sizeof(1!=1) << endl;
   return 0;
}
 
<**********    C   ******************>
 
#include<stdio.h>
#include <stdlib.h>
int main(){
   printf("%4zu", sizeof('a'));
   printf("%4zu", sizeof(1!=1));
   return 0;
}
Juha Nieminen <nospam@thanks.invalid>: Jun 02 06:45PM

> Just noticed that these two program give two different results. One is a
> C program and other is a C++ program.
 
The type of 'a' in C is int, while in C++ it's char. I'm not exactly
sure why its type is int in C (given that C has always had char as a
type, and it has, too, mostly been designed from the ground up with
the philosophy of "you don't pay for what you don't use"). Maybe
it has something to do with C, at least originally, supporting
multi-character constants like 'ab'.
 
I'm also not completely certain why this is one thing which C++
decided to change. (I suppose it's good that it changed it, but
I'm not really sure why this.)
Bart <bc@freeuk.com>: Jun 02 07:55PM +0100

On 02/06/2020 19:45, Juha Nieminen wrote:
> the philosophy of "you don't pay for what you don't use"). Maybe
> it has something to do with C, at least originally, supporting
> multi-character constants like 'ab'.
 
Maybe because the type of 97 is int too. Then 'a' is just another way of
writing 97.
Lew Pitcher <lew.pitcher@digitalfreehold.ca>: Jun 02 03:06PM -0400

On June 2, 2020 14:45, Juha Nieminen wrote:
 
> the philosophy of "you don't pay for what you don't use"). Maybe
> it has something to do with C, at least originally, supporting
> multi-character constants like 'ab'.
 
From what I have been able to find, multi-character constants initiallly
were a platform-dependant side-effect of how K&R C handled character
constants.
 
I believe that the reason for K&R C handling character constants as integers
revolves around the original compiler constraints in emitting PDP-11
assembly/machine language. Specifically, Dennis Ritchie, in the "C Reference
Manual" (circa May 1975) states, of character constants, that
"they behave exactly like integers (not, in particular, like objects of
character type). In conformity with the addressing structure of the
PDP-11, a character constant of length 1 has the code for the given
character in the low-order byte and 0 in the high-order byte; a character
constant of length 2 has the code for the first character in the low byte
and that for the second character in the high-order byte. Character
constants with more than one character are inherently machine-dependent
and should be avoided."
(https://www.bell-labs.com/usr/dmr/www/cman.pdf)
 
 
--
Lew Pitcher
"In Skills, We Trust"
Lew Pitcher <lew.pitcher@digitalfreehold.ca>: Jun 02 03:11PM -0400

On June 2, 2020 14:55, Bart wrote:
 
>> multi-character constants like 'ab'.
 
> Maybe because the type of 97 is int too. Then 'a' is just another way of
> writing 97.
 
Perhaps you are joking?
 
Everyone knows that the C character constant 'a' has a value of 129 (in
EBCDIC-US, of course).
 
--
Lew Pitcher
"In Skills, We Trust"
James Kuyper <jameskuyper@alumni.caltech.edu>: Jun 02 04:20PM -0400

On 6/2/20 2:45 PM, Juha Nieminen wrote:
> sure why its type is int in C (given that C has always had char as a
> type, and it has, too, mostly been designed from the ground up with
> the philosophy of "you don't pay for what you don't use").
 
Because C developed from earlier languages where there was only one
type, and when C became a typed language, that type generally defaulted
to int. While objects can have an integer type that is smaller than int,
values of such types are, in almost all contexts, promoted to int. A
character literal has a value, but is not an object.
 
> ... Maybe
> it has something to do with C, at least originally, supporting
> multi-character constants like 'ab'.
 
It still does, and so does C++. Such constants have the type 'int' in
both languages.
 
> I'm also not completely certain why this is one thing which C++
> decided to change. (I suppose it's good that it changed it, but
> I'm not really sure why this.)
 
I believe that the primary driver for the change was operator
overloading. Given
 
char c = 'c';
 
It would be inconvenient if overloaded_function(c) invoked a different
overload than overloaded_function('c').
"Öö Tiib" <ootiib@hot.ee>: Jun 02 02:10PM -0700

On Tuesday, 2 June 2020 22:11:30 UTC+3, Lew Pitcher wrote:
 
> Perhaps you are joking?
 
> Everyone knows that the C character constant 'a' has a value of 129 (in
> EBCDIC-US, of course).
 
Weird, dinosaurs who use EBCDIC-037 usually say that 'a' is 0201.
Adnan Rashid <adnanrashidpk@gmail.com>: Jun 02 05:08AM -0700

Hi All,
 
I want to declare a variable that holds only 2 bits.
 
In my problem, I have possible combinations are
 
00
01
10
11
 
so bool and integer type not required. Thanks in advance
Bonita Montero <Bonita.Montero@gmail.com>: Jun 02 02:44PM +0200

struct
{
unsigned value : 2;
} s;
You can't define bitfields out of a struct.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jun 02 01:10PM

On Tue, 2020-06-02, Adnan Rashid wrote:
> 10
> 11
 
> so bool and integer type not required. Thanks in advance
 
Depends on what you want to do with it. One solution is
 
enum class Bits { Zero, One, Two, Three };
 
but that won't, I think, be more compact in memory than
 
struct Bits {
Bits(bool a, bool b);
private:
unsigned char bits;
};
 
and not a lot more compact than
 
std::pair<bool, bool>
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Nikolaj Lazic <nlazicBEZ_OVOGA@mudrac.ffzg.hr>: Jun 02 01:24PM

> 10
> 11
 
> so bool and integer type not required. Thanks in advance
 
Minimal storage size is char or byte. If you want to store 1 bit you have to
allocate 1 byte at least.
Bart <bc@freeuk.com>: Jun 02 02:56PM +0100

On 02/06/2020 13:08, Adnan Rashid wrote:
> 10
> 11
 
> so bool and integer type not required. Thanks in advance
 
Implementations typically allow such variables of 8 to 64 bits.
 
Most applications will only need some of the 2**8 to 2**64 possible
values; they just ignore the rest.
 
How many 2-bit variables will there be in total? If only one, then the
packing/unpacking code needed will far exceed the 6 bits saved from uint8_t.
James Kuyper <jameskuyper@alumni.caltech.edu>: Jun 02 10:09AM -0400

On 6/2/20 8:08 AM, Adnan Rashid wrote:
> 10
> 11
 
> so bool and integer type not required. Thanks in advance
 
You can declare such a field, but only inside a struct. It's called a
bit-field:
 
struct contains_two_bit{
unsigned char two_bit:2;
};
 
However, while two_bit itself takes up only two bits, the entire struct
necessarily takes up at least one entire byte, and might take up more
space than that. You don't save any actual space by defining such a type
unless you declare other bit-fields either immediately before or
immediately after that one, in which case it may use up less space than
if you declared them as non-bit-fields. Adjacent bit-fields are packed
into some addressable allocation unit, the size of which depends upon
the implementation. The order of those bit-fields within an allocation
unit also varies with the implementation. Whether or not a bit-field
that is smaller than the allocation unit size may straddle the boundary
between allocation units can also vary from one implementation to
another. For example, given
 
struct bit_fields {
bool a:1;
int8_t b:3;
int8_t c:5;
int8_t d:7;
int16_t e:11;
int16_t f:13;
}
 
An implementation that uses an allocation unit with a size of 8, which
allows bit fields to straddle allocation units, could implement that
type by storing the fields as follows:
 
byte 1: a, b, and the first four bits of c
byte 2: the last bit of c, and d
byte 3: the first 8 bits of e
byte 4: the last 3 bits of e, the first five bits of f
byte 5: the last 8 bits of e.
 
An implementation that uses an allocation unit with a size of 16 that
doesn't allow straddling could implement it as follows:
 
first 2 bytes: a, b, c d
next 2 bytes: e and 5 padding bits
last 2 bytes: f and 3 padding bits
 
You can't take the address of a bit-field, and you can't bind it to a
reference. If two bit-fields in a struct are separated from each other
only by other bit-fields, you cannot safely access both bit fields
concurrently. For these reasons, it's often not worthwhile to declare
things as bit-fields.
Bonita Montero <Bonita.Montero@gmail.com>: Jun 02 06:00PM +0200

> std::pair<bool, bool>
 
This never would be 2 bits large.
"Öö Tiib" <ootiib@hot.ee>: Jun 02 01:38PM -0700

On Tuesday, 2 June 2020 15:08:39 UTC+3, Adnan Rashid wrote:
> 10
> 11
 
> so bool and integer type not required. Thanks in advance
 
Basically others have already answered what you can do.
You can only have two bit variables as class bit-field members.
Classes will occupy at least one byte so there will be
some leftover space if you need only one such variable.
If you happen to need 4 such variables then you can easily
have it. I write some code to illustrate potential
issues that you may face:
 
#include <iostream>
 
// use unsigned to not waste time on negatives
// use chars as smallest to not have whole
// struct made larger than 1 char
struct X
{
unsigned char a:2;
unsigned char b:2;
unsigned char c:2;
unsigned char d:2;
};
 
int main()
{
X x {0,1,2,3};

// have to cast to unsigned since chars will be put
// out as characters not numbers by cout
std::cout << "x.a = " << (unsigned)x.a << '\n'
<< "x.b = " << (unsigned)x.b << '\n'
<< "x.c = " << (unsigned)x.c << '\n'
<< "x.d = " << (unsigned)x.d << '\n'
<< "sizeof(x) = " << sizeof(x) << '\n';
 
return 0;
}
 
I can not find a platform where that compiles but does
not output:
 
x.a = 0
x.b = 1
x.c = 2
x.d = 3
sizeof(x) = 1
 
So the 4 bit-field data members took 2 bits each and together
one byte.
Juha Nieminen <nospam@thanks.invalid>: Jun 02 04:59AM


> A set hold data objects, and pointers are data objects so a set of
> pointers makes sense. Functions are not considered to be data objects
> in either C or C++ so you can't put them into collections.
 
The second template parameter is a comparator, not the element type.
James Kuyper <jameskuyper@alumni.caltech.edu>: Jun 01 10:13AM -0400

On 6/1/20 1:08 AM, Alf P. Steinbach wrote:
> On 01.06.2020 03:50, Ben Bacarisse wrote:
...
> converted to an expression that has type ``pointer to function returning
> type .''
> [/quote]
 
...
> But even though that's incompatible with your claim, and compatible with
 
How is that incompatible? The ANSI C89 standard and the ISO C90 standard
are essentially the same (the only significant difference was that 3
sections were added the beginning to meet ISO requirements for the
format of standard documents, resulting in every top level section
number increasing by 3, requiring a change to every single
cross-reference). He said that the change was made in C90, so that
supports his claim.
 
> directly of function type (K&R doesn't include the arguments list in the
> call), and that a function name is converted to pointer except when used
> as a call. Oh well. How could I have forgotten that weird idiosyncrasy.
 
Easily enough - the rules were carefully written for backwards
compatibility: in the expression (*function_pointer)(arguments) the
sub-expression *function_pointer still has a function type, as was
required in K&R C, but in C89(==C90) it gets implicitly converted back
into a function pointer, as required in C89. As a result, the main
practical consequence was that in C89 and later, you no longer needed to
dereference a function pointer in order to call the function, code that
would have been an error in K&R C.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Jun 02 10:36AM +0100

>> pointers makes sense. Functions are not considered to be data objects
>> in either C or C++ so you can't put them into collections.
 
> The second template parameter is a comparator, not the element type.
 
Ah, yes, I missed the comma. Oddly, though, the reason you can't use an
actual function type there is the same. A compare "thing" must be a
copy-constructable object, so a function type is ruled out. The
comparator is put into the collection -- it's part of the collection's
data.
 
--
Ben.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 28 09:37PM +0200

On 28.05.2020 06:41, Heitber Andres Montilla Ramirez wrote:
> ld.exe____cannot find -lwxzlibd
 
> i tried to add those in the linker settings but don't work.
> how i may solve this problem i'm using codeblocks 17.12 and wxwidgets 3.0.4
 
Find those libraries.
 
Possibly you may have to build them.
 
Then make sure that the the binaries are in folders that the linker
searches for libraries. One easy way is to place them together with
other library binaries that you know are found. One feels-more-right way
is to check the documentation (or output from `g++ -v --help`) to find
the option and/or environment variable that specifies those folders.
 
- Alf
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)