I've passed the message on to Barbara. She offers the following correction:
int *ip, i, &r = i;
I've passed the message on to Barbara. She offers the following correction:
int *ip, i, &r = i;
To Silvercats: Everything in Accelerated C++ is as valid now as it was in 2000. It is true that it doesn't cover the C++11 stuff, but it is possible to learn that stuff later.
Also: Why are you writing
DataType *Ptr = new DataType();
instead of simply writing
DataType Obj;
?
You might be interested to know that the 5th edition of C++ Primer is now available. This book is a complete rewrite of the 4th edition, and integrates C++11 features throughout the text and examples. To my knowledge, it is the first book on the market to do this.
I'm obviously biased about this book, both because I reviewed and commented on several drafts and because I'm married to one of the authors. Nevertheless, my comments in the previous paragraph are all facts, not opinions, and I'd like to suggest that if such a book interests you, you might be interested in checking it out for yourself.
Also: From the table of contents, this book does not mention vectors until page 200 out of 379 pages. This fact suggests that the book is much more C-oriented than C++-oriented.
It's hard to say -- I think the two books have rather different purposes, and the answer would probably depend on your personal style, which obviously I don't know.
I'm sticking with the comment I made earlier: A bunch of people mentioning names of books they personally like, without any real information about why they like them, or about their qualifications to evaluate them, is not useful.
This is especially true because I think that at least a few of the books thus recommended are trash. As the (co)author of a competing book, I think it would be unethical for me to point out which ones or explain why I think so; but I urge you not to take unsupported claims of "I like book X" at face value without evaluating them yourself.
There are four conditions that must be met for checkmate to occur:
1) The king is in check.
2) There is no move that the king can make that takes it out of check.
3) It is not possible to capture the attacking piece.
4) It is not possible to interpose a piece between the king and the attacking piece.
(3) and (4) are impossible if there is more than one attacking piece.
(4) is impossible if the attacking piece is a knight.
What would you do with variable-length arrays that you can't do better with C++ vectors?
Oh, wait a minute, I got it. It is indeed a trick question. sfuo is right. Read the conditions carefully.
If there's no upper bound on n, then you need a data structure that can grow without bound. If you can't use arrays or pointers, then you must find some other data structure that grows without bound. If you're not allowed to use any such data structure, then the only solution I can see is to use recursion to store the information you need on the call stack somehow. I don't immediately see how, but I also don't see any other way to do it.
Either that or there's some other aspect of the problem that you haven't told us.
I'd recommend lots of things, but not without seeing the whole program or what you're trying to do with it.
If you can figure out what the code means, then I suggest you take an example that someone else has written that uses inheritance and try to rewrite it into a program that behaves the same way but does not use inheritance.
Please post your entire program, using code tags, and tell us what is happening that you don't expect.
What happens if you change
... << setprecision(2) << ...
to
... << fixed << setprecision(2) << ...
?
Usually I don't do people's homework for them, but this solution is part of the public literature, and if you actually read and understand it, you will have learned as much as if you had solved it yourself. Perhaps more, because the exposition is so elegant.
That's easy: None of them are even and odd.
You say: "a smart compiler could optimise this by seeing that the next lines (below) of this function never use the derived part of d1 and d2 and that the base part has an identical content"
No it can't. The only way a compiler could do so would be if the program's behavior didn't change. But the moment you make your program depend in any way on d1 and d2 having different addresses, putting d1 and d2 in the same place would change the program's behavior. So that's not an acceptable optimization.
Different objects have different addresses.
You say "2 different objects share the same memory location if their content are identical."
The thing is: If they share the same memory location, they are not different objects.
If allocating and initializing dynamic memory is a significant part of your program's overall execution time, you may want to reconsider your design.
My reason for saying this is that if initialization is significant, it suggests that you're not doing much else with the memory aside from initializing it. In that case, why are you using it at all? Perhaps you can answer this question in a way that provides an alternative to the initialization.
It is hard to know whether a change to your program will make it faster until you understand where it is spending its time now.
For example, if the program is slow because the operating system's file system is taking too long to open and close all those files, adding threads will not help. At the other extreme, if the program is limited by the cpu speed, then threading will also not help unless you are on a multicore processor. Even in that case, you might be able to rewrite the part of the program that is taking too long, and doing so might be more of an improvement than taking advantage of multiple cores.
So if your program is running too slowly, I think it is important not to change anything until you understand how the program spends its time.
I don't think that listing one's favorite C++ books gives any real insight. Accordingly, I've written an article that explains what to look for in a C++ book. If you find these qualities, that's a book to avoid.
The republicans had no say in passage of Obamacare. The Democrats controlled both houses of congress at that time. So I don't know how you can possibly blaim the republicans for anything.
That's easy: the same way that the original poster can talk (apparently with a straight face) about "people such as Oparah and Bill Gates which easily have enough money to supply everyone in the continental U.S. with over a million dollars each in their bank accounts."
Hmmm. Let's see. A million dollars times 300 million people is 300 TRILLION dollars. Oprah and Bill Gates have that much money? In your dreams.
I think that before you suggest solutions to a problem, it is important to understand exactly what problem you are trying to solve.
When you say that you "want to make sure whether two points are the same," exactly what do you mean? In other words, will you ever want to treat two points that are very close together as being "the same?" If so, how close together?
Perhaps even more important is understanding why. In other words, if you want to know whether two points are the same, why are you ever willing to accept two points as being "the same" if they are merely close together? Note that if point A is close to point B, and point B is close to point C, that does not imply that point A is necessarily clowe to point C. Is that fact acceptable? Why or why not?
Until you understand the answers to these questions, you will have a hard time writing code to check whether two points are "the same" that will actually work.
If you want help with your code, you have to post the code that is having problems. You can't expect people to figure out what's wrong by looking at different code.
Aw, gee ... here I was trying to lead the OP gently to the right answer and two people jumped in and spoiled it :-)
That said, I would like to make one slightly subtle point. Suppose we eliminate the short-circuit evaluation:
z = ++x | ++y & ++z;
Now the effect of the statement is undefined because it modifies z twice between sequence points.
i know how to do safe downcasting ,but my question is when i typecasted the base object to derived then pointer should call the fun() of derived (from virtual function call mechanism )
correct me if i am wrong !!
OK, you're wrong.
If D is derived from B, and you want to cast a B* object to D*, then the B* object must be pointing to a D* object, or to an object of a type derived from D*, or the pointer must be zero. If none of these conditions applies, the program's behavior is undefined.
So you did something for which the behavior is undefined. In that case, the implementation is allowed to do as it pleases, and it is a waste of time trying to explain why it did what it did.
If you have the same problem, it can be solved in the same way.
Please use code tags.
Very good to know, thank you.
One reason it's not portable is that IBM mainframes use a character set in which 'a' through 'i' are hex 81 through 89, but 'j' is hex 91. Much more information than you ever wanted to know about this character set can be found here.
To get the value of a character, subtract 'a'.
This technique works on most computers in use today, but it is not actually guaranteed to work. That's why I coded my example the way I did.
Just for the record, I agree that the solution is ugly and unnecessary obfuscated, but at least it's fun.
I'm being serious when I say that it's not obfuscated--it illustrates a programming technique that is important in languages that use recursion as a matter of course.
Definition: A function call that is the very last thing a function does is called a tail call. So, for example, a return statement that returns the result of a function call is a tail call.
In C++, many calls that look like tail calls really aren't, because the compiler has to insert destructor calls for local variables before the function can actually return. However, when a function call is a true tail call, it is often possible for a compiler to replace the call snd subsequent return by a jump instruction.
A tail call that is recursive is called a tail recursion. It is often possible for a compiler to replace a tail recursion by a loop.
There are some programming languages, such as Scheme (which is used as the introductory programming language at MIT), that either discourage or completely prohibit iteration statements. Instead, programmers are expected to use recursion. In such language, it is an important optimization on the programmer's part to use tail recursion where possible, because the compiler will implement tail-recursive programs as iterations that do not consume any new stack space on each iteration.
So although the existence of destructors usually makes it difficult …
It is very easy to estimate the performance of a solution, it is called complexity class.
It is impossible to estimate the performance of a solution without knowing whether a particular program actually is a solution.
It is reasonable to claim that an algorithm that selects every line with the same probability is a solution. However, an algorithm that seeks to a random offset in the file, and then extracts a line near that offset, generally does not select every line with the same probability. So the question then becomes whether that selection is reasonable, and why.
So far, you have said that the selection is reasonable, but you haven't said why. That is, you haven't said what criteria you are using to distinguish reasonable results from unreasonable results. Until you do that, there's no point in talking about the performance of individual programs, because there's no way to know whether those programs even produce correct results.
rvalue-lvalue qualification is not the same as cv-qualification. You can have a const or non-const, lvalue or rvalue variable.
I think you're missing the point.
The C++ standard, clause 5.2.11, says that the result of const_cast<T>(e) is an lvalue if type T is a reference type; otherwise the result is an rvalue. So const_cast<myclass*>(anything) is an rvalue, because the type myclass* is not a reference type.
But, in theory, just reading or writing the value of the this pointer (not what it points to) is "valid" (if the compiler permits it), just like this code is valid, but useless:
void someFunction(int* some_ptr) { delete some_ptr; std::cout << "The pointer I just deleted had address: " << some_ptr << std::endl; some_ptr = NULL; // reading or writing some_ptr is valid and well-behaved after the delete. This also applies to the this pointer. };
I still believe you are mistaken. One of the interesting aspects of pointers is that it is undefined behavior even to copy the value of a pointer to memory that has been freed. Clause 3.7.3.2 of the C++ standard says that once memory has been deallocated, any pointer to that memory becomes invalid, and any use of such a pointer, even to pass it to a function, results in undefined behavior.
This behavior is inherited from C, and comes from some processor architectures that use different registers for addresses and other data. In such processors, the mere act of putting an address into an …
To give you an idea of how many worms are in this particular can, I'd like to isolate two lines from the OP's code:
delete this;
const_cast<myclass *>(this) = 0;
The program is already broken at this point, because once you have executed "delete this;" any subsequent use of this is invalid.
Come to think of it, the second statement is invalid anyway, even without "delete this", because this is not an lvalue. And even if it were, casting it to myclass* yields an rvalue, to which you can't assign.
If your compiler accepts this program, your compiler is broken.
Your download function doesn't contain a return statement, which means that it doesn't return a value. So when you execute line 34, the variable "lines" is set to None. In line 35, when you try to select elements of Lines, the Python system tells you that you can't select elements of None.
If your goal is for download to return the value of the local variable "lines," which is completely distinct from the variable "lines" in line 34 of your program, then you need to put
return lines
at the end of your download function (appropriately indented, of course).
I'm trying to fix these things you pointed ... just one question ... about defining the == and != as friends ... how should I do that?
Go to your nearest C++ textbook and read about friend functions.
Yikes, is that really Andrew Koenig or a very good Impersonator!!!
I'm not impersonating anyone--but it's not exactly obvious how I might go about proving it if you don't already know me. If you do, I could tell you something about myself that an impersonator would be unlikely to know--but if you don't know me, you also don't necessarily know how to distinguish what I tell you from information that might be publicly available.
If you do an online search for me, you will find lots of hits, both for me and for the actor with the same name who vanished last year in Vancouver and was later found dead. There's no relation between us that I know, although we had been friends on Myspace.
You'll find lots of copies of the photo I use for my avatar, too, so an impersonator could have snarfed that from anywhere. I can tell you lots of things about the kitten that was on my shoulder when that picture was taken, but of course I could be making them up.
So yes, it's really me; but I can't think of a convenient way to prove it.
I can think of a somewhat inconvenient way to prove it. Pick up a copy of Accelerated C++ and look at the preface, which tells where I live. Look me up in your phone directory of choice--my phone number is listed. Call it, and give me a piece of information that you'd like …
Before you learn about functions, I suggest you learn about how to write a loop and how to change the value of a variable.
I'm sorry to say that both answers are wrong.
Example (a) uses the overloaded constructor that matches the argument, which in this case has type const char*. The string type is actually an instantiation of the basic_string template, so that string is equivalent to basic_string<char>; but putting that detail aside, it is useful to think of the first example as asking for string(const char*).
Example (b) uses = along with an initializer, which means that it is a request to use the copy constructor (conceptually string(const string&)). The expression after the initializer is converted to type string, which means that the second example is equivalent to
string color = string("red");
Theoretically, then, it is a request to construct a temporary object of type string, initialize color as a copy of that object, and then destroy the temporary object.
However, the compiler is permitted to optimize away this copy (provided that the relevant copy constructor is accessible, which in this case it is), in which case the two examples may well generate identical code.
So the first answer, saying that there is no difference between these two examples, is not quite right; and the second, saying that it is using overloaded operator =, is just plain wrong.
Why are you asking?
Please show the full contents of your input file, as well as exactly what the program prints when you run it. Do not try to interpret or explain what the program does. Just the facts, please.
Your array has 20 columns. When you use puts to read a string, it puts a null character ('\0') at the end of its input. So if your input is 19 characters or longer, the input (including the null character) runs off the end of the row of the array and onto the next row.
So this program fails any time it gets more than 19 characters of input.
More generally, this failure is an unavoidable aspect of using gets: The gets function takes a pointer to memory, and simply overwrites as much memory as necessary to hold its input. Because you don't know how much input you're going to get, you don't know how much memory it is going to overwrite.
As a consequence of this behavior, you should never use gets in your programs for any reason. Because it overwrites memory unpredictably, any program that uses gets has security problems that are impossible to fix. For that reason, I think that if you are using a book that recommends the use of gets, you should consider using a different book.
for (int i = 0; i < 1; ++i) {
for (int j = 0; j < 1; ++j) {
cout<<"_ _ _ 1" << endl;
cout<<"_ _ 2 2" << endl;
cout<<"_ 3 3 3" << endl;
cout<<"4 4 4 4" << endl;
}
}
The difference between int main()
and void main()
is that the first one is allowed in C++ and the second isn't.
You're going to say "But my compiler accepts it!"
And I'm going to reply "So? Compilers often accept code that's not valid. This fact doesn't make the code valid."
The last time you asked for someone else to do your homework for you, I directed your attention here.
I do not think you actually read it, because if you did, you would not be asking again for someone to do your homework for you.
So please, do us all a favor: Read the thread I've just cited, then follow its instructions and come back after you have done so.
transform(object.begin(), object.begin(), //Only one parameter within that range tolower);
This example doesn't work, for two reasons:
1) If you pass object.begin() twice as a range, what you get is the empty string immediately before the first character (if any) in object.
2) You can't actually pass tolower as an argument to a library function because tolower itself is overloaded.
One way to accomplish the same end that does work, and (in my opinion) is easier to understand:
if (!object.empty())
object[0] = tolower(object[0]);
There isn't a set of published answers for Accelerated C++ because Barbara's and my teaching experience is that if students have the answers already available, they don't try to solve the problems for themselves.
Typically, if you don't know for sure whether your answer is right, it probably means you don't understand the subject matter well enough; in which case, it doesn't matter much whether the answer is right or wrong. Still, I can understand why you might have nagging doubts; so I'll underscore what firstPerson said.
If by "best" you mean the closest to 12 without being greater than 12, then what you have just described is a version of the knapsack problem, which is known to be hard to solve efficiently.