Sunday, December 31, 2017

Digest for comp.lang.c++@googlegroups.com - 17 updates in 5 topics

JiiPee <no@notvalid.com>: Dec 31 09:33PM

I dont understand why that foo(p); does not find the correct foo-version
automatically even though its obvious it should call the global
foo(const Player& player);. Can anybody please explain why its trying to
call the foo(const std::string& name, int a) version (and causing a
compilation error-) even though there is perfect match with the global
version?
 
Just would like to know the theoretical reason for this. (I know
::foo(p);  solves it, but is that the only solutions? I would rather not
put those :: ).
 
thanks
 
 
class Player
{
};
 
void foo(const Player& player);
 
class A
{
public:
    std::string name_;
    void foo(const std::string& name, int a)
    {
        Player p;
        foo(p);
    }
};
 
void foo(const Player& player)
{
 
}
 
int  main() {
    A a;
    a.foo("sdf", 9);
    return 0;
}
JiiPee <no@notvalid.com>: Dec 31 11:14PM

On 31/12/2017 22:46, Stefan Ram wrote:
> declaration /hides/ the outer declaration of the same name
> [basic.scope.hiding], and hidden names do not take part in
> name resolution.
 
ok, thanks, I thought its something like this.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Dec 30 09:42PM -0800

Man fell in the garden of Eden, and sin entered into this world and the
world we live in today is the result. Everywhere wars, hate, death, and
destruction, people looking out only for themselves and their personal
interests, and when they do charity it's to say, "Hey look! I do charity."
 
Jesus Christ came into this world to save man from sin. He teaches a new
way to be. That new way is the way He intended for us before sin entered
in and destroyed everything. He restores that which was lost: our future,
our eternal relationship with Him.
 
God is spirit. He is Father, Son, and Holy Spirit. His Son was flesh,
just like us. He came here to live under our laws and save us before God.
He completed His work at the cross after a ~3.5 year ministry, where He
was crucified and died in the flesh with our sin charged to Him. He was
innocent and had no sin of His own, and God allowed Him to receive the
sin of all who would put their faith and trust in Him, so that their sin
could be transferred (literally) from them to Him. Jesus died on the
cross, and went before God to pay the price of that sin. It was a heavy
price and it bruised God, it crushed Jesus. And on the third day, God
raised Him back to life and gave Him all authority in Heaven and on Earth.
 
What Jesus does for us when we come to Him and ask Him to forgive our sin,
is to restore us to eternal life. We are still here in this world for a
time, but our internal nature completely changes. We receive a new spirit
nature (John 3), and are guided from that day forward by His Holy Spirit.
Our flesh nature (sinful) is still here, and we can listen to that input,
and we can still do sinful things, but God's Holy Spirit is also there,
and our new spirit nature is also there, and everyone who is born of God
will not continue in sin for very long. God comes for us to lead us out
of sin, to even take us by the hand and drag us out of sin.
 
-----
Jesus didn't come to the Earth to save righteous people. He came to save
sinners.
 
Are you a sinner? Have you:
 
Ever stolen anything? Ever?
Used the Lord's name as a cuss word?
Lusted after someone who was not your spouse?
Told a lie? Ever?
Coveted after your neighbor's possessions? Ever?
 
All of us are guilty of these sins and more. Jesus knows this, which is
why He came here to save us. He does what we cannot do: He makes us
clean and shiny and innocent and new despite our filth and guilt in sin.
 
-----
You need to Jesus to forgive your sin. Ask Him to forgive you and begin
your new life with Him forever. He enters in the very moment you ask Him
to forgive your sin. It's what the words of the song Amazing Grace
convey:
 
"How precious did that grace appear, the hour I first believed..."
 
God's grace is given to us because He loves us. Jesus loves you and He
wants to forgive your sin and give you eternal life. Ask Him to forgive
you today, and enter in to His eternal Kingdom. He's gone ahead and made
a place for you, a custom place designed just for you, and He is return-
ing soon. The signs are foretold in the Bible and are unfurling before
our very eyes.
 
John 3:
https://www.biblegateway.com/passage/?search=John+3&version=KJV
 
Jesus prepares a place for you in advance:
https://www.biblegateway.com/passage/?search=John+14&version=KJV
 
