Posts by arkoenig

I guess you're referring to the favorable tax rates for capital gains.

Those rates are favorable for two reasons: (1) The money invested to produce those capital gains has already been taxed once, so you're really talking about taxing it twice; (2) Over longer terms, most of the returns from capital gains are due to inflation.

Let me elaborate on (1) because it's not completely obvious. Suppose you invest $1,000 in a way that earns 10% over some period of time. If there were no taxes, you would have $1,100. However, suppose that that $1,000 is subject to a 20% income tax before you invest it, so you have only $800 to invest. Then at the end of the period, you have only $880, not the $900 you might expect. In other words, taxing money before it is invested reduces not just the principal, but also the return.

An even stronger argument applies to corporate dividends. If you buy stock in a company, that company pays corporate income taxes on its profits. Then it distributes (part of) what's left to its shareholders, including you. Then that money, which has already been taxed, is taxed again. This double taxation is part of the reason that corporations are often reluctant to return money to their shareholders as dividends, preferring instead to reinvest that money to make the company bigger. That, in turn, is part of the reason that corporations tend to become so large. If shareholder dividends were taxed only once, rather …

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;

?

I think that you probably have something like this in mind:

def print_reverse(s):
    for i in range(len(s)-1, -1, -1):
        print(s[i])

I doubt you're going to find anyone to help you with this code because your description of what it's supposed to do is so unclear. To begin, (x^2+x)/(x^2+x^3) isn't a polynomial; so your claim that your program finds the integral of a polynomial is not correct. Therefore, we don't actually know what this program is supposed to do, or how it is supposed to work.

May I suggest that you start by taking some small part of the program and isolating the code that does just that part. Then determine whether the code is doing what you expect it to do. If it isn't, then write a short, accurate description of what the program is supposed to do, along with another description of what it is doing, and post those descriptions along with the code. If your code is more like 15-20 lines instead of the 113 lines you posted, you'll be much more likely to get someone to look at it.

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.

This is obviously a biased comment; but I'll make it anyway.

Accelerated C++ does not require any specific previous programming knowledge, but the text is fairly condensed, and if you try to use it to teach yourself to program with no prior experience at all, you might find it rough going if you have no one you can ask for help if you get stuck. Because it covers more in 350 pages than some other books do in 1,000 pages, you should expect to have to read carefully; but I think that if you do read carefully, you will learn more in less time than you would with many other books.

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.

What about the following scenario?

1) Your king is not in check.
2) It's your move and any move you make places your king into check.

Is that checkmate?

No. It's stalemate, and the game is drawn.

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.

Interesting about the sort accepting a1.end; from this page:

http://www.cplusplus.com/reference/stl/vector/end/

I'd have thought that it would fail, since the 2nd parameter of sort is supposed to be the last element to sort (which is not the same as the end of a vector).

Where does it claim that? I couldn't find it.

Everything you say makes sense. I just found it odd that an algorithm that needs to be told the start and the end of the data (like sort) would expect the end to be beyond the final valid element. But, your position is supported by the results of the program, so I'm inclined to believe you're right.

Every STL algorithm that deals with a range expresses the range as a pair of iterators. The first iterator locates the first element in the range; the second is one past the last element.

When I say "first element" and "last element," I am generalizing that to mean "where the first/last element would be if there were one" if the sequence is empty.

There are three reasons that the second iterator points one past the last element of the range:

1) That technique allows you to express an empty range by giving the same value for the two iterators. If the second iterator pointed at the last element, you would need to have the second iterator pointing *before* the first one.

2) The technique makes it possible to use the following pattern for accessing all of the elements in the range: for (iter it = begin; it != end; ++it) { /* process an element */ } I invite you to try to figure out how you would accomplish this if "end" pointed directly to the last element rather than one before it. Be sure to handle correctly the …

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.

@ravenous: Thanks for the excellent suggestions. I have just one tiny comment to add: Some people may prefer

return (rand() % 2)? item_2: item_1;

to

return (rand() % 2 == 0)? item_1: item_2;

Others may feel it's too clever. I'm mentioning it so that you can make up your own mind.

In a similar vein, the outer parentheses are unnecessary because of operator precedence, so you could write

return rand() % 2 ? item_2: item_1;

with the same effect.

Finally, because you're making a random selection, the order of item_1 and item_2 doesn't really matter.

Remove the call to srand from the choose_number function.

As a general rule, you should call srand only once in your entire program.

