- Why do we have type& and type* - 3 Updates
- Simple Proxy Collector... - 1 Update
- Variable declaration syntax - 11 Updates
- [Jesus Loves You] Tag for filtering - 8 Updates
- PVS-Studio is now available on macOS: 64 weaknesses in the Apple's XNU Kernel - 1 Update
- why is "std::string propBulkRow = 0;" legal ? - 1 Update
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 10 10:26AM -0400 What is the C++ reasoning for having both & and * types? Why not just have * types? -- Thank you! | Indianapolis, Indiana | God is love -- 1 John 4:7-9 Rick C. Hodgin | http://www.libsf.org/ | http://tinyurl.com/yaogvqhj ------------------------------------------------------------------------- Software: LSA, LSC, Debi, RDC/CAlive, ES/1, ES/2, VJr, VFrP, Logician Hardware: Arxoda Desktop CPU, Arxita Embedded CPU, Arlina Compute FPGA |
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 10 03:33PM +0100 On 10/04/2018 15:26, Rick C. Hodgin wrote: > What is the C++ reasoning for having both & and * types? Why not just > have * types? Because epistemological sausages travel at the speed of light in a vacuum. How is this possible? They have no mass and always face the Flying Spaghetti Monster (the one true God). /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." |
jameskuyper@verizon.net: Apr 10 08:39AM -0700 On Tuesday, April 10, 2018 at 10:27:03 AM UTC-4, Rick C. Hodgin wrote: > ------------------------------------------------------------------------- > Software: LSA, LSC, Debi, RDC/CAlive, ES/1, ES/2, VJr, VFrP, Logician > Hardware: Arxoda Desktop CPU, Arxita Embedded CPU, Arlina Compute FPGA C++ references are semantically closely related to const pointers. Internally, code using a reference will often be implemented identically to equivalent code using a const pointer. However, references are syntactically more convenient than const pointers. C++ retains pointers both for backwards compatibility with C, and because it's possible for a pointer to be null, which is a convenient way of conveying the information that "there is nothing to be pointed at"; there's no simple way to use C++ references to convey the information that "there is nothing to be referred to". That's a matter of deliberate design, not an oversight. The C++ rules governing references were designed to justify the assumption that a reference always refers to an actual object of the specified type, which makes it easier to write safe code. |
Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 10 03:22PM On Mon, 2018-04-09, Chris M. Thomasson wrote: > to have less traffic: > https://groups.google.com/forum/#!forum/lock-free > Argh! Surely there's /some/ place where this is discussed openly? Although if the forum is C-oriented, I imagine mentioning C++ can be difficult. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
David Brown <david.brown@hesbynett.no>: Apr 10 03:16PM +0200 On 10/04/18 14:09, bartc wrote: >> standards forbid to declare more than one thing per declaration. > Why don't more people who write coding standards design language syntax? > They seem to have more sense. Language designers are aiming for flexibility - let programmers use the language the way they want, for the tasks they want. Coding standards authors are aiming to restrict those freedoms, often in a manner that depends on the task in hand. A coding standard suitable for small-systems embedded design would be useless for general purpose "big computer" programming, and vice versa. And of course people have wildly different ideas of what is good coding practice and clear presentation. C was designed with a "trust the programmer" philosophy. That has let the language be used in far more areas than were originally envisioned by the designers. But it also means the programmer has to be more responsible, because the language won't stop them writing a mess. |
David Brown <david.brown@hesbynett.no>: Apr 10 03:18PM +0200 On 10/04/18 15:04, Scott Lurndal wrote: >> standards forbid to declare more than one thing per declaration. > What's a "real C++ code base"? We've several million lines of > actively developed C++ code that uses raw arrays and raw pointers. I can't tell you what Öö thinks is "real C++", but I'd guess that in your "real C++ code base" you don't declare variables of type T and T* in the same line. |
David Brown <david.brown@hesbynett.no>: Apr 10 03:36PM +0200 On 10/04/18 14:11, Rick C. Hodgin wrote: > of that type. It would remove the need for the existing pointer declar- > ation syntax which can be prickly, and it would not break existing code > because the new form would have to be enabled to be used. I think it is fine to say that the type (including the pointer bit) has to be on the left, separated by a space. I merely think you should avoid there being ambiguity here - the declarations should be clearly one thing, clearly the other thing, or an error. (C compatible mode excluded, of course.) > the dot form because CAlive makes . and -> synonymous, and also allows > instances of --> or ---> to be the same as -> for alignment): > CWhatever [p], [[pp]]; // Same as CWhatever* p; CWhatever** pp; This is all getting back to the same confusion - and then making it worse. Pick /one/ method for declaring pointers. It does not really matter if that is "CWhatever* p", "CWhatever [p]", "CWhatever^ p", "pointer to CWhatever p". But the key thing is to have a single clear and unambiguous syntax. What you don't want is for some people to be writing "CWhatever* p", others to be writing "CWhatever [p]", and neither being able to understand the other's code because they never use that syntax themselves. And don't allow mixing different levels of pointedness in the same declaration. It is not needed, and just makes code harder to follow. One thing you should also try to decide upon is how you view pointer and types. For "int * p;", the usual C philosophy is "*p is an int - therefore you write int *p", while the usual C++ philosophy is "p is of type pointer-to-int - therefore you write int* p". Both C and C++ conflate these concepts but they have a bias towards one of them. In designing a new language, I would aim to view it from one side. Personally, I'd chose the "p is of type pointer-to-int", but a syntax like "int [p]" matches the C idea better. It is up to you to choose one. You should also think about initialisation syntaxes. A strange thing about C is that when you write: int x; int *p = &x; you are assigning to /p/, not to "*p". If you wrote "*p = &x" later, it would be an error. I can't see any neat way to have initialisation with declarations of the form "int [p]". So I would prefer to have the pointer as part of the type, and choose a syntax that does not match C in order to avoid misunderstanding - such as: int^ p = &x; > [pp].member; // Same as (*pp)->member, again using . > It's a nod to assembly language, which uses [reg] for indirection, > and an extension of that syntax to [[pp]] for double-indirection. Different assembly languages use different syntaxes. There is nothing wrong with using [p] for indirection, taking inspiration from Intel format x86 assembly, but don't imagine it is universal in assembly. Just don't give multiple optional syntaxes. And be careful about automatically dereferencing pointers to structs or objects - it can be confusing. In Delphi (which is based on Object Pascal), objects are mostly pointers that are automatically dereferenced, but not always - it can be difficult to track which is which. Consider copying C++'s concepts of references and pointers. Consider also the possibility of disbanding pointers altogether, and working /only/ with references. |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 10 06:51AM -0700 On Tuesday, April 10, 2018 at 9:36:55 AM UTC-4, David Brown wrote: > This is all getting back to the same confusion - and then making it > worse. I disagree wholeheartedly, though I'm certain I'm in the minority here in the C++ group. -- Rick C. Hodgin |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 10 06:53AM -0700 On Tuesday, April 10, 2018 at 9:51:17 AM UTC-4, Rick C. Hodgin wrote: > > worse. > I disagree wholeheartedly, though I'm certain I'm in the minority > here in the C++ group. One other thing: CAlive supports traditional C/C++ syntax. Nobody has to use any of these new features I am adding. They exist as one more tool in the toolbox, able to be used for those who see value in that tool. -- Rick C. Hodgin |
scott@slp53.sl.home (Scott Lurndal): Apr 10 02:10PM >I can't tell you what Öö thinks is "real C++", but I'd guess that in >your "real C++ code base" you don't declare variables of type T and T* >in the same line. As a general rule, you're correct, variables are declared one per line. |
scott@slp53.sl.home (Scott Lurndal): Apr 10 02:17PM >that is "CWhatever* p", "CWhatever [p]", "CWhatever^ p", "pointer to >CWhatever p". But the key thing is to have a single clear and >unambiguous syntax. Or you can be more verbose: 08050000 ssp_initialize 08054000PROC; 08055000SHARES 08056000 CONST loader_storage, 08057000 CONST mcp_identification, 08058000 CONST pointer_reference_table, 08059000 VAR queue_storage, 08060000 CONST shared_systems_data; 08061000 08062000VAR 08063000 base_ptr DAT_POINTER := ioat_ptrs.first_element, 08064000 ch_ptr PTR TO CHANNEL_TABLE_ENTRY := nil, 08065000 search_done BOOLEAN := false, 08066000 status_buffer SSP_STATUS, 08067000 status_ptr PTR TO SSP_STATUS := ptr( status_buffer ); 08068000 08069000 08070000 08071000 DO 08072000 FIND ioat_ptr OVER base_ptr..ioat_ptrs.last_element 08073000 INTO ioat_ptrs.base @ 08074000 WHERE ioat_ptr@.primary_hardware_type = shared_system_processor 08075000 THEN 08076000 ch_ptr := ptr( channel_table_ptrs.base @ 08077000 [ioat_ptr @.primary_channel_number] ); 08078000 ch_ptr @.flags.good_firmware_file := false; ... Declarations are obvious "PTR TO <type>" and dereferences are visible (@). |
bartc <bc@freeuk.com>: Apr 10 03:20PM +0100 On 10/04/2018 14:36, David Brown wrote: > So I would prefer to have the pointer as part of the type, and choose a > syntax that does not match C in order to avoid misunderstanding - such as: > int^ p = &x; That's getting on the right lines, depending on dereference syntax. If it's now ^p, then you have the same problem. (Elsewhere I write types strictly left-to-right, with a variable name following if this is a declaration: ref int p := &a ref int p; p := &a The difference between assignment and declaration/initialisation of one variable, is simply that type spec stuck on the left. And the left-to-right form allows building of complex types more naturally in a way that exactly follows the English: ref[]ref int p # pointer to array of pointer to int The only quibble might be whether you stick the variable before or after the type, and with what extra syntax. What you wouldn't do is stick the variable name IN THE MIDDLE of the type, and even end up splitting the type into THREE PARTS like the variable 'c' here: int a,b, *c[10]; So you have the 'int', '*', and '[10]' all in different places with respect to the variable name. If someone were to invent this syntax now, you'd think they were having a laugh. And if that wasn't enough, if the parts are numbered 1, 2 and 3, you have to rearrange them as 3, 2, 1 to read off the type, or as 2, 3, 1 if it was (*c)[10].) > Different assembly languages use different syntaxes. There is nothing > wrong with using [p] for indirection, taking inspiration from Intel > format x86 assembly, but don't imagine it is universal in assembly. This is recycling the C (and now also C++) idea of declaration syntax having to mirror expression syntax, which leads to the situation I mentioned above. How about, just keeping it simple: TYPE NAME or, declaring several names with exactly the same type wouldn't be objectionable: TYPE NAME, NAME, NAME And not STILL having part of the type syntax that wraps itself around name. -- bartc |
Ben Bacarisse <ben.usenet@bsb.me.uk>: Apr 10 03:29PM +0100 > You can get a lot worse than that (you can throw in some function > declarations, typedefs, etc.), but such mixes are fortunately rare in > real code - even in C code without coding standards. There is a function declaration in there! (You probably meant a pointer to function, since those start to get more complex.) I think part of the trouble is that so many people learn C "by example". And when coding standards say you should put only one declaration on a line there's no incentive to learn. Because I know that the * is part of little expression-like syntax that revolves around the name being declared, I can't stand seeing char* x; It really grates. It looks like return! x; or return x +1; to me. Given that this is comp.lang.c++ it's worth noting that such derived types are rare in programs that use the standard library so it's often much less of an issue. >> In real C++ code bases it is getting irrelevant because raw arrays >> are rarely used and raw pointers are rarely used... Oh, snap! -- Ben. |
David Brown <david.brown@hesbynett.no>: Apr 10 04:53PM +0200 On 10/04/18 16:29, Ben Bacarisse wrote: >> real code - even in C code without coding standards. > There is a function declaration in there! (You probably meant a pointer > to function, since those start to get more complex.) Let's assume that's what I meant, rather than simply failing to read properly :-) > I think part of the trouble is that so many people learn C "by > example". And when coding standards say you should put only one > declaration on a line there's no incentive to learn. I don't think it is a matter of not learning - I know fine how things work when you have multiple declarations in one line. But mixing concepts together too tightly is never a good idea for clarity. I also think your declarations mostly either have expressive (and therefore somewhat longer) names, a useful comment, an initialiser, or are so local that they are part of a loop (like "for (int i ..."). The lines are long enough, and contain enough information, that one declaration at a time is a good size. There are exceptions, of course. > Because I know that the * is part of little expression-like syntax that > revolves around the name being declared, I can't stand seeing > char* x; To me, that is putting the emphasis on x being a pointer-to-char. I tend to write "char * x;" myself, as I would usually want an initialisation: char * x = &b; I dislike seeing : char *x = &b; because "*x = &b;" would be wrong after the declaration and initialisation. > or > return x +1; > to me. Those two would really annoy me too. |
David Brown <david.brown@hesbynett.no>: Apr 10 05:05PM +0200 On 10/04/18 16:20, bartc wrote: > left-to-right form allows building of complex types more naturally in a > way that exactly follows the English: > ref[]ref int p # pointer to array of pointer to int I'd be inclined to use either keywords or punctuation, rather than a mixture, but that's just preference. I'd also use more spaces. > The only quibble might be whether you stick the variable before or after > the type, and with what extra syntax. You might also want keywords to say that this is a variable declaration (or a block of variable declarations) rather than a statement (or block of statements). Some programming languages require an extra keyword to declare the identifier as a non-constant variable, which I think is a good idea - if I were designing a new language, "variables" would be immutable by default. > type, and even end up splitting the type into THREE PARTS like the > variable 'c' here: > int a,b, *c[10]; Well, /you/ wouldn't do it! Clearly some other people are quite happy with that. In C, the declaration syntax is designed to match the way the variable is used, rather than to emphasis its type. Since the language has postfix and prefix operators, both can occur in the declarations. If I were making a language, I would probably be using much stronger typing than in C and with a bigger emphasis on types - thus having the type entirely before or entirely after the variable name would be natural. > So you have the 'int', '*', and '[10]' all in different places with > respect to the variable name. If someone were to invent this syntax now, > you'd think they were having a laugh. No, you would not - at least, you would not laugh if you understood about language design - as distinct from having designed a couple of simple languages and thinking that they are the only good ways to make a language. |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 10 06:21AM -0700 On Tuesday, April 10, 2018 at 8:21:08 AM UTC-4, Mr Flibble wrote: > No. You use Satan as an excuse to not answer any question that might > conflict with your worldview so Kenny is correct when he says that > religious people can't answer such questions. No, Leigh. Satan really is real. Demons are real. The spirit nature is real. Our flesh cannot see it, but only the effects of it, because we are spiritually dead due to sin. I explain these things to you so you can know the truth, but you reject it. It's why you don't understand or believe the things I say as being true, nor trust the contents of the Bible as being true. You refuse to acknowledge the possibility that something beyond this tangible, physical, flesh-knowing world we live in actually exists. If you ever step away from that place you will then be able to pursue the truth. Until that time, it will totally elude you. -- Rick C. Hodgin |
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 10 02:30PM +0100 On 10/04/2018 14:21, Rick C. Hodgin wrote: > exists. If you ever step away from that place you will then be > able to pursue the truth. Until that time, it will totally elude > you. Evolution mate. Speed of light in a vacuum mate. /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." |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 10 06:48AM -0700 On Tuesday, April 10, 2018 at 9:30:50 AM UTC-4, Mr Flibble wrote: > Evolution mate. Speed of light in a vacuum mate. Ever see "A Fish Called Wanda?" Remember this scene with Otto and Wendy? Wendy: My father was in the Secret Service, Mr. Manfredjinsinjin, and I know perfectly well that you don't keep the general public informed when you are "debriefing KGB defectors in a safe house." Ever see Star Trek Voyager and the episode with the female Q (Q's wife)? FEMALE Q: Try to wrap your minuscule mind around this. These supernovas are actually caused by spatial disruptions within the Continuum, the result of the war. Now, each time a star implodes, a negative density false vacuum is created which actually sucks the surrounding matter into the Continuum. ----- Now, in that same tone picture me saying this to you (as you stand there looking like Otto): Rick: Try to wrap your brain around this, Leigh. Everything you think exists ... it's not the limit of what exists. There's a whole spiritual universe out there beyond this one, here right now at the same time, invisible to your natural eyes but more real than all of this. It's from within that spirit nature that God exists, which is why your miniscule mind cannot fathom God's existence today. But if you'll take even one conscious step away from that permanent magnet you seem affixed to, then you'll be taking your first step to true enlightenment, real understanding, and eternal life. -- Rick C. Hodgin |
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 10 03:23PM +0100 On 10/04/2018 14:48, Rick C. Hodgin wrote: > take even one conscious step away from that permanent magnet > you seem affixed to, then you'll be taking your first step > to true enlightenment, real understanding, and eternal life. Quod gratis asseritur, gratis negatur. What can be asserted without evidence can be dismissed without evidence. https://en.wikipedia.org/wiki/Hitchens%27s_razor Evolution mate. Speed of light in a vacuum mate. /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." |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 10 07:34AM -0700 On Tuesday, April 10, 2018 at 10:23:58 AM UTC-4, Mr Flibble wrote: > > to true enlightenment, real understanding, and eternal life. > Quod gratis asseritur, gratis negatur. > What can be asserted without evidence can be dismissed without evidence. The evidence exists, Leigh. It exists spiritually, not physically. It's what I've been trying to teach you. I used to also believe as you do. So sure I was right. When I came to seek the truth, God gave it to me, and it completely blew everything I previously held out of the water. That's what I'm teaching you. There's more than your flesh knows today. > https://en.wikipedia.org/wiki/Hitchens%27s_razor > Evolution mate. Speed of light in a vacuum mate. God created the entire universe by His word. He could've assembled everything as we see it today, Leigh, just as our video games would load the entire world in as a single scene before game play begins. You understand these concepts fully. You refuse to acknowledge the possibility that God exists and created more than a mere video game using His ability to instantiate everything, and you do so solely because of sin and your love of sin ahead of truth. -- Rick C. Hodgin |
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 10 03:36PM +0100 On 10/04/2018 15:34, Rick C. Hodgin wrote: > you do. So sure I was right. When I came to seek the truth, God > gave it to me, and it completely blew everything I previously held > out of the water. Quod gratis asseritur, gratis negatur. > That's what I'm teaching you. There's more than your flesh knows > today. Quod gratis asseritur, gratis negatur. > God created the entire universe by His word. He could've assembled > everything as we see it today, Leigh, just as our video games would > load the entire world in as a single scene before game play begins. Quod gratis asseritur, gratis negatur. > possibility that God exists and created more than a mere video game > using His ability to instantiate everything, and you do so solely > because of sin and your love of sin ahead of truth. Quod gratis asseritur, gratis negatur. /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." |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 10 07:40AM -0700 On Tuesday, April 10, 2018 at 10:36:50 AM UTC-4, Mr Flibble wrote: > > gave it to me, and it completely blew everything I previously held > > out of the water. > Quod gratis asseritur, gratis negatur. Oro te, ut veritas revelata sunt a Domino. > > That's what I'm teaching you. There's more than your flesh knows > > today. > Quod gratis asseritur, gratis negatur. Oro te, ut veritas revelata sunt a Domino. > > everything as we see it today, Leigh, just as our video games would > > load the entire world in as a single scene before game play begins. > Quod gratis asseritur, gratis negatur. Oro te, ut veritas revelata sunt a Domino. > > using His ability to instantiate everything, and you do so solely > > because of sin and your love of sin ahead of truth. > Quod gratis asseritur, gratis negatur. Oro te, ut veritas revelata sunt a Domino. -- Rick C. Hodgin |
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 10 04:04PM +0100 On 10/04/2018 15:40, Rick C. Hodgin wrote: > Oro te, ut veritas revelata sunt a Domino. Nemo curat. /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." |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 10 07:46AM -0700 On Saturday, March 31, 2018 at 2:51:08 PM UTC-4, Andrey Karpov wrote: > A new version of the PVS-Studio analyzer 6.23 is working under macOS, which allows you to check the projects written in C and C++. Our team decided to perform a XNU Kernel check to coincide it with this event. https://www.viva64.com/en/b/0566/ I continued to use this tool for a few more days and remain thoroughly and completely impressed. All told it found about 300 things in my 35K line app. About 6 of them were legitimate bugs. The rest were cases where I was double-testing a variable, using memcmp() without comparing an entire buffer, copying more data to a structure than did exist in the structure definition (when the structure pointed to a 512- byte block, but only had a few bytes which are the start of the fixed portion of the structure, and the remaining 400+ bytes were always variable). It actually helped solidify one of my projects. It's made it more stable by finding a case where I did this: memset(ptr, 0, sizeof(ptr)); Rather than: memset(ptr, 0, sizeof(*ptr)); And a few others like that. ----- Bottom line: I recommend this tool to everyone who does C/C++ code. It integrated seamlessly with Visual Studio, and was very easy to use. -- Rick C. Hodgin |
"James R. Kuyper" <jameskuyper@verizon.net>: Apr 10 10:07AM -0400 On 04/10/2018 03:11 AM, Barry Schwarz wrote: >> This compiles just fine on Visual C++ 2015. > Because there is an implicit conversion from the integer 0 to the > character '0x00'. You're thinking about the implicit conversion from a null pointer constant (which 0 qualifies as) to a null pointer of any particular type. std::string doesn't have a constructor from a single integer type of any size, not even "char", but it does have a constructor from a char* value. However, the description for that constructor has says:"Requires: s points to an array of at least traits::length(s) + 1 elements of charT." (24.3.2.2p10). Note: this description is for std::basic_string<charT, traits, Allocator>. In the context of std::string, "traits" refers to std::char_traits<char>. As a null pointer, (char*)0 is prohibited from pointing at any object, so it cannot meet that requirement. |
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. |
No comments:
Post a Comment