Jesus loves you. I love you. I teach you about Him, and He teaches
you the truth. Read the Bible and learn the truth God gave mankind to
protect him from the enemy, to save him from sin. He did this for you,
directly and personally.
 
--
Rick C. Hodgin
Mr Flibble <flibble@i42.co.uk>: Dec 31 05:05PM

On 31/12/2017 05:42, Rick C. Hodgin wrote:
[snip: tl;dr]
 
Christianity is a religion and your god doesn't exist.
 
Merry Festivus.
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne 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."
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Dec 31 02:50PM -0800

On 12/31/2017 9:05 AM, Mr Flibble wrote:
> [snip: tl;dr]
 
> Christianity is a religion and your god doesn't exist.
 
> Merry Festivus.
 
Is it okay to have a pole that is not made of aluminum?
 
;^)
 
[...]
ram@zedat.fu-berlin.de (Stefan Ram): Dec 31 10:46PM

>void
...
>     void
 
The second declaration appears in a scope that is nested in
the scope of the first declaration. Therefore, the second
declaration /hides/ the outer declaration of the same name
[basic.scope.hiding], and hidden names do not take part in
name resolution.
Dombo <dombo@disposable.invalid>: Dec 31 01:46PM +0100

Op 30-Dec-17 om 23:44 schreef bitrex:
 
> There's not much below the ATTiny series; an ATTiny85 is around 75 cents
> in quantity.
 
Actually there is a lot below the ATtiny series if you look beyond the
8-bit AVR family. There are many, many other microcontroller families on
the market that target the really low-end/low-cost/low-power/high volume
market, where the unit price of a controller is only a few cents each.
For those few cents you can expect a small OTP or mask ROM program
memory of at most a couple of kilobytes, a couple of bytes of RAM, a few
4-bit registers and a few peripherals. The average hobbyist won't know
about those; companies selling them won't talk to you unless you intend
to buy quantities of a like a million or more. However chances are you
have already many of those in your home.
David Brown <david.brown@hesbynett.no>: Dec 31 02:53PM +0100

On 31/12/17 13:46, Dombo wrote:
> about those; companies selling them won't talk to you unless you intend
> to buy quantities of a like a million or more. However chances are you
> have already many of those in your home.
 
There are very few 4-bit microcontrollers used now, even in the most
cost-sensitive mass produced applications. The cost difference between
a 4-bit core and an 8-bit (or even 16-bit or 32-bit) core is too small
now with smaller processes and many free or cheaply licensed cpu cores.
In a typical cheapo device (like those "amusing" birthday cards that
play a tune, or plastic giveaway toys with a kid's comic) the
peripherals like a timer or two and a DAC or PWM with amplifier cost a
lot more than the cpu core in terms of die space. But you are right
that these cores may be a more limited than even an ATTiny - though some
of them are /exactly/ as limited as ATTiny's, as a major part of Atmel's
business is ASICs with these kinds of cores.
 
And in these sorts of devices, I think you'd be surprised at the amount
of memory or other peripherals. It is not uncommon to have quite a bit
of ROM - far more than the flash sizes of an off-the-shelf ATTiny. But
it will be masked ROM, not OTP - the programming time for writing an OTP
and the electronics for making the high voltages would be far too expensive.
 
The last 4-bit microcontroller family that was available to mere mortals
was from Atmel - I've forgotten the name of it. They had devices with
flash (for prototyping) as well as masked ROM. Some of them had 30 or
more pins, and a wide range of peripherals - especially wireless
communication. But no C++ compiler - just a limited variation of Forth.
bitrex <bitrex@de.lete.earthlink.net>: Dec 31 09:03AM -0500

On 12/31/2017 07:46 AM, Dombo wrote:
> about those; companies selling them won't talk to you unless you intend
> to buy quantities of a like a million or more. However chances are you
> have already many of those in your home.
 
Ok, I know what you mean. As you say they usually have inscrutable names
like Hitachi XM7FB194910JJ29-3 and aren't available to anyone buying in
quantities of a bajillion (professional term) or fewer
bitrex <bitrex@de.lete.earthlink.net>: Dec 31 09:14AM -0500

On 12/30/2017 06:23 PM, David Brown wrote:
> Last I heard, there was minimal C++ library support for avr-gcc, and
> thus things like exceptions don't work.  (Header libraries are fine, of
> course.)
 
