- Function overloading problem (global versus member) - 2 Updates
- Christianity is a relationship between God and man - 3 Updates
- Function overloading problem (global versus member) - 1 Update
- Inheriting from a class and overriding user-defined conv. operators - 10 Updates
- I am trying to code C++ STL vector, list, queue, pq, map, etc. But i dont know how to start.. - 1 Update
| 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. |
