Thursday, November 21, 2019

Digest for comp.lang.c++@googlegroups.com - 11 updates in 4 topics

Paavo Helde <myfirstname@osa.pri.ee>: Nov 21 06:20PM +0200

On 21.11.2019 13:53, Soviet_Mario wrote:
 
>> I'm curious about something. Do you have a realistic expectation that
>> your code might need to work under an implementation with CHAR_BIT > 8?
 
> no, not at all.
 
Good. I suspect that without lots of porting and testing efforts none of
these software pieces would work with CHAR_BIT>8 - neither gambas,
neither QT and neither your code.
 
> code that calls the C++ static library and that expects a 8-bit wide
> unsigned integral, find its matching type in the C++ code, as they need
> to share bitmaps and transparency maps.
 
This is easy, use unsigned char or std::uint8_t.
 
> The bitmaps use 32-bit packed colors+alpha channel, so I was assuming no
> difficulty in exchange.
 
This is more tricky because the size of int or long varies much more
than char. For example, long is 32 bits in 64-bit MSVC and 64 bits with
64-bit gcc on Linux.
 
However, for your purposes std::uint32_t should work fine.
 
> support for single bit R/W
> so I decided to waste some space and to use an addressable unit of 8
> bits for a boolean value
 
This is a common choice, ok.
 
> static library solution would produce a binary with all the needed QT
> essentials hard wired in it and no further dependencies (just a guess,
> all to be verified).
 
Qt is mostly a GUI library as far as I have understood. Of course it has
all bells and whistles like threading support and datetime library and
whatever, but these things are nowadays also present in standard C++. So
if you are writing some back-end library with no GUI interface involved,
you actually should not need Qt at all.
Soviet_Mario <SovietMario@CCCP.MIR>: Nov 21 06:07PM +0100

Il 21/11/19 17:20, Paavo Helde ha scritto:
> On 21.11.2019 13:53, Soviet_Mario wrote:
 
CUT
 
> nowadays also present in standard C++. So if you are writing
> some back-end library with no GUI interface involved, you
> actually should not need Qt at all.
 
uhm ... this might sound silly ... but I had not thought a
lot about this choice. And actually I find it a darn good
advice.
I am using an elephant to tow a feather :\
I used it without much thought, but now that you said it,
CodeBlocks would be more than enough.
Ciao !
 
 
 
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 21 05:34PM

On 21/11/2019 16:20, Paavo Helde wrote:
>> essentials hard wired in it and no further dependencies (just a guess,
>> all to be verified).
 
> Qt is mostly a GUI library as far as I have understood. Of course it has all bells and whistles like threading support and datetime library and whatever, but these things are nowadays also present in standard C++. So if you are writing some back-end library with no GUI interface involved, you actually should not need Qt at all.
 
Qt has too much legacy cruft: QVector? LOL. My alternative, neoGFX, will ultimately win out as I have the distinct advantage of being able to support modern C++ as I have no legacy user-base to worry about.
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."
Keith Thompson <kst-u@mib.org>: Nov 21 11:30AM -0800

David Brown <david.brown@hesbynett.no> writes:
[...]
> uint8_t is always 8 bits. No more, no less.
[...]
 
Yes. Expanding on that, uint8_t is always 8 bits *if it exists*.
 
(And in the real world, it almost always exists. You're far more
likely to encounter a very old implementation that doesn't support
<stdint.h> or <cstdint> than to encounter one that does have those
headers but has CHAR_BIT>8.)
 
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
David Brown <david.brown@hesbynett.no>: Nov 21 10:54PM +0100

On 21/11/2019 20:30, Keith Thompson wrote:
> likely to encounter a very old implementation that doesn't support
> <stdint.h> or <cstdint> than to encounter one that does have those
> headers but has CHAR_BIT>8.)
 
That is certainly true if by "in the real world" you mean "platforms
that support QT" :-)
 
I've worked with a couple of devices that have 16-bit CHAR, and been
indirectly connected with a project using one with 32-bit CHAR. These
were DSP devices, but are current devices, with new family members being
added regularly. But it is very rare that you want much software that
will be portable between these sorts of chips and other more "normal"
processors.
 
Balancing that, I have a few compilers that I still have occasion to use
that don't support <stdint.h> (or C++, for that matter).
Adnan Rashid <adnanrashidpk@gmail.com>: Nov 21 10:48AM -0800

Dear All,
 
I wrote this below code in the source file. (I am using a simulator ns3 which is based on C++)
 
 
ApplicationContainer sixLbrApps;
ObjectFactory factory;
factory.SetTypeId (SixLowPanRadvd::GetTypeId ());
Ptr<SixLowPanRadvd> sixLbr = factory.Create<SixLowPanRadvd> ();
nodes.Get (0)->AddApplication (sixLbr);
sixLbrApps.Add (sixLbr);
sixLbrApps.Start(Seconds(0));
 
 
How can I write a helper function for the above code? So I can reuse the above functionality by calling the function.
scott@slp53.sl.home (Scott Lurndal): Nov 21 03:44PM


>Note also that even if "E" is an expression with an integer type and a
>value of 0, (T*)E is not guaranteed to produce a null pointer value
>That guarantee requires an integer literal.
 