Right, but it's a non-issue. There's no OS or true multitasking (there
are 'multitasking' libraries for 8-bit processors but it would probably
be better to call them multiprocessing/threading libraries, all you
usually get is register-saving context switching plus some type of queue
for inter-process communications. Where would one throw an exception to,
and who would catch it?
 
> It's just that /if/ you have made a C compiler for them, and you already
> have a C++ front end for your ARM targets (or whatever), then supporting
> virtual methods (or any other C++ feature) is not actually that much work.
 
Virtual methods are pretty efficient on the AVR; each virtual method in
a class or structure results in a "hidden" 2 byte vtable entry, then to
execute IIRC it's a 2 clock instruction to load the vtable entry into
the "Z" register from program memory, and then a 2 clock instruction to
indirect-jump to the function address
Dombo <dombo@disposable.invalid>: Dec 31 03:34PM +0100

Op 31-Dec-17 om 0:23 schreef David Brown:
>> The 8051 does have a multiply instruction.
 
> There are many 8051 variants - I think only some have multiply hardware.
> (Even if they have multiply hardware, 8051 cores are still depressing!).
 
I have a databook from 1984 which mentions that the 8051 has a multiply
instruction; therefore I'm inclined to believe that the MUL instruction
has been a integral part of the 8051 instruction set right from the
start. Though their are a huge number of 8051 variants, I believe the
difference is mostly in the peripherals and not so much in the core
instruction set. I agree that the 8051 isn't exactly pretty from the
programmers perspective. In its defense it's from an era when
microcontrollers were typically programmed in assembly, not C.
 
> I don't expect anyone intentionally planned to make a C++ compiler for
> an AVR tiny!
 
I think the C++ support for the 8-bit AVR is mostly a "lucky"
side-effect of using GCC. In theory it should be relatively easy to also
support the other programming languages GCC supports (Fortran, Ada,
Go...) on the AVR.
 
> But the AVR family are all supported by gcc - once you
> have the C compiler working for them, the basic C++ support is free.
 
That is largely true for GCC because it has a relatively clear
separation of the programming language dependent front-end and the
processor dependent back-end. However this is not necessarily the case
for compilers that are not GCC based.
 
>> less necessary.
 
> That is certainly true. But support for C++ (at least baring
> exceptions) is not much harder than supporting C.
 
Only if your compiler is GCC or CLang based, or at least if you have a
suitable C++ front-end that can be easily bolted on to your compiler. If
you are writing a compiler from scratch I think you are going to find
supporting C++ a lot harder than supporting just C. For example I don't
expect C++ support for the 8-bit PIC microcontrollers (given your
comments about the 8051 I can guess how you feel about that family),
simply because the MPLAB XC8 doesn't appear to be GCC based, hence
supporting C++ would be a rather costly proposition with little reward.
 
For the really low-end processors (4-bit, few bytes RAM, a kilobyte or
so of program memory and a little bit of I/O) there isn't even really a
point in creating a C compiler for it.
David Brown <david.brown@hesbynett.no>: Dec 31 05:06PM +0100

On 31/12/17 15:34, Dombo wrote:
> start. Though their are a huge number of 8051 variants, I believe the
> difference is mostly in the peripherals and not so much in the core
> instruction set.
 
There are a surprising number of variants in the instruction set and key
registers too, such as additional accumulators, pointer registers, and
even addressing modes. But it is unlikely that they will be missing
features from the original 8051 - if you say it had a multiply
instruction from the beginning, then I expect you are right if you say
they have it. My actual experience of using 8051's is not that wide - I
avoid them whenever possible.
 
> I agree that the 8051 isn't exactly pretty from the
> programmers perspective. In its defense it's from an era when
> microcontrollers were typically programmed in assembly, not C.
 
The 8051 was quite an old-fashioned design when it came out (as was the
8086 - Intel have been innovative in their implementations and
production processes, but quite conservative and old-fashioned in many
of their ISA designs). What bugs me about the 8051 is not so much that
it is painful to use in C (and in assembly), but that some manufacturers
of systems-on-a-chip still, to this day, put 8051 cores in their
designs. The problem is hardware designers that make nice radio
devices, or programmable motion sensors, or configurable analogue parts,
and think "we should put a microcontroller in this chip to make it more
flexible. Which one will we choose? I know - an 8051. Everyone likes
those". They never bother talking to the poor sod that has to program
them - nor the development company that has to splash out multiple $K
for bug-ridden development tools that belong in the last century
(because "everyone has Keil's 8051 compiler").
 
There we go - rant over. I don't like 8051's, and I don't like when
manufacturers make me use them (or chase me away from good peripherals
due to their poor choice of cpu core).
 
> side-effect of using GCC. In theory it should be relatively easy to also
> support the other programming languages GCC supports (Fortran, Ada,
> Go...) on the AVR.
 
Yes, that is mostly correct. There have been some people who have
actively contributed to gcc C++ on the AVR, but they would not have
bothered if they hadn't got most of it free with the gcc C AVR port.
There are also people programming AVR's in Ada, in the same way. (I
haven't heard of anyone using Fortran or Go on the AVR. But maybe there
is someone out there trying it - after all, there is at least one Linux
system running on an AVR Mega.)
 
