It's a very reasonable conjecture that Trump would be much less careful than Clinton was if he were to hold office. He just hasn't had the opportunity.
What harassment laws did Bill violate? He didn't violate any that I could tell with Paula Jones. Clearly, he's a jerk, but I suspect he knows where the line is. "Allegedly raping"? Should we be paying attention to you with your alleged rapes (I just alleged them)? I'm reluctant to pay attention to alleged crimes, like the allegation (currently in court) that Trump raped a 13-year-old.
As far as "women's issues" go, there's no reason to think that, because she was angry at a few women, she doesn't legitimately work for women's issues.
Trump allegedly raped a 13-year-old. There's a lawsuit going on now, which suggests that there's some evidence that it happened. Should we be paying attention to rape allegations without good evidence?
I've been looking at Snopes from time to time lately, and they seem to be debunking lots of anti-Clinton and lots of anti-Trump claims. They appear to be holding to the same standard of evidence (not perfect, but good) for their political analyses, and they do give sources. It seems to me that they're being fairly neutral in what they publish, although there may be biases in what they publish.
In other words, it looks to me like you may be the one out of touch with reality due to bias.
Christianity, as practiced by many people, is consistent with what we know. If we knew that the only significant laws of the Universe were the sort we're busy discovering, then it would be inconsistent, but we don't know that. It's entirely possible that there are things like angels and magic, and I can think of numerous reasons why they wouldn't have been discovered. I have no problem with you believing that physics more or less as we know it is it, but it bugs me when people insist that beliefs of theirs that can't be rationally proven have got to be true.
Lots of things can't be shown rationally. Most of us can agree on some parts of aesthetics, for example, but the only way we've got to make any rationality of it is to notice how people feel about things.
I didn't get that out of my quick look at the Wikipedia article on the Espionage Act, but what the heck.
Using a private email server is not prima facie being negligent. We know that Clinton was negligent in several areas, but there's no reason she couldn't have had a server more secure than official government systems and which complied with all applicable laws. The server was not intended to handle classified documents, and indeed there were very few found on the system. If there had been none, then it didn't matter what Clinton did with it as far as the Espionage Act goes. Therefore, Obama was not an accomplice unless he was aware of negligence, and that's not going to be easy to show.
I do understand how my company works, how we make money, what our competitive advantages are, and how what I do fits into all of this. I'm not in management, and nobody's going to get me into management, because I don't want to be there. That means I'm still required to abide by management decisions. It does happen that the managers around here respect my knowledge and ability, but that doesn't mean I get to pick which languages and tools I use.
The ability to develop software competently is in high demand and short supply, and anyone with that talent who has halfway reasonable communication skills and can get along with people reasonably well can get a job and keep it. A software manager who can't deal with people like that and get good work out of them should not remain an employed person for long.
I don't know Rust or Ada, and in my experience I tend to get things wrong when I look up language features, so I like to let people who do know them talk about them. I do know C++ well, and have noticed that a lot of people think they know C++ and are wrong. Very often, they used an early version, or were taught badly, and don't even know how to use C++98 well.
However, anyone who uses phrases like "C/C++" or "C and C++" with the implication that the differences don't really matter does not know what he or she is talking about, and is about as competent to judge C++ safety features as I am to judge Ada or Rust. In this case, I was going by "C and C++ are less safe than, say, Ada or Rust", and in fact C++ is a lot safer than C.
It would seem that neither you nor I know enough to compare C++ and Ada and Rust for safety. I'm willing to believe Ada and Rust are safer (that was one of the main design goals in Ada, I know), but I'd like to hear from someone who appears to me to know C++ well and who does know Ada and Rust well.
However, there can be constraints enforced by the compiler. In the case of a[-1], the compiler is literally allowed to do anything by the C standard, and some compilers at high optimization levels will take advantage of that. In the case of a std::vector being referenced by.at(), the compiler doesn't have to add constraints if it can know that the reference is in-range (one example would be inside a for loop where the iteration variable is only changed in the for statement clause).
Also, the compiler can aim its optimizations to the usual case of checked references It's not like the unchecked references need optimization.
Oh, agreed. My point is that the language implementation matters, and that depends partly on the language. Careful coding goes only so far, and typos are easy to make and miss.
No, the act was to prohibit redlining, meaning that there would have to be fair criteria. The act did not require banks to loosen their criteria. They didn't have to make ninja loans. If the Federal government was pressuring banks to make bad mortgages in the seven years before 2008, that really wasn't Clinton's fault.
1. An interface to existing C code, so we don't have to convert all at once. Okay, that one they usually provide. But...
Approximately everything has interfaces to existing C code, since C tends to have very stable ABIs on various platforms. The C ABI is often used as a lingua franca.
std::shared_ptr does have performance problems. Updating the counts can screw up cache coherency, and needs to be thread-safe, which can cut performance further. I don't know enough about modern mark-and-sweep garbage collection to provide comparisons, except that modern garbage collection deals only with memory and C++'s RAII idiom uniformly handles all allocation and deallocation.
Why is calling two destructors so bad? You're going to want all those lower-level destructors called somehow, and you're going to have to write code to do it. Is it any more of a performance issue to put that code in the container's destructor?
In other words, you want to add more compiler warnings to C++. C++ has safe pointer features, a preprocessor alternative, and a lot of other improvements. It still suffers from some syntactic things like "if (a=b)" and "Foo foo();", but we can provide compiler warnings for those.
Really? Despite knowing what I'm doing and being very experienced, I mistype and produce something like "if (a=b)" maybe once every two years or so. (For people not familiar with C, that means assigning the value of b to a and taking the "true" branch if a evaluates to true. This should not be confused with a comparison of a to b.) I'm sufficiently egotistical to believe that, if I'm not perfect, not many people are.
Are you talking about modern extensions of the 360 architecture? The original version had a 24-bit address space that was addressed relative to registers, and no memory safety.
The early stuff on formal verification left me with the feeling that, if I were a perfect mathematician, I could then become a good programmer, which wasn't really all that helpful. I did get some ideas on how to verify some fairly small constructs, which I've used when they seemed useful. My experience is that, once I've formally proven a routine correct, the remaining errors are normally big dumb ones that are easy to find and fix.
The big issue with formal specifications is that programming is the art of changing informal descriptions to formal descriptions, and so creating a correct spec and verifying that the program conforms is more work than writing a conforming program. Moreover, the formal description can be considered a programming language in itself.
In some cases, it's possible to set up a correct formal spec, and there are software verification tools that can help from there. It helps if the domain is really limited, such as accounting or circuit design.
a[-1] is undefined behavior in C, and not all compilers will do what you want with it. It's only reasonable with the sort of pointer action that's very error-prone and almost never required in normal applications. If you need it in C++, it's there. With C++ and std::vector, the compiler is not required to introduce checks when using the normal [] way of using it and not.at(). Heck, it's not required to check.at(), if the compiler can determine that this particular access will not throw an exception.
A compiler that optimizes checked memory references in preference to raw memory accesses is going to be more useful in most cases. There's no advantage to doing the wrong thing really, really fast.
The flexibility advantage in C++ is real. Often you don't get a chance to use your nice spiffy string functions, because the existing code base uses the standard ones, or (worse) uses something proprietary. With a C++ string class, change a few functions in the class definitions and you're ready to go. C++ classes and inheritance make it easy for old code to use new code without change, instead of just new code using old code.
The big problem with strncpy() is that the naming convention is deceptive. IIRC, all other "strn" functions are range-checked versions of the corresponding "str" functions, while strncpy() does something significantly different from strcpy().
The places I've worked at have used std::vector happily (although here we usually wrap it up to fit into MFC better). What do you think is wrong with it?
I've yet to see any C++ code base that is bug free,
I've yet to see any sizable code bases that are bug free, and the ones I've read about that are likely to be are that way because of development approach and individual ability, not choice of language. TeX is very reliable, and was written in Pascal with weird formatting (see Literate Programming).
Requirements for projects of reasonable size will be captured wrongly. I'm not saying it's going to happen absolutely all the time, but it's a good attitude to have. Most users can't express what they need in sufficient formality, and can't project what the consequences are with any accuracy. Expecting accurate requirements analysis going into design is like expecting a computer language that does what you mean.
Actually, C++ has, in the language standard, ways to eliminate whole classes of C bugs. I'm not familiar enough with Ada or Rust to compare safety features, but I doubt anyone who refers to "C and C++" in the context of language safety knows enough C++ to compare.
C++ uses malloc/calloc/free for C compatibility only. It uses new/delete as low-level mechanisms, and has enough safe templated abstractions on top of that for people to actually use.
The trick to using templates in C++ is to remember that they're hard, because they make it syntactically easy to do difficult things, much like Common Lisp macros. The ordinary C++ programmer should almost always use somebody else's templates, and not try his or her own.
C++ templates are extremely powerful, and make it possible to transform the language in various ways. They allow a lot of compile-time processing which helps runtime. They make it easy to reuse efficient algorithms without needing shims to bolt on the algorithms. Consider C's qsort. It requires an explicit description of the memory layout, and a function that has to be declared somewhere else. C++'s std::sort can just be used on appropriate data structures, and the comparison function can be a standard operator<() or a lambda function at the site.
Slashdot Mirror
It's a very reasonable conjecture that Trump would be much less careful than Clinton was if he were to hold office. He just hasn't had the opportunity.
What harassment laws did Bill violate? He didn't violate any that I could tell with Paula Jones. Clearly, he's a jerk, but I suspect he knows where the line is. "Allegedly raping"? Should we be paying attention to you with your alleged rapes (I just alleged them)? I'm reluctant to pay attention to alleged crimes, like the allegation (currently in court) that Trump raped a 13-year-old.
As far as "women's issues" go, there's no reason to think that, because she was angry at a few women, she doesn't legitimately work for women's issues.
Trump allegedly raped a 13-year-old. There's a lawsuit going on now, which suggests that there's some evidence that it happened. Should we be paying attention to rape allegations without good evidence?
I've been looking at Snopes from time to time lately, and they seem to be debunking lots of anti-Clinton and lots of anti-Trump claims. They appear to be holding to the same standard of evidence (not perfect, but good) for their political analyses, and they do give sources. It seems to me that they're being fairly neutral in what they publish, although there may be biases in what they publish.
In other words, it looks to me like you may be the one out of touch with reality due to bias.
Christianity, as practiced by many people, is consistent with what we know. If we knew that the only significant laws of the Universe were the sort we're busy discovering, then it would be inconsistent, but we don't know that. It's entirely possible that there are things like angels and magic, and I can think of numerous reasons why they wouldn't have been discovered. I have no problem with you believing that physics more or less as we know it is it, but it bugs me when people insist that beliefs of theirs that can't be rationally proven have got to be true.
Lots of things can't be shown rationally. Most of us can agree on some parts of aesthetics, for example, but the only way we've got to make any rationality of it is to notice how people feel about things.
I didn't get that out of my quick look at the Wikipedia article on the Espionage Act, but what the heck.
Using a private email server is not prima facie being negligent. We know that Clinton was negligent in several areas, but there's no reason she couldn't have had a server more secure than official government systems and which complied with all applicable laws. The server was not intended to handle classified documents, and indeed there were very few found on the system. If there had been none, then it didn't matter what Clinton did with it as far as the Espionage Act goes. Therefore, Obama was not an accomplice unless he was aware of negligence, and that's not going to be easy to show.
I do understand how my company works, how we make money, what our competitive advantages are, and how what I do fits into all of this. I'm not in management, and nobody's going to get me into management, because I don't want to be there. That means I'm still required to abide by management decisions. It does happen that the managers around here respect my knowledge and ability, but that doesn't mean I get to pick which languages and tools I use.
The ability to develop software competently is in high demand and short supply, and anyone with that talent who has halfway reasonable communication skills and can get along with people reasonably well can get a job and keep it. A software manager who can't deal with people like that and get good work out of them should not remain an employed person for long.
I don't know Rust or Ada, and in my experience I tend to get things wrong when I look up language features, so I like to let people who do know them talk about them. I do know C++ well, and have noticed that a lot of people think they know C++ and are wrong. Very often, they used an early version, or were taught badly, and don't even know how to use C++98 well.
However, anyone who uses phrases like "C/C++" or "C and C++" with the implication that the differences don't really matter does not know what he or she is talking about, and is about as competent to judge C++ safety features as I am to judge Ada or Rust. In this case, I was going by "C and C++ are less safe than, say, Ada or Rust", and in fact C++ is a lot safer than C.
It would seem that neither you nor I know enough to compare C++ and Ada and Rust for safety. I'm willing to believe Ada and Rust are safer (that was one of the main design goals in Ada, I know), but I'd like to hear from someone who appears to me to know C++ well and who does know Ada and Rust well.
However, there can be constraints enforced by the compiler. In the case of a[-1], the compiler is literally allowed to do anything by the C standard, and some compilers at high optimization levels will take advantage of that. In the case of a std::vector being referenced by .at(), the compiler doesn't have to add constraints if it can know that the reference is in-range (one example would be inside a for loop where the iteration variable is only changed in the for statement clause).
Also, the compiler can aim its optimizations to the usual case of checked references It's not like the unchecked references need optimization.
Thanks - I completely don't remember that from my 360 assembler days.
Oh, agreed. My point is that the language implementation matters, and that depends partly on the language. Careful coding goes only so far, and typos are easy to make and miss.
No, the act was to prohibit redlining, meaning that there would have to be fair criteria. The act did not require banks to loosen their criteria. They didn't have to make ninja loans. If the Federal government was pressuring banks to make bad mortgages in the seven years before 2008, that really wasn't Clinton's fault.
Approximately everything has interfaces to existing C code, since C tends to have very stable ABIs on various platforms. The C ABI is often used as a lingua franca.
std::shared_ptr does have performance problems. Updating the counts can screw up cache coherency, and needs to be thread-safe, which can cut performance further. I don't know enough about modern mark-and-sweep garbage collection to provide comparisons, except that modern garbage collection deals only with memory and C++'s RAII idiom uniformly handles all allocation and deallocation.
Why is calling two destructors so bad? You're going to want all those lower-level destructors called somehow, and you're going to have to write code to do it. Is it any more of a performance issue to put that code in the container's destructor?
In other words, you want to add more compiler warnings to C++. C++ has safe pointer features, a preprocessor alternative, and a lot of other improvements. It still suffers from some syntactic things like "if (a=b)" and "Foo foo();", but we can provide compiler warnings for those.
Really? Despite knowing what I'm doing and being very experienced, I mistype and produce something like "if (a=b)" maybe once every two years or so. (For people not familiar with C, that means assigning the value of b to a and taking the "true" branch if a evaluates to true. This should not be confused with a comparison of a to b.) I'm sufficiently egotistical to believe that, if I'm not perfect, not many people are.
Are you talking about modern extensions of the 360 architecture? The original version had a 24-bit address space that was addressed relative to registers, and no memory safety.
The early stuff on formal verification left me with the feeling that, if I were a perfect mathematician, I could then become a good programmer, which wasn't really all that helpful. I did get some ideas on how to verify some fairly small constructs, which I've used when they seemed useful. My experience is that, once I've formally proven a routine correct, the remaining errors are normally big dumb ones that are easy to find and fix.
The big issue with formal specifications is that programming is the art of changing informal descriptions to formal descriptions, and so creating a correct spec and verifying that the program conforms is more work than writing a conforming program. Moreover, the formal description can be considered a programming language in itself.
In some cases, it's possible to set up a correct formal spec, and there are software verification tools that can help from there. It helps if the domain is really limited, such as accounting or circuit design.
a[-1] is undefined behavior in C, and not all compilers will do what you want with it. It's only reasonable with the sort of pointer action that's very error-prone and almost never required in normal applications. If you need it in C++, it's there. With C++ and std::vector, the compiler is not required to introduce checks when using the normal [] way of using it and not .at(). Heck, it's not required to check .at(), if the compiler can determine that this particular access will not throw an exception.
A compiler that optimizes checked memory references in preference to raw memory accesses is going to be more useful in most cases. There's no advantage to doing the wrong thing really, really fast.
The flexibility advantage in C++ is real. Often you don't get a chance to use your nice spiffy string functions, because the existing code base uses the standard ones, or (worse) uses something proprietary. With a C++ string class, change a few functions in the class definitions and you're ready to go. C++ classes and inheritance make it easy for old code to use new code without change, instead of just new code using old code.
The big problem with strncpy() is that the naming convention is deceptive. IIRC, all other "strn" functions are range-checked versions of the corresponding "str" functions, while strncpy() does something significantly different from strcpy().
The places I've worked at have used std::vector happily (although here we usually wrap it up to fit into MFC better). What do you think is wrong with it?
I've yet to see any sizable code bases that are bug free, and the ones I've read about that are likely to be are that way because of development approach and individual ability, not choice of language. TeX is very reliable, and was written in Pascal with weird formatting (see Literate Programming).
Requirements for projects of reasonable size will be captured wrongly. I'm not saying it's going to happen absolutely all the time, but it's a good attitude to have. Most users can't express what they need in sufficient formality, and can't project what the consequences are with any accuracy. Expecting accurate requirements analysis going into design is like expecting a computer language that does what you mean.
Actually, C++ has, in the language standard, ways to eliminate whole classes of C bugs. I'm not familiar enough with Ada or Rust to compare safety features, but I doubt anyone who refers to "C and C++" in the context of language safety knows enough C++ to compare.
C++ uses malloc/calloc/free for C compatibility only. It uses new/delete as low-level mechanisms, and has enough safe templated abstractions on top of that for people to actually use.
The trick to using templates in C++ is to remember that they're hard, because they make it syntactically easy to do difficult things, much like Common Lisp macros. The ordinary C++ programmer should almost always use somebody else's templates, and not try his or her own.
C++ templates are extremely powerful, and make it possible to transform the language in various ways. They allow a lot of compile-time processing which helps runtime. They make it easy to reuse efficient algorithms without needing shims to bolt on the algorithms. Consider C's qsort. It requires an explicit description of the memory layout, and a function that has to be declared somewhere else. C++'s std::sort can just be used on appropriate data structures, and the comparison function can be a standard operator<() or a lambda function at the site.