| Ned Latham <nedlatham@woden.valhalla.oz>: Oct 08 07:35PM -0500 James Kuyper wrote: > has undefined behavior - so the fact that gcc's output meets those > non-existent requirements shouldn't give you the slightest feeling of > safety. None. Whatsoever. I have some searching to do. Thanks a lot. > of code fall into that category. By my count, the latest draft of the > standard that I have access to, N4659.pdf, contains 68 occurrences of > that term. I now have a copy, thanks. I was going to print it, but I think I'll rely on reading it onscreen. > In itself, that's not quite as bad as it sounds - not all of > those occurrences represent distinct reasons for code to have undefined > behavior (though most of them do). One's easy to guess: what happens when terminator-dependent string functions are run over character arrays? > C++ standard library are defined in terms of the behavior of the C > standard library (for instance, <iostream> heavily cross-references > <stdio.h>). Hmm. I avoid almost all of that code, choosing instead low-level file handling and raw character-level I/O using only low-level routines in ctype.h, stdio.h and stdlib.h. > As a result, code which makes no direct use of the C > standard library might have undefined behavior for reasons that you > would have to look at the C standard to understand. As with there being no means in stdio.h for testing file status? I see no way to avoid that problem without portability problems. > There's many ways that function pointers can be involved when code has > undefined behavior. However, there's also many other ways the behavior > can be undefined. Got it. > > for that matter. > Ruling out the existence of any problems in any significant body of code > is essentially impossible. I see "significant" here as subject to opinion. > Detecting problems is often easy, but being > certain that you've found and corrected all such problems is always the > result of self-delusion. Depends on how you treat error conditions. I eschew raising exceptions (I eschew <iostream> because it raises them): instead I use a my own little library, which includes a class that does all I/O with just two functions, Read() and Write(). (All file operations are done by the caller so that the portability bug is removed from the library.) Possible errors in those two methods are few, easy to se, and usually easy to deal with. When an error is detected the class raises an error condition *in the object*, disaqbling it and uniquely describing the error. That's all it does, except that the total number of possible error conditions is 100: it includes flow-on error conditions, making a nice trail to follow. The result is that callers can deal with errors intelligently: they can begin development querying the status of objects after every operation and cut back as regions of code become robust. > You might happen to be right that there are no > remaining defects, but certainty about that fact can't be justified. It can with encapsulation and if all the possibilities for error within a scope are examined. > Such certainty is, however, a very popular delusion. If it's a delusion, I share it. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Oct 08 09:21PM -0400 On 10/8/19 8:35 PM, Ned Latham wrote: > James Kuyper wrote: ... >> behavior (though most of them do). > One's easy to guess: what happens when terminator-dependent string functions > are run over character arrays? "A string is a contiguous sequence of characters terminated by and including the first null character." (7.1.1p1). The term "string" is italicized, an ISO convention indicating that this sentence constitutes the official definition of that term. As a result, if the description of a standard library function describes one of the arguments of that function as pointing at the first character of a string, the behavior is undefined if the corresponding argument points at memory that is not null-terminated. Typically, the actual behavior will involve continuing to search for a null character beyond the end of that object, a search whose results are unpredictable, and likely to result in memory access violations if the search goes on long enough. > Hmm. I avoid almost all of that code, choosing instead low-level file > handling and raw character-level I/O using only low-level routines in > ctype.h, stdio.h and stdlib.h. ctype.h: "In all cases the argument is an int, the value of which shall be representable as an unsigned char or shall equal the value of the macro EOF. If the argument has any other value, the behavior is undefined." stdio.h: 21 occurrences of "the behavior is undefined". 55 occurrences of "shall", most of which impose requirements on programs which, if violated, render the behavior undefined. stdlib.h: 12 occurrences of "the behavior is undefined". 30 occurrences of "shall". ... >> Ruling out the existence of any problems in any significant body of code >> is essentially impossible. > I see "significant" here as subject to opinion. Agreed. |
| Ned Latham <nedlatham@woden.valhalla.oz>: Oct 08 08:38PM -0500 James Kuyper wrote: That was quick, James. Thanks. > to search for a null character beyond the end of that object, a search > whose results are unpredictable, and likely to result in memory access > violations if the search goes on long enough. Which it can very easily. It's a C/C++ language bug, imo, and a pernicious one at that: there's no way to avoid string constants, and if someone misuses a character array as such in code you call, you'd better know the details or a segfault is pretty much inevitable, sooner or later. > ctype.h: "In all cases the argument is an int, the value of which shall > be representable as an unsigned char or shall equal the value of the > macro EOF. If the argument has any other value, the behavior is undefined." Mine are all [0..255], unsigned char. > stdio.h: 21 occurrences of "the behavior is undefined". 55 occurrences > of "shall", most of which impose requirements on programs which, if > violated, render the behavior undefined. Are these quotes from the draft (I haven't done any work yet)? > stdlib.h: 12 occurrences of "the behavior is undefined". 30 occurrences > of "shall". Oof. Thanks again. ----snip---- |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Oct 08 10:15PM -0400 On 10/8/19 9:38 PM, Ned Latham wrote: > That was quick, James. Thanks. >> Ned Latham wrote: >>> James Kuyper wrote: ... >> be representable as an unsigned char or shall equal the value of the >> macro EOF. If the argument has any other value, the behavior is undefined." > Mine are all [0..255], unsigned char. That makes it easy - but many people write code that assumes that "plain char" is unsigned, and which can therefore break if ported to a platform where plain char is signed. What makes this problem harder to notice is the fact that all members of the basic execution character set are required to be positive, even if char is signed. People who don't need to use any members of the extended character set (which includes many people who produce software exclusively for the US market), are likely never to trigger the defects in such code. >> of "shall", most of which impose requirements on programs which, if >> violated, render the behavior undefined. > Are these quotes from the draft (I haven't done any work yet)? Yes, but since the C++ standard incorporates the C standard library by reference (with minor modifications), the relevant draft is a different one from the one I cited before. I should have mentioned that fact. Specifically, those counts are from n1570.pdf, which differs in only minor ways from the final version of C2011. Note: I'm not claiming to have done a perfectly accurate count - my point is merely that there's a lot of those things. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 09 05:45AM +0200 > You really don't appreciate how thoroughgoing the meaning of "undefined > behavior" is. Are you so stupid like Melzzzzz? I'm talking about compile-time semantics and not behaviour at runtime. And it is the same at all points where I wrote "nd->pinCounter = FREE_NODE;". |
| Paavo Helde <myfirstname@osa.pri.ee>: Oct 09 08:45AM +0300 On 9.10.2019 4:38, Ned Latham wrote: > one at that: there's no way to avoid string constants, and if someone > misuses a character array as such in code you call, you'd better know the > details or a segfault is pretty much inevitable, sooner or later. This is one more reason to avoid C-style strings, and functions working with C-style strings, in C++. FYI: there are now convenient ways to write std::string literal constants directly in the code, and there is also std::string_view which can be used to encapsulate any raw character arrays as proper C++ strings. |
| Ned Latham <nedlatham@woden.valhalla.oz>: Oct 09 01:42AM -0500 Paavo Helde wrote: > > details or a segfault is pretty much inevitable, sooner or later. > This is one more reason to avoid C-style strings, and functions working > with C-style strings, in C++. Which is what I do. > FYI: there are now convenient ways to write std::string literal I have my own C++ standard library, preferable by far to the one James mentioned above. > constants directly in the code, and there is also std::string_view which > can be used to encapsulate any raw character arrays as proper C++ strings. My string class does it with a constructor (unsigned char*,unsigned int). |
| Ned Latham <nedlatham@woden.valhalla.oz>: Oct 09 02:50AM -0500 James Kuyper wrote: > minor ways from the final version of C2011. Note: I'm not claiming to > have done a perfectly accurate count - my point is merely that there's a > lot of those things. Well my little library's been in use for seventeen years now, without change for the last six . . . time now to see whether I missed any potential problems. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Oct 09 07:55AM -0700 On Tuesday, October 8, 2019 at 11:45:27 PM UTC-4, Bonita Montero wrote: > > behavior" is. > Are you so stupid like Melzzzzz? I'm talking about compile-time > semantics and not behaviour at runtime. I'm talking about both compile-time and run-time semantics. "Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message)." (3.27). Undefined behavior in other parts of your program is allowed, among many other things, to cause translation of the program to terminate, for instance by resulting in a linker problem such as the one you ran into, so long as that termination is accompanied by a diagnostic (as yours was). The fact that the linker error that you got mentioned a particular line in your program doesn't mean that the code which allowed that that error to occur was on that particular line. It needn't be anywhere near that line. The committee doesn't like specifying that violating a rule has "undefined behavior", because that relieves the implementation of any obligation to diagnose the violation. They only do that when there's a least a few important platforms where a C++ compiler would be desirable, where it would be an unacceptable burden on the implementors to mandate that they diagnose all violations of that rule. If diagnosis of a rule violation is difficult, violation of that rule often has subtle consequences that would be difficult to predict. The place where the violation actually produces noticeable symptoms can often be far removed from the place where the violation occurred. That is why you cannot assume that some small part of your program must have particular semantics, regardless of how the rest of your program is written. As a general rule, a problem in one part of your code producing symptoms that are associated with a very different part of your code is a more likely possibility than a compiler error, though compiler error is also a possibility worth investigating. > And it is the same at all > points where I wrote "nd->pinCounter = FREE_NODE;". If code elsewhere in your program has undefined behavior (a possibility that we cannot rule out, not having seen the rest of your program), then the behavior of your entire program (including the compile-time behavior) is undefined, including each of the points at which it says "nd->pinCounter = FREE_NODE;". Having the behavior be undefined at each of those points would not mean that the behavior is the same at each of those points. "no requirements" includes, as a special case, that there's no requirement that the behavior be the same at each of those locations. If your diagnosis of the problem that you're running into is correct, it should be easy to create a complete program that demonstrates the problem and is simple enough to show this group. If your reason for not bothering to post such an example is supposed to be that you're too lazy to bother doing so, prove it by being too lazy to bother posting a response to this message. You've spent more time posting messages excusing your failure to provide such an example, than it would have taken to create and post one. That is not intelligent laziness. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 09 05:01PM +0200 > execution in a documented manner characteristic of the environment (with > or without the issuance of a diagnostic message), to terminating a > translation or execution (with the issuance of a diagnostic message)." (3.27). All "nd->pinCounter = FREE_NODE;" have the sae compile-time semantics. > the behavior of your entire program (including the compile-time > behavior) is undefined, including each of the points at which it says > "nd->pinCounter = FREE_NODE;". I already told that in one case the compiler is physically reading FREE_NODE and in many other cases not. There's nothing to discuss. That's a bug. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Oct 09 08:19AM -0700 On Wednesday, October 9, 2019 at 11:01:19 AM UTC-4, Bonita Montero wrote: > > or without the issuance of a diagnostic message), to terminating a > > translation or execution (with the issuance of a diagnostic message)." (3.27). > All "nd->pinCounter = FREE_NODE;" have the sae compile-time semantics. Define what those semantics are required to be; give a definition that defies the possibility that the behavior of the entire program is undefined due to a defect in some other part of it. Explain why those requirements continue to apply despite the standard specifying that it imposes "no requirements" on the behavior of such a program. > I already told that in one case the compiler is physically reading > FREE_NODE and in many other cases not. There's nothing to discuss. > That's a bug. Agreed. But is it a bug in the compiler, or a valid consequence of the compiler dealing with a bug elsewhere in your program? Without seeing the rest of your program, I can't be certain - and the certainty you express appears to derive from ignorance of the other possibilities. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 09 05:22PM +0200 > Agreed. But is it a bug in the compiler, or a valid consequence > of the compiler dealing with a bug elsewhere in your program? static const members never need to be defined. And when you don't take their address or a reference to it they're are constant. Why should other program-parts change this? |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 09 05:23PM +0200 > static const members never need to be defined. And when you don't ^ integral |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Oct 09 09:39AM -0700 On Wednesday, October 9, 2019 at 11:22:21 AM UTC-4, Bonita Montero wrote: > static const members never need to be defined. And when you don't > take their address or a reference to it they're are constant. Why > should other program-parts change this? I can't even begin to guess unless I see those other parts - the options are too numerous to describe. But I do know that the presence of undefined behavior anywhere in a program does release an implementation from all requirements, including the requirement to handle even ordinary constants properly, much less static const members. How any particular implementation of C++ might malfunction under such circumstances is hard to predict, but to say it can't malfunction in any particular way is to betray a lack of imagination. Personally, I suspect that the real cause is probably closer to home. You haven't even shown us the declarations of nd or pinCounter yet, much less the contexts in which that expression has occurred. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 09 06:46PM +0200 > I can't even begin to guess unless I see those other parts - ... There's no reason why a non-odr-access should become an odr-access until I change the type of access itself. But I haven't done that. |
| "Öö Tiib" <ootiib@hot.ee>: Oct 09 09:59AM -0700 On Wednesday, 9 October 2019 19:46:35 UTC+3, Bonita Montero wrote: > > I can't even begin to guess unless I see those other parts - ... > There's no reason why a non-odr-access should become an odr-access > until I change the type of access itself. But I haven't done that. Technically compiler is permitted to crash or to hang on case of undefined behavior in code that it compiles. It does that ultra rarely because of high professional standards of its team members, not because of requirements to it. But changing non-odr-access to odr-access of unrelated const isn't crash nor hang so what you complain? |
| Juha Nieminen <nospam@thanks.invalid>: Oct 09 07:02AM > Look at it this way: a lack of women in programming is a clear sign > that we're missing out on talented programmers: people who would be > good at it and who would enjoy it. On what do you base this opinion on? If, for whatever reason, women on average are less interested in computer programming than men, and this is the cause for there being more male programmers, why would inducing women to choose a career path they are not interested in make them "be good at and and enjoy it"? Somehow I get the feeling that you subscribe to the "tabula rasa", or "blank slate" theory. In other words, that there are exactly zero differences between the average man and the average woman, that they have no innate characteristics (eg. in personality, personal interests and talents) and that the only and sole reason for any differences is because society teachest them to be different. Thus it would simply be a question of "teaching women to enjoy programming" to make them enjoy programming and be interested in it and be good at it, as if people's personalities and interests were malleable and completely up to whatever society teaches them and wants them to be. Not only does this idea go against all evidence and studies on the subject, in fact I find it insulting. It considers people to be mindless robots which can be programmed to be whatever we want them to be. Teach them thing X, and they will automatically be interested in thing X and become good at it. Teach them thing Y, and likewise they will become interested in thing Y and become good at it. Like programmable robots with no agency and innate personalities and characteristics. Treat everybody equally, teach everybody the same things, and give everybody the same opportunities to choose their preferred career paths, and allow them to choose whatever they like and want. Don't try to coax people into a particular career path just because you think "we need more people with inconsequential characteristic X in this career path". Treat people as people, not as robots. |
| David Brown <david.brown@hesbynett.no>: Oct 09 10:06AM +0200 On 09/10/2019 09:02, Juha Nieminen wrote: > programming than men, and this is the cause for there being more male > programmers, why would inducing women to choose a career path they are not > interested in make them "be good at and and enjoy it"? I am quite happy with the idea of getting the best people (in terms of ability, personal enjoyment, etc.) for jobs - without regard to gender, age, or anything else. And I believe it is fine to say that some classifications of people are, on average, going to be better suited for a particular task than others. But you have to keep in mind that this is only on average, and does not apply to individuals. However, there is a very real risk that people who have the potential to be good at a task, don't get involved in it as a result of these average biases. It might be that they see the bias and underrate themselves because of it, or maybe others underrate them. It may be an active choice - they don't want to be in a minority situation. There can be many reasons. If I am screening candidates for a programming job, I am not going to give someone a higher rating because they are a woman, or old, or have two heads, or whatever - I rate them based on how I think they can do the job. But I think there is a problem that there are people who /could/ have been right for the job, but never got to that point because they are a women, old, or have two heads. (I think this effect is less than it used to be - we are moving in the right direction.) |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 09 09:00AM On Wed, 2019-10-09, Juha Nieminen wrote: > programming than men, and this is the cause for there being more male > programmers, why would inducing women to choose a career path they are not > interested in make them "be good at and and enjoy it"? I never suggested that. I have no idea how we should get the right programmers in the future (apart from focusing more on talent and less on formal education). > Somehow I get the feeling that you subscribe to the "tabula rasa", or > "blank slate" theory. I don't. But I don't subscribe to the theory that our society is ideal and we shouldn't try to change anything. [snip a fairly large strawman] /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Juha Nieminen <nospam@thanks.invalid>: Oct 09 01:57PM > /could/ have been right for the job, but never got to that point because > they are a women, old, or have two heads. (I think this effect is less > than it used to be - we are moving in the right direction.) It can be an interesting discussion to have whether in our modern society there exist people who would have been talented and interested in a particular hobby or career path, but never got to even try it because of, for example, personal prejudice based on misinformation, because of never having been presented information on that subject, or having been inadvertently or deliberately discouraged from even pursuing such a path by misinformed and prejudiced people. That's the only explanation given and accepted by the modern feminist doctrine, but I don't think it's that simple. There may be some cases, even to this day, of that happening, but I'm not so sure of how much it happens, or whether it's even a majority of such cases. However, my problem is not really with that discussion. My main problem is that in the modern world the steps taken to try to rectify that problem (even assuming it's real and accurate) have gone in many ways way, way too far. These steps have only escalated more and more in the past few decades, at an ever-accelerating rate. The discrimination in enrollment that universities like Harvard engage in (where they require higher scores from Asians than from white people, and from white people than from Hispanics, for instance, which I consider astonisingly egregious and racist) is but the *mildest* example of this. The example I mentioned before, about the PHP Central Europe conference not just being cancelled, but terminated completely and forever, because some random person (who wasn't even attending) complained about the speakers being "old white men" or something like that, is especially egregious. There was literally zero discrimination or preferential treatment by the organizers, and they did absolutely nothing wrong, and many of the would-be speakers who bailed out because of that tweet even outright admitted that, yet they still bailed out, and the entire conference had to be terminated because of lack of attendance. Because of a completely ridiculous nontroversy started by some random person completely unaffiliated with the conference. When you start introducing modern identity politics into something like this, that's a sure way to introduce discontent, infighting, division and eventually destruction, into something that has absolutely nothing to do with politics, identity or otherwise. And it won't be the alleged "sexists" and "misogynists" who will be destroying it. It will be the people who classify themselves as feminists. So the exact moment that I see identity politics being shoved into something that has absolutely nothing to do with it, like a C++ conference, that's a huge warning sign for me. It predicts destruction. Just wait and see how long it takes before prominent figures in the C++ community start being accused of all kinds of things, and the purge starts. You'll see. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Oct 09 11:09AM -0400 On 10/9/19 3:02 AM, Juha Nieminen wrote: > Somehow I get the feeling that you subscribe to the "tabula rasa", or > "blank slate" theory. In other words, that there are exactly zero > differences between the average man and the average woman, I doubt that he subscribes to any such ridiculous theory. A much more plausible one would suffice to justify his comments. For instance, the theory that there are some differences between the average man and the average woman, but that many aspects of our society conspire to discourage women from pursuing traditionally male roles (and vice versa), even if the woman is interested in doing so, and is sufficiently competent to compete for such a role, if she hadn't been discouraged from doing so. It can be difficult to measure the severity of such discouragements, or even to prove that they exist. However, that doesn't mean that they don't exist. |
| David Brown <david.brown@hesbynett.no>: Oct 09 05:29PM +0200 On 09/10/2019 15:57, Juha Nieminen wrote: > doctrine, but I don't think it's that simple. There may be some cases, > even to this day, of that happening, but I'm not so sure of how much > it happens, or whether it's even a majority of such cases. I can't answer that. But I agree that it is a relevant question. There are lots of differences between people. Some are genetic, some are from upbringing, some are due to preferences of the people, some are due to influences from others, some are luck of where you are born and who your parents are, and so on. Some give obvious advantages or disadvantages for different tasks - being rather short, it was never likely that I'd be a good competitive sportsman. Others may be less obvious, or less known (especially when one means "proven scientifically" rather than "commonly accepted bias"), or less socially acceptable. > So the exact moment that I see identity politics being shoved into something > that has absolutely nothing to do with it, like a C++ conference, that's > a huge warning sign for me. It predicts destruction. Again, I am not convinced this is "politics" - but again, I don't think it is a word that is very clearly defined. I am not keen on the idea of forcing some sort of equality - I don't think you improve the average ability of a traditionally male-dominated profession by pushing in more women, or that you improve a traditionally female-dominated profession by pushing in more men. But I /do/ think there are plenty of situations where a traditionally minority group feels unwelcome or - equally bad, in a way - overly welcome (such as being treated specially as the only woman in the group, or only man). And this is bad for that group or profession - it hinders the selection based purely on suitability for the task. I don't know a good solution for getting from that situation to one where no one (either in the group, or outside it) cares about whether a programmer is male or female, or any other non-relevant aspect of people. One possible way is to use quotas or positive biases as a temporary measure, to counter any negative biases, until the mixed group is established as "normal" - then the active bias can be gradually removed as unnecessary. But whether that is the right approach or not - and if so, where and how much positive bias should be used - I have no idea. I like programming - I can see if something is a 0 or a 1. It is much simpler than psychology, sociology, or politics. > Just wait and see how long it takes before prominent figures in the C++ > community start being accused of all kinds of things, and the purge > starts. You'll see. Why should the C++ world miss out on the fun? That would not be fair, and this is all about equality. |
| legalize+jeeves@mail.xmission.com (Richard): Oct 09 03:40PM [Please do not mail me a copy of your followup] James Kuyper <jameskuyper@alumni.caltech.edu> spake the secret code >versa), even if the woman is interested in doing so, and is sufficiently >competent to compete for such a role, if she hadn't been discouraged >from doing so. [Emphasis added] This constantly comes up about women being "discouraged" to enter into STEM fields. I'm an old fart now and you might have considered that "back in the day" women would have been discouraged from STEM fields, but even 40 years ago this was not the case and it is certainly not the case now. The more plausible theory is not that there is some kind of "conspiracy" that discourages or prevents women from entering STEM positions, but that they simply don't choose those careers. It isn't interesting to women generally and they don't pursue those careers. Nothing is keeping them out, nothing is discouraging them, and in fact it is MASSIVELY the other way with women constantly being encouraged to enter STEM fields and constantly being "empowered" to enter programming fields. .....and yet, they still don't. I think it's time to acknowledge that women, as a general statement, simply don't pick these fields because they aren't that interested in them. As long as people have the freedom to choose their career paths that best suit their own tastes, there are always going to be imbalances. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 09 05:11PM +0100 On 09/10/2019 16:40, Richard wrote: > programming fields. .....and yet, they still don't. I think it's > time to acknowledge that women, as a general statement, simply don't > pick these fields because they aren't that interested in them. So you use the words "as a general statement" to hopefully qualify the following statement as not being sexist. Sorry mate but it doesn't wash. /Flibble -- "Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "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." |
| Frederick Gotham <cauldwell.thomas@gmail.com>: Oct 09 05:33AM -0700 Another thing: When creating the dependency files, the header inclusion paths must be passed to the compiler, like so: %.c.d: %.c $(CC) $(INC_DIRS) -MM -MT $(<:.c=.c.o) $< -MF $@ %.cpp.d: %.cpp $(CXX) $(INC_DIRS) -MM -MT $(<:.cpp=.cpp.o) $< -MF $@ So here's what I've got now. . . - - - - - - - - - - Makefile - - - - - - - - PROGRAM = super_cool_program INC_DIRS += -I./ CFLAGS_CXXFLAGS_IN_COMMON += -pedantic -Wall -Wextra -rdynamic -funwind-tables -fno-omit-frame-pointer -fdump-rtl-expand -fno-common -Og -g -pthread CFLAGS += $(INC_DIRS) $(CFLAGS_CXXFLAGS_IN_COMMON) -std=c99 CXXFLAGS += $(INC_DIRS) $(CFLAGS_CXXFLAGS_IN_COMMON) -std=c++17 LDFLAGS += $(CFLAGS_CXXFLAGS_IN_COMMON) LDLIBS += SRC_FILES_C := $(wildcard *.c) SRC_FILES_CXX := $(wildcard *.cpp) #If there's no C++ files then use the C compiler to link ifeq ($(SRC_FILES_CXX),) LINKER = $(CC) else LINKER = $(CXX) endif OBJECTS += $(SRC_FILES_C:.c=.c.o) $(SRC_FILES_CXX:.cpp=.cpp.o) DEPENDENCIES += $(OBJECTS:.o=.d) .PHONY: all all: $(PROGRAM) $(DEPENDENCIES) #This rule runs the linker to combine object files into one executable binary file $(PROGRAM): $(OBJECTS) $(LINKER) $(LDFLAGS) $^ $(LDLIBS) -o $@ #This rule makes dependencies files for the source files .PRECIOUS: %.c.d %.c.d: %.c $(CC) $(INC_DIRS) -MM -MT $(<:.c=.c.o) $< -MF $@ .PRECIOUS: %.cpp.d %.cpp.d: %.cpp $(CXX) $(INC_DIRS) -MM -MT $(<:.cpp=.cpp.o) $< -MF $@ #This rule compiles the source files to object files %.c.o: %.c %.c.d $(CC) $(CFLAGS) -o $@ -c $< %.cpp.o: %.cpp %.cpp.d $(CXX) $(CXXFLAGS) -o $@ -c $< #This next line pulls in all the dependency files (if they exist, and it's not "make clean") ifneq ($(MAKECMDGOALS),clean) -include $(DEPENDENCIES) endif .PHONY: clean clean: $(RM) $(DEPENDENCIES) $(OBJECTS) $(PROGRAM) $(OBJECTS:.o=*.expand) #These next two rules to (un)install are only for Linux .PHONY: install install: $(PROGRAM) cp $< /usr/bin/ .PHONY: uninstall uninstall: $(RM) /usr/bin/$(PROGRAM) |
| 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