- problem with std::string::c_str() - 3 Updates
- Why should a "c" programmer learn c++ ? (V2) - 13 Updates
- Why should a "c" programmer learn c++ ? - 9 Updates
RM <robert_magdziarz@wp.pl>: Sep 11 09:11PM +0200 I have such problem: string exec_system(string command) { /* here command == "php /home/robert/dirtyphp_cpp/build/apps/../../src/_dirtyphp2.php /home/robert/rozgloszenia/application_edit_obfuscated/config/constants.php " */ const char *cmd = command.c_str(); /* here problem: cmd == "p" */ array<char, 128> buffer; string result = ""; // cmd's stdout unique_ptr<FILE, decltype(&pclose)> pipe(popen(cmd, "r"), pclose); if (!pipe) { throw runtime_error("popen() failed!"); } while (fgets(buffer.data(), buffer.size(), pipe.get()) != nullptr) { result += buffer.data(); } return result; } I don't understand why cmd == "p". Please help. I use g++ in Linux Mint (g++ (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0). |
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Sep 11 01:18PM -0700 > } > I don't understand why cmd == "p". Please help. > I use g++ in Linux Mint (g++ (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0). I can't reproduce the problem. How do you know that cmd == "p" at that point? It should be "php /home/..." (and it is when I run a similar program on my system). Can you construct a small self-contained program whose output demonstrates the problem? If cmd is "p" at that point, then the rest of the function should be irrelevant, and you should be able to remove it from your test case. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
Cholo Lennon <chololennon@hotmail.com>: Sep 11 06:45PM -0300 On 9/11/20 4:11 PM, RM wrote: > " */ > const char *cmd = command.c_str(); > /* here problem: cmd == "p" */ What are the values of command[1], command[2], and cmd[2], cmd[3]? (I assume that command[0] == 'p' and cmd[1] == 0). It's weird that c_str truncates the string in that way. Maybe 'command' contains a double byte string... -- Cholo Lennon Bs.As. ARG |
Juha Nieminen <nospam@thanks.invalid>: Sep 11 07:38AM > start with) - in others, "public domain" is only possible when the > copyright time has run out. I don't know which viewpoint is held by > "most" countries. I think there's a lot of confusion about what it means, legally speaking, when an author declares his work to be "public domain". Most of this confusion sparks from the fact that many people don't understand what "public domain" means, or how copyright law works (in most countries). "Public domain" means "has no copyright". It's not a usage license. It does not mean "I give you permission to do with this work of mine whatever you want". It would mean, if the law supported the concept, "this work is not copyrighted". Many people think that one can simply declare his own work to "not be copyrighted" and that makes it so. Maybe that was the case in the 60's or so, when works had to be explicitly registered as copyrighted, but in most jurisdictions that hasn't been the case in like 40 or so years. In most jurisdictions copyright is automatic and, moreover, there is no mechanism by which you can get rid of it and toss the work into the public domain. That being said, it's very probable that no court will judge in your favor if you publish something under "public domain" and then try to sue someone for copyright infringement: Yes, you still own the copyright to your work, and no, "public domain" is not a valid usage license, but most courts will probably read intent, the spirit of the law, rather than the letter of it, and judge against you. Courts will probably judge that by saying "this is in the public domain" you implicitly gave permission for people to use it, and trying to sue them afterwards would be akin go fraud. Anyway, if you want to publish your work with a very free usage license, it's safest to use one of the existing copyright-based licenses (like the Creative Commons ones). This makes it clearest from a legal perspective. |
"Öö Tiib" <ootiib@hot.ee>: Sep 11 01:37AM -0700 On Friday, 11 September 2020 10:38:35 UTC+3, Juha Nieminen wrote: > it's safest to use one of the existing copyright-based licenses (like > the Creative Commons ones). This makes it clearest from a legal > perspective. That is obviously rather tedious to write every time we post some code snippet for to illustrate our (doomed to be ambiguous) words that it is licensed under Creative Commons. I don't think it is needed. Our attempt to sue someone with such snippet would maximally result with sued party stopping usage of verbatim equivalent of said snippet. I suspect that real courts would support our copyright claims only if someone second used equivalent to that particular snippet to sue ourselves or some third party with incorrect copyright claim. |
David Brown <david.brown@hesbynett.no>: Sep 11 10:45AM +0200 On 11/09/2020 09:38, Juha Nieminen wrote: > when an author declares his work to be "public domain". Most of this > confusion sparks from the fact that many people don't understand what > "public domain" means, or how copyright law works (in most countries). Agreed. > "Public domain" means "has no copyright". It's not a usage license. Yes. > does not mean "I give you permission to do with this work of mine > whatever you want". It would mean, if the law supported the concept, > "this work is not copyrighted". AFAIK all countries support the idea of public domain - there is always a time limit on copyright. The actual limit varies - a typical limit is "death of the author plus 50 years". After that time limit, the work falls into public domain. So Shakespeare's works are all public domain in all countries. Particular renderings of the text can still be copyrighted - you can't buy a Complete Shakespeare, scan the pages, and publish it as your own. But you /can/ copy out the text into your PC, print it out yourself and publish it. (That's what Project Gutenberg has done.) (The USA has had a series of "Mickey Mouse" laws - any time the copyright on Mickey Mouse is nearing its end, they raise the limit.) What varies significantly between countries is whether you can make something "public domain" /before/ the copyright runs out. Some countries let you do this, others do not. > copyrighted" and that makes it so. Maybe that was the case in the 60's > or so, when works had to be explicitly registered as copyrighted, but > in most jurisdictions that hasn't been the case in like 40 or so years. The Berne convention is from the 19'th century, and under that you never need an explicit copyright notice for work to be copyrighted. (Though it is typically vastly easier to prove and enforce copyright if there is an explicit notice.) The USA, as I understand it, used to be different and required explicit copyright notices - otherwise the work was automatically public domain. This was an exception from the Berne convention. But they changed to follow the convention in 1989. Some other countries have had varying degrees to which they implement the convention in their laws. > In most jurisdictions copyright is automatic and, moreover, there is > no mechanism by which you can get rid of it and toss the work into the > public domain. With the proviso that I don't know if "most" is accurate or it should be "some jurisdictions", this is almost correct. Copyrighted work becomes public domain automatically after a given time. (Assuming we don't find a way to live forever, and assuming the Mickey Mouse laws eventually stop - or at least other countries stop following the USA.) > will probably judge that by saying "this is in the public domain" you > implicitly gave permission for people to use it, and trying to sue > them afterwards would be akin go fraud. This will also vary from jurisdiction to jurisdiction - some legal systems put more favour on the letter of the law, some emphasise the wording of the author's statements, others pay more attention to the authors presumed intentions. It's also going to be heavily influenced by the lawyers involved. (Writing your intentions clearly is usually a good idea, however.) > it's safest to use one of the existing copyright-based licenses (like > the Creative Commons ones). This makes it clearest from a legal > perspective. Agreed - it makes a lot of sense to copy existing practice from groups that have had /real/ lawyers from many countries look at the issues, and copy practices from the Creative Commons folk, the GPL licensing and copyright notices, or perhaps the NoSQL project if you want to make some software "public domain". |
Juha Nieminen <nospam@thanks.invalid>: Sep 11 09:49AM > copy practices from the Creative Commons folk, the GPL licensing and > copyright notices, or perhaps the NoSQL project if you want to make some > software "public domain". Just don't do what the SQLite project does: They essentially punish you if you live in a jurisdiction that doesn't recognize "public domain" as a valid license and you want to do things by the book. Their official license is "public domain" (ignoring the fact that it isn't a license), and for reasons known to nobody they seemingly refuse to offer the software under any other open source license. If, however, you live in a jurisdiction that doesn't support the ability of individuals to publish work in the public domain, and you want to do things by the book, they generously offer to sell you a legally-binding individual license for the meager price of US$6000. This is not just me saying it, or reading between the lines or interpreting. This is explicitly stated by them. They say that they will sell you a legal license (for US$6000) if: "You are using SQLite in a jurisdiction that does not recognize the right of an author to dedicate their work to the public domain." Why they can't offer you the software eg. using the MIT or BSD license, or any other such license, is a completely mystery. Essentially they are punishing you for living in the wrong jurisdiction and wanting to do the legally right thing. |
"Öö Tiib" <ootiib@hot.ee>: Sep 11 03:27AM -0700 On Friday, 11 September 2020 12:49:26 UTC+3, Juha Nieminen wrote: > or any other such license, is a completely mystery. Essentially they are > punishing you for living in the wrong jurisdiction and wanting to do the > legally right thing. Perhaps by their (unsaid out) philosophy traders in such jurisdiction deserve to be taxed for the laws (or maybe even whole existence) of that jurisdiction. Indeed ... whom else to tax for unfair trademark, copyright and/or patent laws but traders? Said taxing process however is trouble and for it to be profitable they ask for sum that SQLite is anyway well worth of in my experience. |
antispam@math.uni.wroc.pl: Sep 11 11:24AM > a time limit on copyright. The actual limit varies - a typical limit is > "death of the author plus 50 years". After that time limit, the work > falls into public domain. In Poland once copyright expires work effectively goes to state. One is supposed to pay a fee for use of such works. There is state agency for collecting fees and there is official rate, something like few percent of price. I do not know if anybody actually pays and if they have rules what to do with derived works. But certainly this is a big legal landmine for anybody who thinks in terms of "public domain". -- Waldek Hebisch |
Richard Damon <Richard@Damon-Family.org>: Sep 11 08:01AM -0400 On 9/11/20 5:49 AM, Juha Nieminen wrote: > or any other such license, is a completely mystery. Essentially they are > punishing you for living in the wrong jurisdiction and wanting to do the > legally right thing. One issue is that to provide a license under MIT or BSD, they would need to assert their rights under copyright to give such a license, which might impede their ability to disclaim that right in the other jurisdictions. They might want to look at the CC0 license, which I think deals with these sorts of issues, but not being a lawyer or knowing all their thought, they may have reasons not to want or be able to use it. |
Anton Shepelev <anton.txt@g{oogle}mail.com>: Sep 11 04:16PM +0300 Juha Nieminen: > essentially punish you if you live in a jurisdiction that > doesn't recognize "public domain" as a valid license and > you want to do things by the book. It makes no sense to me. No one may deny me the right to give away a creative work of mine to the whole world under no conditions, restrictions, or limitations. No one may force me to put any limitations on the usage by others of my creative work. > fact that it isn't a license), and for reasons known to > nobody they seemingly refuse to offer the software under > any other open source license. Perhaps they should consider a license equivalent to public domain: https://en.wikipedia.org/wiki/Public-domain-equivalent_license -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived] |
Anton Shepelev <anton.txt@g{oogle}mail.com>: Sep 11 04:33PM +0300 Richard Damon to Anton Shepelev: > freely available to anyone with a TV, and if you used a > cheap VCR you could easily have recorded the program. No > essential difference. The essential difference from the TV is that a TV broadcast is temporal: it is available only at a specific time. Recording it on a persistent medium for later re- broadcasting, or distribution surely makes it more available than it was. > Freely available isn't the same as free of copyright. Yes. My idea about copyring is that it is partly about one's right to increase the availability of a creative work, you cannot increase the availability of a Usenet post, except the way Google does by maintaing an archive of it so that it remains available after it has expired from all Usenet servers. You can, however, increase the availability of a printed book, a music record publiched on CD, or an article retained behind a paywall. > What you can't do (probably, depending on things like far > use) would be make something like a book out of things > said. What is the essential difference from the quoting with a proper attribution of a single Usenet post, entire, on a personal web page? Can one be sued for that? -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived] |
Juha Nieminen <nospam@thanks.invalid>: Sep 11 05:08PM > copyright and/or patent laws but traders? Said taxing process however > is trouble and for it to be profitable they ask for sum that SQLite > is anyway well worth of in my experience. If they have a problem with countries/jurisdictions where you cannot publish works into the public domain, why do they want to punish the people living in those places who have done nothing wrong? It's not their fault. |
Juha Nieminen <nospam@thanks.invalid>: Sep 11 05:11PM > no conditions, restrictions, or limitations. No one may > force me to put any limitations on the usage by others of my > creative work. You can publish your work under a (legally-binding) license that imposes no restrictions, limitations or requirements. It's just that it has to be copyright-based in order to be recognized in many countries in the modern world. It's just a formality, really. |
James Kuyper <jameskuyper@alumni.caltech.edu>: Sep 11 04:55PM -0400 On 9/11/20 9:16 AM, Anton Shepelev wrote: > no conditions, restrictions, or limitations. No one may > force me to put any limitations on the usage by others of my > creative work. You've got it backwards. The problem is that no one can safely take advantage of the fact that you've released your creative work, because (in those jurisdictions which don't recognize "public domain") you're always free to change your mind and enforce your copyright. |
Eli the Bearded <*@eli.users.panix.com>: Sep 11 09:45PM > or any other such license, is a completely mystery. Essentially they are > punishing you for living in the wrong jurisdiction and wanting to do the > legally right thing. They are giving people in those areas a US$6000 incentive to lobby for law changes. I don't know about them, but I know when I'm wearing my public software development hat, I really don't want to think hard about international laws and their implication on my choice of license. Elijah ------ has never contributed anything as widely useful as sqlite |
Juha Nieminen <nospam@thanks.invalid>: Sep 11 07:27AM > i++; > int* i = (int*) ptr; > i* = 2; Can you give an example of any C++ compiler on any platform that would behave differently when compiling those as C++ than when compiling them as C? |
David Brown <david.brown@hesbynett.no>: Sep 11 11:08AM +0200 On 11/09/2020 09:27, Juha Nieminen wrote: > Can you give an example of any C++ compiler on any platform that would > behave differently when compiling those as C++ than when compiling them > as C? Alternatively, an explanation (ideally with references) as to why they might be different would be nice. I am not entirely fluent in the details of POD, standard layout, trivial types, etc., (especially as these details have changed with different standards versions), but for scalar types like "int" this kind of thing should work identically in C and C++ AFAIK. That is, the first two should work fine (assuming malloc returns something other than a null pointer), and the third is fine as long as "ptr" holds an address that points to an "int" (that bit was skipped by the quotation snipping). |
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Sep 11 11:17AM +0100 On Fri, 11 Sep 2020 11:08:57 +0200 > > as C? > Alternatively, an explanation (ideally with references) as to why they > might be different would be nice. They are different in C++20 because that is what the C++ standard committee hath wrought, foolishly in my opinion. This code ought to be valid C++. (The reference is [intro.object]/1, if that is what you were after.) > types, etc., (especially as these details have changed with different > standards versions), but for scalar types like "int" this kind of thing > should work identically in C and C++ AFAIK. I agree that it should do. Unfortunately it doesn't. > something other than a null pointer), and the third is fine as long as > "ptr" holds an address that points to an "int" (that bit was skipped by > the quotation snipping). The third (snipped) example is invalid because according to C++17 and C++20 you can only carry out pointer arithmatic on a pointer which results in an address within the range of an array (including one past the end) ([expr.add]/4) and "Otherwise, the behavior is undefined" for pointer arithmetic. Memory returned by malloc (and operator new for that matter) is not an array. You are right that an object that is not an array element whose address is taken by the unary & operator is considered to belong to an array with one element of type T for the purposes of pointer arithmetic on the value returned by that operator: in such a case you can add 1 to the address of the object. That doesn't apply here, but where it does, given an object 'o' then '&o+1' can be valid whereas '&o+2' is not, even in cases where the result of both point within properly malloc'ed memory. Even for '&o+1' to work you would have to construct an object (here an int) in the malloc'ed memory using placement new first. Note that this is not about dereferencing the pointer (where obviously an object is required) but about the mere act of carrying out pointer arithmetic on a pointer. Frankly, this result is unintuitive and absurd. Pointer arithmetic within memory duly allocated by malloc or operator new should be allowed. And, to go back to the original point, C++ is incompatible with C on this, apparently deliberately so. You cannot "do it in the exact same way in C++". |
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Sep 11 11:49AM +0100 On Fri, 11 Sep 2020 11:17:46 +0100 > malloc'ed memory using placement new first. Note that this is not about > dereferencing the pointer (where obviously an object is required) but > about the mere act of carrying out pointer arithmetic on a pointer. Sorry I got my numbering wrong. The preceding two paragraphs are about the second example, not the third. As to the third example, you can according to C++20 construct an int in a dynamically allocated array of char (the example I gave). But to access it by a cast of the char* (as opposed to using the pointer to int returned by the use of placement new to construct the int), you must use std::launder as well as make the cast, because the pointers are not pointer-interconvertible - it is no longer sufficient just to comply with the strict aliasing rules as in C. This is the combined effect of [basic.compound]/4 and [ptr.launder]. The pointer-interconvertibility rules were brought in in C++17. |
boltar@nuttyella.co.uk: Sep 11 11:21AM On Fri, 11 Sep 2020 11:17:46 +0100 >malloc'ed memory using placement new first. Note that this is not about >dereferencing the pointer (where obviously an object is required) but >about the mere act of carrying out pointer arithmetic on a pointer. It makes you wonder if the committee really don't like pointers at all and are making it as obnoxious as possible to use them in order to discourage it and eventually deprecate them. Given how tricky pointers can be for learners all it'll do is make even more potential C++ devs flee to other languages with fewer BS rules-for-their- own-sake and sphagetti syntax. Certainly if I was starting out today and wondering which language to learn C++ would not be top of the list. |
David Brown <david.brown@hesbynett.no>: Sep 11 05:28PM +0200 On 11/09/2020 12:17, Chris Vine wrote: > committee hath wrought, foolishly in my opinion. This code ought to be > valid C++. (The reference is [intro.object]/1, if that is what you > were after.) I haven't looked in detail at C++20 (and I haven't read all the details of any other C++ standards - there's just too much there). Usually I get what I need from looking at the lists of changes and new features, along with <https://en.cppreference.com>, and nothing I have seen in these sources indicates anything you mention here. But now I have N4860 open, and I'm looking at 6.7.2 "intro.object". In p10-p12, there is a discussion of "implicitly creating objects" and there is this example: #include <cstdlib> struct X { int a, b; }; X *make_x() { // The call to std::malloc implicitly creates an object of type X // and its subobjects a and b, and returns a pointer to that X // object // (or an object that is pointer-interconvertible (6.8.2) with it), // in order to give the subsequent class member access operations // defined behavior. X *p = (X*)std::malloc(sizeof(struct X)); p->a = 1; p->b = 2; return p } I can't see any way to rationalise this example being valid and defined behaviour, but your first two examples being a problem or in any way different from the behaviour in C. (I'm not saying you are wrong here - but you might be, and I think we both hope that you /are/ wrong.) > results in an address within the range of an array (including one past > the end) ([expr.add]/4) and "Otherwise, the behavior is undefined" for > pointer arithmetic. That is the same in C. (A pointer to a single object can be viewed as an array of length 1 in this context.) And the third example doesn't have pointer arithmetic, and it is not snipped. Are you talking about a different example that has got lost somewhere, and are counting differently from me? (Maybe you are counting from zero...) > considered to belong to an array with one element of type T for the > purposes of pointer arithmetic on the value returned by that operator: > in such a case you can add 1 to the address of the object. In the section of N4860 referenced, it is clear that "malloc" is considered to "implicitly create objects", and that you can cast the returned void* pointer to other types and access data that way. > That doesn't apply here, but where it does, given an object 'o' then > '&o+1' can be valid whereas '&o+2' is not, even in cases where the > result of both point within properly malloc'ed memory. Are you suggesting that if you do a malloc (of suitable size) and cast the returned pointer to T*, this is only valid as a pointer to a single T and not the start of an array of T's ? I don't believe that is correct, though I haven't dug through chapter and verse, and I don't think the meaning has changed for different C++ standards or between C and C++. |
James Kuyper <jameskuyper@alumni.caltech.edu>: Sep 11 11:44AM -0400 On 9/11/20 6:17 AM, Chris Vine wrote: >>>> i++; >>>> int* i = (int*) ptr; >>>> i* = 2; ... > committee hath wrought, foolishly in my opinion. This code ought to be > valid C++. (The reference is [intro.object]/1, if that is what you > were after.) Where can I obtain a copy of that version of the standard? I couldn't find it on the working group's web site, which is where I usually go. It doesn't have to be the actual current standard; a sufficiently recent draft would be sufficient. ... > the end) ([expr.add]/4) and "Otherwise, the behavior is undefined" for > pointer arithmetic. Memory returned by malloc (and operator new for > that matter) is not an array. Do you mean "second example"? Tracing back, only the second example involve pointer arithmentic (i++). That is just as much a problem with C as with C++. For pointer values, they both define i++ as equivalent to i=i+1, except that 'i' is evaluated only once, and they both define addition of integer values to pointer values in terms of a containing array; if there's no such array, there's no applicable definition of what the addition means. > purposes of pointer arithmetic on the value returned by that operator: > in such a case you can add 1 to the address of the object. > That doesn't apply here, In n3797.pdf, the relevant wording is "For the purposes of these operators, a pointer to a nonarray object behaves the same as a pointer to the first element of an array of length one with the type of the object as its element type." (5.7p4), which seems perfectly applicable. That wording does not include the part from your explanation requiring that it be the result of the unary & operator; all that's required is that it be "a pointer to a non-array object". How is the wording in C++2020 different, to render that clause inapplicable? |
Brian Wood <woodbrian77@gmail.com>: Sep 11 10:22AM -0700 On Wednesday, September 9, 2020 at 11:45:34 AM UTC-5, olcott wrote: > the c++ that "c" programmer ever needs to know. > -- > Copyright 2020 Pete Olcott There's some effort to tie OOP to C++ like an anchor around it's neck. Probably this comes from authors of competing languages. The jury is still out on 2020 C++, so I suggest using an older version. Brian Ebenezer Enterprises https://github.com/Ebenezer-group/onwards |
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Sep 11 07:57PM +0100 On Fri, 11 Sep 2020 11:44:54 -0400 > find it on the working group's web site, which is where I usually go. It > doesn't have to be the actual current standard; a sufficiently recent > draft would be sufficient. The closest to C++20 was N4849. Stimulated by David Brown I have now got hold of N4860. Assuming that that actually represents the final version of C++20 put to international ballot, it has considerable changes voted in at the last moment, probably in answer to http://wg21.link/p0593r6 , which pointed out the considerable deficiencies in C++17 and in the then draft standard respecting trivial objects. If so, that is surprising, as P0593r6 said: "This paper did not complete LWG review in time for C++20. However, the functionality contained herein can be split into two portions: The core language change that gives defined behavior to various constructs that have historically been assumed to work, and ... The author suggests that the committee considers adopting the former portion of this paper as a Defect Report, for possible inclusion into the C++20 IS, and that the latter portion be deferred to C++23." Maybe N4860 is C++20 plus defect report but it looks like the final version. No doubt in due course all will be revealed. > evaluated only once, and they both define addition of integer values to > pointer values in terms of a containing array; if there's no such array, > there's no applicable definition of what the addition means. Yes I did mean the second example. The point about C11 is that §6.5.6/8 deals with pointer arithmetic concerning arrays and the words "otherwise, the behavior is undefined" seem to have been read in the context of arrays only and not applying to raw malloc'ed memory. That reading is impossible with C++20's [expr.add]/4. The issue with C is also that the "effective type" of raw memory is normally the type of the first object constructed in it (§6.5/6 of C11), so in a sense malloc'ed memory becomes an array in C by being treated as an array. (Somewhat akin to the new C++ implicit-lifetime types.) At any rate I doubt you will find any C programmer, or member of the C standard committee, who thinks that: int* i = (int*) malloc(2 * sizeof(int)); i++; is undefined behaviour because of §6.5.6/8, as in C it is the only way of getting to the second element in advance of constructing the first one. If N4860 is the definitive text for C++20, then I think this construct now has defined behaviour in C++20 because an array would implicitly be taken to arise for the case of an array of trivial types, given that array types are now implicit-lifetime types. I will need to consider revised [intro.object]/10 further on this. > that it be the result of the unary & operator; all that's required is > that it be "a pointer to a non-array object". How is the wording in > C++2020 different, to render that clause inapplicable? My meaning was that it was not applicable to my example, which did not involve construction of an object. |
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