> separation of the programming language dependent front-end and the
> processor dependent back-end. However this is not necessarily the case
> for compilers that are not GCC based.
 
It is also true for clang/llvm. And the original C++ "compiler" was a
C++ to C translator. You can implement C++ (at least excluding
exceptions) without a code generation beyond what you need for C -
although some C++ specific features would be useful for efficiency. But
you are certainly correct that other compilers could be structured
differently in a way that makes C++ support harder.
 
 
> comments about the 8051 I can guess how you feel about that family),
> simply because the MPLAB XC8 doesn't appear to be GCC based, hence
> supporting C++ would be a rather costly proposition with little reward.
 
Moving from a C-only compiler for a PIC16 to provide C++ support would
certainly be a lot of effort for little return. But some of the other
big embedded toolchain manufacturers already have C++ support - IAR
springs to mind. I expect that for them, supporting C++ on their PIC16
compiler would not be a huge job. It might still not be worth the
effort, of course - it still costs time and money, and the market is
going to be very small.
 
> For the really low-end processors (4-bit, few bytes RAM, a kilobyte or
> so of program memory and a little bit of I/O) there isn't even really a
> point in creating a C compiler for it.
 
I have once used an AVR Tiny with no ram other than the 32 8-bit
registers, and 2K (IIRC) flash. I programmed it in C, using gcc. I
suppose I could have used C++ :-)
Hergen Lehmann <hlehmann.expires.5-11@snafu.de>: Dec 31 05:47PM +0100

Am 31.12.2017 um 17:06 schrieb David Brown:
 
> of systems-on-a-chip still, to this day, put 8051 cores in their
> designs.  The problem is hardware designers that make nice radio
> devices, or programmable motion sensors, or configurable analogue parts,
 
Well, an 8051 core is very small (doesn't require much space on the
silicon) and VHDL sources are available from various sources for free or
very low cost.
 
If it does suit the purpose of basically acting as the bootloader for
some configurable analog front-end chip, why bothering with something
more complex, which requires you to pay royalities and sign NDAs?
Dombo <dombo@disposable.invalid>: Dec 31 06:13PM +0100

Op 31-Dec-17 om 14:53 schreef David Brown:
> between a 4-bit core and an 8-bit (or even 16-bit or 32-bit) core is
> too small now with smaller processes and many free or cheaply
> licensed cpu cores.
 
It true that the cost reductions in higher end of the market squeezes
the lower end of the market. Especially if the volume isn't extremely
high you see 32-bit processors are being used where with a bit of effort
a 8-bit processor could do the job as well. Lower NRE, shorter time to
market, easier grow path to more advanced versions of product may very
well outweigh a small difference in BOM cost.
 
However at the most extreme end of the market (very high volume/very low
retail price) every fraction of a cent still counts, and there is no
thing like a "too small cost difference".
 
> play a tune, or plastic giveaway toys with a kid's comic) the
> peripherals like a timer or two and a DAC or PWM with amplifier cost
> a lot more than the cpu core in terms of die space.
 