Xoring the bits of an integer is equivalent to computing its parity. There are ways of doing so that might be faster than your original example, but you'd have to measure to see whether it's really faster in practice.

The way that comes to mind is this: Divide the integer into N-bit chunks. Use each chunk as an index into a table with 2^N elements that you have precomputed to hold the parity of each possible chunk. Then xor the table values together.

I would guess that 8, or perhaps 12 or 16, is a convenient number of bits. Beyond that you run the risk of depleting your processor's cache with table elements.

However, I need to emphasize again that unless you actually measure the code both ways, you won't know if it helps.

Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty.

This is known as "bad luck."

--Robert Heinlein

Here's one I've not seen mentioned yet...

"C++ Essentials" by Sharam Hekmat, 14th July 2005
PragSoft Corporation

The author describes it as a concise introduction to C++ for beginners and without unnecessary verbosity. I wouldn't disagree.

I'm afraid I would. A quick search through the PDF file shows that it doesn't describe the standard-library vector template at all. I'll bet there are other similarly important facilities that it doesn't describe either.

Why wouldn't you use a map?

Depending on the input of the user in what way?

The problem is that the OP doesn't know how to solve this particular problem, and wants someone else to do it instead.

Use the next_permutation algorithm that's part of the C++ standard library.

I'd recommend lots of things, but not without seeing the whole program or what you're trying to do with it.

What happens if you include <string> before you include Profiles.h? If that doesn't solve the problem, can you tell us which line(s) the compiler reports as erroneous?

The FBI, CIA, and the military comes to your house via dragon and breaths fire onto your soul sending you to hell for eternity to burn, simply because you deleted a pointer twice. So next time be aware.

And don't forget Basement Cat!

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.

The results are undefined, which means that a program that does so is permitted to do anything at all.

Please post your entire program, using code tags, and tell us what is happening that you don't expect.

I like to read Effective C++ by Scott Meyers
c++ is thinking, ( bruce eckel)

I know Meyers and Eckel, and they're both good guys.

Between us (including Accelerated C++), we have three very different approaches to teaching C++. Some people may like one, some may like another. From my viewpoint as an author, the best thing to do is to play it safe and buy all three.

The usual way is that the variable's memory has been deallocated but the program hasn't gotten around to putting anything new in that particular piece of memory yet. So by luck it still has the last value you gave it.

Both of your examples are wrong: A function must never return a reference to a local variable. Whatever output such a program produces is the result of coincidence and cannot be trusted.

Since we're somewhat on the topic, are you planning a new edition for C++0x?

It would be nice. There's another project I want to get done first. In addition, there's a slightly odd problem: The copyright to the book is held jointly by Barbara and AT&T, because I was working for AT&T at the time I wrote the book. This fact comes with the weird implication that I do not have the legal right to contract with the publisher for a revised edition; only Barbara and AT&T have that right and both of them must do so before the revision can proceed.

What makes this doubly weird is that so far the publisher has not been able to find anyone in AT&T who can figure out who has the legal right to sign such a contract. The original contract says that AT&T is required either to agree to a revision or hand the work off to someone else, but the company has been through so many reorganizations since then that no one seems to know whose job it is to do so.

We'll try harder to untangle it all after this other project is finished, which should be early next year.

Thank-you Andrew Koenig and Barbara Moo..I appreciated yours words of wisdom.

You're welcome!

The reason is that DictionaryList (defined on line 7) and dictionaryList (used on line 11) are different types.

By default C++ prints floating-point numbers in scientific notation if they are so large that doing so will provide more compact output than fixed-point notation. By sending "fixed" to the output stream, you are asking it to print in fixed-point notation (i.e. with a decimal point at a fixed place in each output number) regardless of value.

If you replace "fixed" by "scientific," it will print in scientific notation regardless.

What happens if you change

... << setprecision(2) << ...

to

... << fixed << setprecision(2) << ...

?

Here you go.

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.

You say: "The problem asks to create a program with the complexity O(n) and i wonder if the program i made is a O(n) complexity."

A program with complexity O(n) that does what?

That's easy: None of them are even and odd.

In my example, I "cleared a string". The very concept of clearing a string is to empty it, and the way it is done in C is putting a "NULL character" at the beginning of it.

That's your opinion. Neither of us knows whether it is also the original poster's opinion. What we do know is that the original poster asked for a faster way to do what memset does, and putting a null character at the beginning of an array is different from what memset does.

Of course, the second method doesn't actually clear the memory, which is why it appears to be faster.

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.

What is VARIANT?

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.