- Beginners questions regarding argument transferral and finding all available functions (linux) - 12 Updates
- This will work or not? - 6 Updates
- "Unicode" - 7 Updates
| BartC <bc@freeuk.com>: Sep 01 10:17AM +0100 On 31/08/2016 21:33, Richard wrote: >> (With some compilers you can just give them the .dll files; no library >> needed.) > Which ones? I think gcc, Tiny C and g++. -- Bartc |
| "R.Wieser" <address@not.available>: Sep 01 11:38AM +0200 Andy, > Can you read assembler? I think so. > bar(pserver); /* Disassembly will show a single push of */ > /* a 32 or 64 bit address onto the stack */ You're cheating here. :-) The devil is in the details. PUSH pserver is quite a bit different than PUSH [pserver] > pserver is on any architecture you are likely to come across >a single register containing the address of server. Correct. Though under Assembly "pserver" is nothing more than a design-time label, being converted at compile-time to a fixed address pointing at a bit of memory where its 'contents' are stored. Contents which than point to the actual "server" record. Now do you understand my request for dereferencing ? This is basic Assembly. Talk to your teachers. :-) Regards, Rudy Wieser -- Origional message: Vir Campestris <vir.campestris@invalid.invalid> schreef in berichtnieuws KpCdnaiHZ8iocljKnZ2dnUU78avNnZ2d@brightview.co.uk... > On 30/08/2016 09:09, R.Wieser wrote: > > I'm sorry, but I disagree with you. Just consider the difference between > > and > > struct hostent *server; > > I regard your above statement true for the first, not the latter. As far as > > I can tell for the latter "server" is the addres of the variable which holds > > the address to the "hostent" structure (hence the need for dereferencing). |
| BartC <bc@freeuk.com>: Sep 01 10:55AM +0100 On 01/09/2016 10:38, R.Wieser wrote: > being converted at compile-time to a fixed address pointing at a bit of > memory where its 'contents' are stored. Contents which than point to the > actual "server" record. The definition for pserver was as a pointer variable initialised to the address of a struct (&server). On x86, a push of that variable would be of the form PUSH [pserver]. If register-resident, it would be PUSH Rn. On x86, it would be MOV RCX,[pserver] or MOV RCX,Rn. If the compiler recognised that pserver at that point contained only &server, then it could perhaps optimise. But on x86 you can't directly push an address (neither when static, nor when the offset of a local frame variable); it would be two instructions. On x86, it would be MOV RCX,&server or LEA RCX,[...]. > Now do you understand my request for dereferencing ? There is no dereferencing in this case as a dereference would yield the entire struct. That is not what is happening. The only dereference might be the normal one where in a high-level language you write A and the generated native code is MOV R0,[A] rather than MOV R0,A. But that is so common that you never even think about it. -- Bartc |
| BartC <bc@freeuk.com>: Sep 01 11:00AM +0100 On 01/09/2016 10:55, BartC wrote: > RCX,[pserver] or MOV RCX,Rn. > frame variable); it would be two instructions. On x86, it would be MOV > RCX,&server or LEA RCX,[...]. I meant x64 for these two. x64 passes the first 4 or 6 arguments in registers. -- Bartc |
| "R.Wieser" <address@not.available>: Sep 01 12:22PM +0200 Jerry, > Yes, but you only posted partial code, and even then you changed the > types, function names, etc. Are we supposed to read your mind as to > what the code *really is*? I don't think so. Nope. I posted all the code that was involved in the problem. And yes, I changed the type. On purpose, because that type is the one I needed in the receiving function. As for the function name, do you think you would have been more happy with "write" (as in to an open (file) handle) ? I think you would have been none-the-wiser than you are now -- but most likely would go on a (unwanted!) tangent on how I should not be writing the contents of that "hostent" structure to somewhere that way ... > But you have a problem because you're not passing an unsigned > char * to the function; rather you're passing a hostent*. So, you are trying to tell me me that the "(unsigned char*)" actually doesn't do anything at all ? Really ? As far as I'm concerned the "unsigned char *" and "hostent*" typing just tell you the "preferred usage" of the data pointed to by the address involved. Nothing more. And no, that turned out not the be the problem *at all*. > The two are *not the same thing*. Well, not to the compiler. To the machine the executable is going to run on ? It does not even have any concept of data typing. :-) Regards, Rudy Wieser Jerry Stuckle <jstucklex@attglobal.net> schreef in berichtnieuws nq58a5$akc$1@jstuckle.eternal-september.org... > >> function takes a type server*, then it should work as > >> I explained > > Ehrmm .... In my first post in this thread I did show how I call the foobar > > function, indicating I'm attempting to coerce the provided variable into an > same thing*. > > If the argument defined in the foobar function itself would be of a > > different type I would (as far as I know) get a compile-time error because |
| "R.Wieser" <address@not.available>: Sep 01 12:39PM +0200 Jerry, > It WORK'S WHEN YOU DO IT RIGHT. THAN TELL ME HOW TO FIGURE OUT WHAT I DID WRONG .... instead of keeping hammering me that it *should* work, but not coming up with *any* "hey, try this. What result do you get ?" that could shed light on what the problem might be. Heck, now, with 20-20 vision I can tell that just a few lines of example code could have made clear where I was taking a wrong turn. The only reason I did not try to write such code myself (yes, did think about it) is that, atb that time, I did not assume I understood enough of indirection to be able to write such a testing without running into the same problem. Regards, Rudy Wieser -- Origional message: Jerry Stuckle <jstucklex@attglobal.net> schreef in berichtnieuws nq58g7$akc$2@jstuckle.eternal-september.org... > It WORK'S WHEN YOU DO IT RIGHT. > Rather than argue with everyone, post the *REAL CODE* that fails. Not > some partial code that we're supposed to use to guess what you really need. > And please - GET A GOOD C++ BOOK. You can't learn by googling the internet. |
| "R.Wieser" <address@not.available>: Sep 01 01:03PM +0200 Jerry, > Yes, we READ it. But you posted INCOMPLETE and > INCORRECT information. Go blow a horse. Incomplete ? You simply are not capable of working with the info you got. The info was-and-is correct. And no, you not being capable to understand why someone would make such a typecast doesn't make it incorrect, it only indicates you have a limited imagination. Regards, Rudy Wieser -- Origional message: Jerry Stuckle <jstucklex@attglobal.net> schreef in berichtnieuws nq58ll$akc$3@jstuckle.eternal-september.org... > On 8/30/2016 3:38 PM, R.Wieser wrote: > > For all people that tried to help me find a solution to that "server" > > variable problem, it turns out to be rather simple, and due to a mistake > > made by me. > > Yes!, I'm one of those people that does not run away when he has made one, > >> foobar( (unsigned char*) server->h_addr, ... ) > > *Both* the "first" and "only" descriptions where wrong. Next to that > > "h_addr" isn't even a field in that hostent record, but in a ipv4/ipv6 table > > that the hostent record holds a pointer to, and *noone* here noticed any of |
| "R.Wieser" <address@not.available>: Sep 01 01:36PM +0200 Reinhardt, > Problem of comprehensive reading? I don't think so. > Since do never showed any prototype for your function, we > do not know Yes you do. And if you look at your own quoted material I've explained why, and how. Short explanation: if the offered parameter and the receiving argument have different types the compiler would throw an error. Thus the prototype can be inferred from the call, which I included in my inital post. Apart from that, what other info do you think you need ? And if you say "just all of the rest of your code" I'm going to presume you have no clue, and are just on a fishing expedition. And what is it with you guys that when I tell you that that code is of no consequence to the problem you simply *refuse* to accept that ? What if I would tell you that that "foobar" function opens a pipe, sends bytes thru it (pointed to by the first argument, with the second argument to the foobar function being the ammount) and than closes the pipe ? How would that help to get the problem into focus ? I don't think it would. Hence me not including it. Believe me, I've got enough experience in seeing threads being poissoned by people who want to talk about *everything* in regard to the offered (full) code, but for the problem the code was posted for. > At least your self confidence does not seem to be lacking. You say that as if its a bad thing. :-) Regards, Rudy Wieser -- Origional message: Reinhardt Behm <rbehm@hushmail.com> schreef in berichtnieuws nq5n7g$d5k$1@dont-email.me... > >> parameter, we can not really explain it. From what you write > >> it seems it expect a pointer to a char (char*). > > Huh? In the first line you tell me you do not know, and in the second you > > tell me you do .... :-) > Problem of comprehensive reading? > Since do never showed any prototype for your function, we do not know and I > >> "*server" is a "struct hostent", assuming it has been set > >> correctly and "server" is a pointer to struct hostent. > > With all the "not working" going on I'm not sure if I understand that. I > >> a pointer is not just an address. It also has the property > >> to point to a certain type. > > You mean why all that type-casting is neccesary ? Yes, I'm aware of that > >> One tip: If you think it is to much effort to show something > >> more of your code, > > Its not about effort. I could just grab the whole sourcefile and dump in > > in the next message. I consider that to be offensive -- as if you do not > >> then just show us at least the definition of such functions > >> because it not irrelevant. > > I thought I did so in my first message in this thread, but I did not do so > > explicitily. I however posted calling the function itself: > > foobar( (unsigned char*) server->h_addr, ... ) > > As far as I'm aware you cannot call a function with an argument of a type > > void foobar(unsigned char* argument , .....) > >> Or show us the compiler message. > > Although I did not copy-paste, I mentioned the compile-time error messages > >> to > > a > >> char (char*). That would explain that the first form "server->h_addr" is > > correctly > >> and "server" is a pointer to struct hostent. > >> To me it looks as if you do not know that in C (or C++) a pointer is not > >> just an address. It also has the property to point to a certain type. > >> So if your function foo expects a char pointer, meaning it is defined as > >> anything. > >> This is true even if your variable "server" contains the address (as a > >> bit pattern) of the first byte of some struct hostent which by chance is > > different. > >> That willlead to your compiler complaining. > >> One tip: If you think it is to much effort to show something more of your > >> code,then just show us at least the definition of such functions because |
| David Brown <david.brown@hesbynett.no>: Sep 01 02:00PM +0200 On 01/09/16 13:36, R.Wieser wrote: >> At least your self confidence does not seem to be lacking. > You say that as if its a bad thing. :-) In this case, it /is/ a bad thing. Misplaced self-confidence is stopping you from learning. It is pretty clear from the this thread that you are missing some important understandings about pointers in C++. Other people have given you various explanations, all of which would have made sense to you if you understood the basics here. But you don't know the difference between addresses and objects, or how to get from one to the other. Ignorance is a solvable problem - ask the right questions, listen to the answers, and learn. But pig-headed ignorance, an insistence that you've tried everything already, and insulting people who try to help you - that is not going to fix anything. So if you really want to learn, you have two choices. One is to go away and study C++ - read some books, take some courses, and learn the language. The other is to ask appropriate questions, and work /politely/ and /respectfully/ with people who are willing to spend their free time helping others. However you are working, a key point is to get a small, self-contained code snippet that illustrates your problem. It must contain /all/ relevant information - the information that other people tell you is relevant, not just the bits that /you/ think are relevant. A good guide is to use this site with an online code editor and compiler: <http://gcc.godbolt.org/#> Your snippet is ready when people can paste it directly into that page, and either compile the code or see exactly what error message is causing you trouble. After the way you have treated some of the group's regulars, I'd be surprised if they bothered to try to help you again - but there will be some people who will give you hints once you have posted code. |
| "R.Wieser" <address@not.available>: Sep 01 02:15PM +0200 Bart, > > Heck, why do you think both "." and "->" exist to access > > a strucures fields ? > "P -> m" is just a neater way of writing of (*P).m. I read that too. So, should than (*P) not return the addres of the structure itself ? As mentioned in my first message, that does not even pass the compiler. > S.m means that S is a struct, not a pointer. To me "S" is just a static, typed address of a struct. Put simpler: If its referring to something thats stored in memory than its a pointer, otherwise its a constant. I guess my other languages knowledge is interfering here. :-\ > In your OP, you didn't give the declaration of the function that > you want to pass your struct pointer to Currently two other people said the same, and I give you the same answer: As far as I can tell the declaration of that function can be inferred from the way I called it: if the offered parameter does not match the receiving arguments type the compiler will throw an error. > (nor of the struct itself), Really ? You mean that, next to having posted how I declared that "server" variable, I should have copy-pasted the contents of the header-file regarding to the "hostent" structure too ? > so it's difficult to know exactly how it ought to be passed. I'm not sure which problem you might be referring to. Mind you, I already mentioned that the call as proveded in the OP did work. That means including that typecasting. Regards, Rudy Wieser -- Origional message: BartC <bc@freeuk.com> schreef in berichtnieuws nq6a4l$rb$1@dont-email.me... > On 30/08/2016 19:34, R.Wieser wrote: > >> Then you don't yet understand the fundamentals of the language. > > It could also be that I have a better understanding of what goes on below > > than you do. > > You see, you do not seem to understand the difference between a structures > > address, and a variable *used as* a pointer *to hold* some other variables > If S is a struct variable (as in struct hostent S), then &S is the > struct's address. A variable to hold it might be 'struct hostent *P'. > > When you say "server *is* the address" you are right. But it is the address > > fundamental things about it, and just throw something at it to get it > > silently dereferenced to get at the actual structure. > > Heck, why do you think both "." and "->" exist to access a strucures fields |
| "R.Wieser" <address@not.available>: Sep 01 02:37PM +0200 BartC, > The definition for pserver was as a pointer variable initialised > to the address of a struct (&server). And as the contents of "pserver" are most likely stored somewhere in memory "pserver" is a pointer in itself -- to its contents. Contents which in turn point to the memory where the structure resides. > On x86, a push of that variable would be of the > form PUSH [pserver]. Correct. And I don't know about you, but to me that looks like dereferencing. > There is no dereferencing in this case as a dereference > would yield the entire struct. So, the result of that above push is infact the whole structure ? I don't think so. To me it looks that what you would have on the stack is simply the address of (aka: a pointer to) where the structure is stored in memory. But I think this is a semantics problem: High-level programmers often confound the name of a variable with its contents. In cases like this that does throw a wrench into my understanding what the blazes is actually ment. :-\ Regards, Rudy Wieser -- Origional message: BartC <bc@freeuk.com> schreef in berichtnieuws nq8tvc$2ri$1@dont-email.me... > >> a single register containing the address of server. > > Correct. > > Though under Assembly "pserver" is nothing more than a design-time label, > > being converted at compile-time to a fixed address pointing at a bit of > > memory where its 'contents' are stored. Contents which than point to the |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Sep 01 01:39PM +0100 On Thu, 1 Sep 2016 14:15:27 +0200 > > "P -> m" is just a neater way of writing of (*P).m. > I read that too. So, should than (*P) not return the addres of the > structure itself ? See below. > If its referring to something thats stored in memory than its a > pointer, otherwise its a constant. I guess my other languages > knowledge is interfering here. :-\ Why don't you stop arguing and get out a book. Your "to me ..." is ridiculous. It doesn't matter what 'S' is to you, it is what the C or C++ standards specify which counts. '(*P)' does not "return the addres (sic) of the structure"; it does the opposite. '*' is the dereferencing operator, and *P evaluates to the struct pointed to by 'P'. 'P' is a pointer. Pointers hold addresses. You have repeatedly been told this. You repeatedly think you know better. You don't. You also have an misconceived (and I think probably entirely inverted) notion of what the word "dereference" means. The 'S' in 'S.m' is not "just a static, typed address of a struct". 'S' is the name of a variable which represents the struct itself. '.' is the dot operator providing access to the members of that struct. The '->' operator happens to dereference a pointer to a struct and provide access to the members of the struct at the same time. Your stubborn refusal to actually learn the language (and indeed to read the answers you have been given) and instead endlessly to hypothesise about it is astonishing. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Sep 01 02:28AM +0200 On 31.08.2016 14:59, Melzzzzz wrote: > }; > I am not sure if this will work, so if someone has clear explanation > why it will work (or not) , I would be grateful. Formally there can be padding (except before the first item), and therefore formally you're in UB-land. And the formal UB means that an impractical compiler, a perverse compiler, can treat this as an opportunity to optimize away all of the checking. After all if it incurs UB, then in a correct program it would never be executed. So to the perverse compiler it's just dead code. But assuming a non-perverse compiler, you can simply static_assert( sizeof( Problem ) == 4*sizeof( uint32_t ) ); ... and, under the no perversity assumption, that makes the code portable in the sense that sometime in the future it simply won't compile on the so far not yet created system where it wouldn't work. Note: the /order/ of the items in memory is guaranteed, because there is no intervening access specifier. • • • All that said, a safe alternative is to do this: #include <algorithm> #include <array> #include <stdint.h> namespace my { using std::array; struct Problem { using Item = uint32_t; struct Id{ enum Enum{ a, b, c, d, _ }; }; array<Item, Id::_> items; auto item( Id::Enum const id ) -> Item& { return items[id]; } auto item( Id::Enum const id ) const -> Item const& { return items[id]; } auto check_it_in_change_resistant_way() const -> bool { auto const p_last_item = &items[Id::_ - 1]; for( auto p = &items[Id::a]; p != p_last_item; ++p ) { if( *p > 0 ) { return true; } } return false; } auto check_it_directly() const -> bool { return (items[0] || items[1] || items[2]); } }; } // namespace my Cheers & hth., - Alf |
| Jerry Stuckle <jstucklex@attglobal.net>: Aug 31 11:17PM -0400 On 8/31/2016 1:29 PM, David Brown wrote: > part of the "as if" rule - compilers can generate anything they want, as > long as the code runs "as if" it followed the abstract machine and C or > C++ rules directly. Incorrect. Order of data members in the struct must be as they are declared in the struct. There may be padding between the members, but the order cannot change. Compilers cannot "generate anything they want as long as the runs as if". They are bound by other rules. > local variable without ever referring to their addresses, not only can > the compiler swap a and b, but it can put them in registers, or even > omit one of the members altogether if it can be "optimised away". That is not the only reason compilers have to allocate members in the specified order. Reading/writing binary files is another. And the compilation of source file "A" has no idea if the compilation of source file "B" uses any of the above. So even though "A" doesn't use any of these features, the compiler cannot reorder members of a struct. And the same is true in C. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| David Brown <david.brown@hesbynett.no>: Sep 01 09:07AM +0200 On 31/08/16 22:52, Chris Vine wrote: > C11, except that if there are padding bytes they can have a trap > representation (§6.2.6.1/6 and /7 of C11 read with footnote 95 of > §6.5.2.3/3 if you want the reference). Yes, that's how I remember the standards. C90 standards did not allow this sort of access to different parts of the union, but most implementations did - and programmers relied on that as a way of changing types without changing the underlying representation. So the C99 (after the TC's) standard put it in. But I guess C++ gets most of its C stuff from C90. > The latter (trap > representations) can be ignored on any architecture running C++. Is that guaranteed by the C++ standards, or is it just that no one has made a C++ compiler for one of the weird architectures that has trap representations? (In this particular case, the types in question were uint32_t and uint64_t - these cannot have trap representations in C. But pointers, signed integers, and floating point types could have trap representations, in theory.) > GCC > and clang permit type punning through unions in C++ in the same way as > an extension. I believe the OP was using one of these (since he uses __attribute__). > To make it portable I guess you could put the code in a separate > translation unit compiled as C11 and link to that in your C++ code. It > seems a bit overly complicated though. Indeed. Sometimes it makes sense to use implementation-specific behaviour (like "it works with gcc and clang"). But that's up to the OP and his requirements. |
| David Brown <david.brown@hesbynett.no>: Sep 01 09:35AM +0200 On 01/09/16 05:17, Jerry Stuckle wrote: > the order cannot change. > Compilers cannot "generate anything they want as long as the runs as > if". They are bound by other rules. No, to a very large extent they /can/ generate anything they want - as long as the code runs "as if" it followed the rules strictly. This is one of the key points for an optimising compiler. >> omit one of the members altogether if it can be "optimised away". > That is not the only reason compilers have to allocate members in the > specified order. Reading/writing binary files is another. And how do you intend to read or write binary data between a file and a struct, without taking the address of that struct? When you are doing operations like that, the compiler must make sure the ordering of the struct members follows the rules of the language (C or C++), and the ABI requirements of the platform. But when code does nothing (with defined behaviour) that could be influenced by the ordering of the struct members, the compiler is free to re-order those members. And with function-local data, it might well do exactly that. > And the compilation of source file "A" has no idea if the compilation of > source file "B" uses any of the above. So even though "A" doesn't use > any of these features, the compiler cannot reorder members of a struct. The compiler can only re-order data if it can be sure it is safe to do so - that is the same as for any optimisation. Since it does not know what "B" will do with the data in "A", then typically it would not be able to re-arrange the members. However, an implementation /could/ do so - as long as it tracks this difference, such as via information in the object file files, and ensures the complete result runs "as if" the order was fixed. That's not going to happen in a compiler for big systems, where object file formats follow known ABIs, but it is perfectly allowed for specialised tools. > And the same is true in C. That, at least, is correct - the rules here for C and C++ are the same. |
| "Öö Tiib" <ootiib@hot.ee>: Sep 01 01:28AM -0700 On Thursday, 1 September 2016 03:29:35 UTC+3, Alf P. Steinbach wrote: > never be executed. So to the perverse compiler it's just dead code. > But assuming a non-perverse compiler, you can simply > static_assert( sizeof( Problem ) == 4*sizeof( uint32_t ) ); That assertion will fail on all platforms; it may be that you missed the 'c' being 'uint64_t'. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Sep 01 12:30PM +0100 On Thu, 01 Sep 2016 09:07:27 +0200 > uint64_t - these cannot have trap representations in C. But pointers, > signed integers, and floating point types could have trap > representations, in theory.) A trap representation is (according to C) "an object representation that need not represent a value of the object type". §6.2.6.1/5 goes on to say that "Certain object representations need not represent a value of the object type. If the stored value of an object has such a representation and is read by an lvalue expression that does not have character type, the behavior is undefined. If such a representation is produced by a side effect that modifies all or any part of the object by an lvalue expression that does not have character type, the behavior is undefined. Such a representation is called a trap representation". The resulting undefined behaviour may include the triggering of hardware traps. C++ has not yet imported the "trap representation" from C: C++ instead refers to uninitialised values of trivial types having "an indeterminate value". In particular it does not so far permit access to indeterminate values via the character types, but by the same token I do not think that any architecture running C++ has hardware-level traps for invalid signed arithmetic or floating points or for copying invalid pointer values (but see below on pointers). §8.5/12 of the draft C++17 standard sort-of introduces something similar to the rules on trap representations by stating (in a convoluted fashion) that if you evaluate an indeterminate value except via a narrow unsigned character type you have undefined behaviour. Since "evaluate" includes copy, this seems inconsistent with the welcome licence given by §3.7.4.2/4 of C++14/17 which makes copying a pointer value which is neither the null pointer nor the address of a valid object implementation-defined behaviour instead of undefined behaviour (C++14 tips it hat to C hardware traps by indicating that that implementation-defined behaviour may include having "a system-generated runtime fault"). No one yet seems to have spotted this inconsistency. Chris |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Sep 01 01:50AM +0200 On 31.08.2016 22:31, Richard wrote: >> handle file names with anything other than narrow chars [...] > C++ had been around for 15+ years before it was standardized. The > standardization process was capturing existing practice more Uhm, that's bollocks. One would have to search long and hard and wide to find a standardization with more pure innovation than C++98. Namespaces, exceptions, most of the standard library. Even compared to the ARM it was extreme. Compiler vendors had a hard time catching up, authors detailed their choices of practically necessary compatibility trade-offs so as to not confer wrong impressions to their readers. > than it was introducing fundamental changes to the language. Uhm, ditto. Sorry. Cheers & hth., - ALf |
| Daniel <danielaparker@gmail.com>: Aug 31 06:47PM -0700 On Wednesday, August 31, 2016 at 7:50:59 PM UTC-4, Alf P. Steinbach wrote: > One would have to search long and hard and wide to find a > standardization with more pure innovation than C++98. > Namespaces, exceptions, most of the standard library and export :-) Best regards, Daniel |
| Jerry Stuckle <jstucklex@attglobal.net>: Aug 31 11:06PM -0400 On 8/31/2016 7:50 PM, Alf P. Steinbach wrote: > Uhm, that's bollocks. > One would have to search long and hard and wide to find a > standardization with more pure innovation than C++98. Sorry, Richard is correct. C++98 was NOT the first standard. > the ARM it was extreme. Compiler vendors had a hard time catching up, > authors detailed their choices of practically necessary compatibility > trade-offs so as to not confer wrong impressions to their readers. None of these were included in the initial C++ standard. > Uhm, ditto. Sorry. > Cheers & hth., > - ALf Later standards added these feature. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Ian Collins <ian-news@hotmail.com>: Sep 01 03:21PM +1200 On 09/ 1/16 03:06 PM, Jerry Stuckle wrote: >> One would have to search long and hard and wide to find a >> standardization with more pure innovation than C++98. > Sorry, Richard is correct. C++98 was NOT the first standard. So what was? -- Ian |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Sep 01 08:02AM +0200 On 01.09.2016 05:06, Jerry Stuckle wrote: >> One would have to search long and hard and wide to find a >> standardization with more pure innovation than C++98. > Sorry, Richard is correct. C++98 was NOT the first standard. I think Richard's error was just one of perception. He shouldn't have posted those claims without checking, or including qualifier phrases such as "I believe". You, on the other hand, are just blatantly counter-factual. Why do you persist in that? Why not try to be a bit constructive and maybe learn something? Baffled, - Alf |
| David Brown <david.brown@hesbynett.no>: Sep 01 10:09AM +0200 On 01/09/16 05:06, Jerry Stuckle wrote: >> One would have to search long and hard and wide to find a >> standardization with more pure innovation than C++98. > Sorry, Richard is correct. C++98 was NOT the first standard. C++98 was the first /ISO/ standard of C++. The first edition of "The C++ Programming Language" (1985) was the defining reference for the language, but it was not an official standard. The same applies to the ARM (1990). C++ itself was from 1983 (after 4 years as "C with classes"). So Richard is correct on the timings, C++ had been around for 15 years before it was standardised (C++98). I can't comment on how much C++98 standardised existing practice or invented new features - I don't know the tools of that era well enough. Alf and Richard can fight that one if they want. It is quite possible that the ARM was based on existing practice, and certainly likely that "The C++ Programming Language" was based on existing practice. But those were not standards, and they were not written 15 or so years after C++ was first developed. >> authors detailed their choices of practically necessary compatibility >> trade-offs so as to not confer wrong impressions to their readers. > None of these were included in the initial C++ standard. The initial C++ standard was C++98, and included those features. |
| "Osmium" <r124c4u102@comcast.net>: Sep 01 06:01AM -0500 "Daniel" <danielaparker@gmail.com> wrote in message news:4a13de5a-a74e-4edc-bf54-64a23514c0f4@googlegroups.com... >> standardization with more pure innovation than C++98. >> Namespaces, exceptions, most of the standard library > and export :-) LOL |
| 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