I'm sorry to have inadvertantly confused you. The Architecture is question
used the 24-bit value 0xeeeeee as the sentinal value that indicated
end of a linked list of entries. That is one purpose of C's null/NULL
pointer. And of course languages other than C also have a concept of
a NULL pointer by whatever name you want to use.
 
The machine was a BCD machine without fixed operand sizes[*] (pointers
were originally six BCD digits because the machine only supported
one million digits (500kB) of memory). Later, a multi-level segmenting
scheme was added to the architecture which exended pointers to 8 BCD
digits (co-incidentally 32-bits). The high order 8 bits of the pointer
were a sign digit and a base selector digit; the remaining 6 digits
were the offset from the specified base register. Those 6 digits were
set to the value 0xEEEEEE (an invalid BCD address) to indicate end
of list (and for a null pointer); The hardware had instructions to walk
linked lists (SLT instruction) and the hardware reinstate list (the list
of read-to-run thread/task/process contexts) was also organized as a linked
list and was dispatched using the privileged BRV (Branch Reinstate Virtual) instruction.
 
[*] The arithmetic instruction operands could be from one to 100 digits
(or bytes with the zone digit ignored) in length.
 
While we tried a couple times to make a useful C compiler for the architecture,
the lack of any form of bit shifting and/or rotation instructions made it
too inefficient for the architecture, which frankly was designed specifically
for COBOL.
James Kuyper <jameskuyper@alumni.caltech.edu>: Nov 21 09:17AM -0800

On Thursday, November 21, 2019 at 10:44:42 AM UTC-5, Scott Lurndal wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
...
> >several C++ contexts, one of the most important being the phrase "null
> >pointer". C++ is a case sensitive language, so I don't think it counts
> >as pedantry to point out that these are different things.
...
> I'm sorry to have inadvertantly confused you.
 
No problem - you didn't confuse me. I immediately realized that you were
incorrectly using "NULL pointer" where you should have said "null
pointer". I was merely trying to get you to correct your usage, since,
sooner or later, you're likely to misuse those terms in a context where
it will cause confusion.
I was apparently unsuccessful, since you went on to use NULL incorrectly
two more times:
 
"Öö Tiib" <ootiib@hot.ee>: Nov 21 05:29AM -0800

On Thursday, 21 November 2019 13:34:55 UTC+2, David Brown wrote:
 
> Fair enough for the facts of these languages - they have the type coming
> last. (I am taking your word for that - I don't know the details of
> them.)
 
I sometimes try programming languages (for fun puzzle with new tool)
so I'm 100% sure that all of those (plus also Kotlin) use "type right" syntax.
Also type can be often implicitly deducible and then there are just nothing
(no "auto") needed.
 
> - is that just your guess, or have they published rationales or other
> information explaining their reasoning? (I hope it is the later, as
> those could be very interesting reads.)
 
For general public the best explanation that I have read was blogged
by Rob Pike about Go:
<https://blog.golang.org/gos-declaration-syntax>
Note that it is actually matter of taste (again) so your mileage may vary
from strongly disagree to fully agree but the argumentation felt relatively
solid there.
 
My own opinion is that C's declarations are simpler for parsers to parse
but Go/Rust/Swift/Kotlin declarations feel easier for human to to type
and to read.
Manfred <noname@add.invalid>: Nov 21 03:50PM +0100

On 11/21/2019 6:02 AM, Alf P. Steinbach wrote:
 
> I remember introducing Bjarne to the term in a mail exchange, but it's
> apparently not in my GMail so it must be have been before July 2006.
 
> - Alf
read: Bjarne's book says on SFINAE ...
The C++ Programming Language (4th Edition), p. 692
 
However, it is curious that the following still fails:
 
template< class Int, class UInt = make_unsigned_t<Int> >
struct S
{
// using UInt = make_unsigned_t<Int>;
UInt m;
 
S( Int x, Int ): m( UInt( x ) ) {}
};
 
The error is still about "invalid use of incomplete type", which sounds
like a type error to me.
 
while
 
template< class Int, typename = typename
enable_if<is_integral<Int>::value>::type
 
struct S
{
using UInt = make_unsigned_t<Int>;
UInt m;
 
S( Int x, Int ): m( UInt( x ) ) {}
};
 
seems to work fine.
David Brown <david.brown@hesbynett.no>: Nov 21 03:58PM +0100

On 21/11/2019 14:29, Öö Tiib wrote:
>> them.)
 
> I sometimes try programming languages (for fun puzzle with new tool)
> so I'm 100% sure that all of those (plus also Kotlin) use "type right" syntax.
 
I too like to try new languages - when I get the time!
 
> Note that it is actually matter of taste (again) so your mileage may vary
> from strongly disagree to fully agree but the argumentation felt relatively
> solid there.
 
I'll read it - thanks for the link.
 
 
> My own opinion is that C's declarations are simpler for parsers to parse
> but Go/Rust/Swift/Kotlin declarations feel easier for human to to type
> and to read.
 
Many of the humans here find C's declaration easy to parse from long
habit - it's always difficult to judge such inherently subjective issues.
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)