It is true that for applications that must drive a relatively heavy load
the output transistor(s) are relatively large. Also the bonding pads
take up percentage wise quite a bit of space on a small die. However
4-bit microcontrollers tend to have very few peripherals. Timers and PWM
circuitry typically do not require more die space than the core and the
associated RAM and ROM memory. A DAC (whose resistor network would
occupy quite a bit of die real-estate) is usually omitted as PWM is for
those applications good enough.
 
Also those applications typically don't use the smaller, more advanced
(& more expensive) processes. That means the core, ROM and RAM still
takes up quite a bit of die space. Hence when every fraction of cent is
relevant it still pays to have very low-end microcontroller that can do
the job. Also for extremely low power applications (like clock,
thermometer...etc.) a dedicated 4-bit processor can still have an edge
compared to a more general purpose 8- or 32-bit processor.
 
Sometimes you find 4-bit microcontrollers in places were you would not
expect a microcontroller in the first place, like in my toothbrush.
Given its functionality (on/off/charge) I'd expect a few discretes would
suffice, yet apparently a 4-bit microcontroller was more economical, but
something like a general purpose 8-pin PIC apparently too expensive.
 
> the amount of memory or other peripherals. It is not uncommon to
> have quite a bit of ROM - far more than the flash sizes of an
> off-the-shelf ATTiny.
 
Once we are talking about more than a few kilobytes of memory, we are no
longer talking about a market that is targeted by the bottom-end
microcontrollers that may only cost a few cents.
 
> be far too expensive.
 
> The last 4-bit microcontroller family that was available to mere
> mortals was from Atmel - I've forgotten the name of it.
 
Atmel is/was hardly the benchmark for the very low-end & cost sensitive
market. The 8-bit AVRs are relatively expensive. They are popular in the
hobbyist scene due to the easy availability of the chips, tools &
documentation and more recently the Arduino kits, but you don't find
8-bit AVRs that often in high volume products. At the real bottom end of
the microcontroller market you find different players than the familiar
players of the higher end microcontrollers (like Microchip, ST,
Freescale....etc.).
 
Either way for C++ this has little to no relevance. If I were to write a
general purpose C++ library these days, I wouldn't be too bothered how
well it would do on anything less than a contemporary 32-bit processor.
Given how the market is developing even the 16-bit microcontroller
families like the PIC24 and MSP430 don't appear to have a very bright
future ahead of them.
Vir Campestris <vir.campestris@invalid.invalid>: Dec 31 05:34PM

On 29/12/2017 22:16, Robert Wessel wrote:
> the Z-80, or their contemporaries, the 6800 and 6502. For examples of
> more current architectures without a multiplier, there are the low end
> PICs and the smaller AVRs.
 
My apologies. I haven't used one since ... 1982? and I seem to have
forgotten the instruction set.
 
The smallest thing I've used recently is a MIPS router chip.
 
With a Gig of ram... so not all that small!
 
Andy
Ian Collins <ian-news@hotmail.com>: Jan 01 11:31AM +1300

On 01/01/2018 05:06 AM, David Brown wrote:
 
> There we go - rant over. I don't like 8051's, and I don't like when
> manufacturers make me use them (or chase me away from good peripherals
> due to their poor choice of cpu core).
 
As one of the lucky few to get hold of preproduction prototype 8751s
back in the early 80s I have to disagree! It was a big step up from the
8748s we had been using. I never had the (dubious) pleasure of
programming one in C, but had great fun writing complex assembly
solutions in the 4K of EPROM available to us. Bit addressable memory
was incredibly useful for the kind of products we were building at the
time, but I've no idea how is is exploited from C or C++.
 
--
Ian.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Dec 31 12:01PM

On Thu, 2017-12-28, Richard wrote:
>>coding style and let me learn more about how they work?
 
> It is unclear if you are asking how to *implement* std::vector, etc.,
> or if you are asking how to *use* the standard library.
 
Yes, it's unclear.
 
 
> For the former, I would recommend any basic book on algorithms and
> data structures. There are plenty of these as they are core computer
> science and not specific to C++.
 
Well ... it seems to me that implementing e.g. std::list is 50% about
understanding the general concept of linked lists, and 50% about
fitting it into the C++ language and its concept of containers.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
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)