Posts by arkoenig

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.

Now if i use

#include <stdio.h>

main()
{ int c;
 while ((c=getchar()!=EOF)//get the sinle char
  putchar(c);//prnt it on cmd
}

then your program will not compile because of the unbalanced parentheses in line 5.

IIRC, if a function that is declared to return a value falls off the end without doing so, the C89 standard permits this state of affairs so long as the caller does not try to use the value that the function failed to return. In other words:

int foo()
{
    /* This function should return an int but doesn't */
}

int main()
{
    foo();      /* Discards the invalid value, so the call is OK */
    foo() + 0;  /* Undefined behavior */
}

I do not remember for sure whether C99 tightened this rule.

What you've written is really a C program. I suggest that you either rewrite it in C++ or ask your question in the C forum.

Also, please use code tags.

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.

I think you should start responding to what I actually wrote, rather than to what you imagine I'm thinking--because your imagination is incorrect.

You are making an equally invalid assumption that tax payers and citizens who elect the gov't would be unwilling/unable to pay anything for healthcare.

I'm making no assumptions--I'm just pointing out the error in your assertion.

The extreme case of low cost and equal treatment is the gov't pays at cost for all treatments it can afford to make available which are available free to all people and any other treatment is not available at all.

And if the government decides not to pay for any treatments, that yields the extreme I mentioned earlier.

Either way, it proves my point: Using "low cost" and "equal treatment" as your only measures of merit leads to an absurd result--a fact that shows that those measures by themselves are not appropriate, despite superficial appearances.

Well the reverse: less equal treatment at higher cost carried to its logical extreme is one person in the world spending all the money of the world to have his temperature taken with a solid gold, diamond encrusted thermometer...

You're wrong, because you're assuming that both extremes involve forced transfer of wealth, and there's no justification for that assumption.

So the other extreme is that people get whatever medical care they are able to pay for, and the market sets the rates. That state of affairs has its own disadvantages, of course; but as far as I can see, it is better in every way than the other extreme.

The phrase "more equal treatment of patients and lower costs overall" looks on the surface like it is a desirable state of affairs, but looks can be deceiving.

Consider: If health care were stopped entirely for everyone, then costs would be zero and all patients would be treated equally, because there wouldn't be any.

So the phrase describes a state of affairs that, taken to its logical limit, would be essentially the worst possible. Why should it be assumed to be desirable in smaller quantities?

All forms of government will eventually break down due to man's tendency towards corruption and greed.

Switzerland has been a democracy since 1250, so apparently this breakdown sometimes happens very slowly.

Please tell me how the two statements are related???

If you're referring to my comment, the relation between the two statements is that in order to make each of them, one must believe something that is obviously not true. In other words, one can blame Republicans for actions of a Democrat-controlled Congress in the same way that one can believe that Bill Gates is thousands of times more wealthy than he actually is.

In short, I'm agreeing with you.

If you're referring to someone else's comment, I suggest you clarify whose comment you mean.

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.

Your problem is that in line 12, you try to calculate the values of num1-1 and num2-1 before you have given values to num1 and num2.

If this information is not enough to allow you to fix your problem, then you don't really understand how variables work, and you need to go back to the beginning of your C++ book and start over.

I think this question would be better asked in the C forum, as the program you posted has no significant C++ content.

Sorry, that's not enough information.

Please post the FULL, EXACT text of the mssage you're getting, along with the code surrounding the asssert statement that's failing.

When I try to run your code, it fails because "it" has the wrong time. When I remove the erroneous assignment to "it" in line 6, and the statement that tries to use "it" in line 8, the code prints 4 (correctly), not 6.

So if your code is printing 6, that means that what you're running is different from what you posted. I am not going to waste any more time by trying to read your mind.

What's the error, and where is it happening?

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.

You need to specify the problem more precisely, because 1678.6 is probably not exactly representable as a double. So the question arises as to how close a representation you are willing to accept.

The obvious solution would be to multiply the number by 10, round to the nearest integer, and then divide by 10. Is that good enough?

I think it would be more useful to talk (probably in another thread) about what characteristics make a C++ book useful and which books have those characteristics.

If people just post books they like, reading that post doesn't tell you much because you know nothing about who posted it.

Line 298 of your code inserts an entry into your map that contains the address of a local variable. When function execution finishes at line 300, that local variable goes away, leaving a dangling pointer in the map.

Later, when you try to access the object to which the pointer points, it is no longer there, causing your program to crash.

@mike_2000_17: Apparently we were typing our respective responses at the same time.

I do not understand what you expect these two statements to accomplish:

letterNeighbors.resize( 123, vector<string> (neighborSize) );
letterNeighbors[templateLetter][i] = neighborLetter.substr(i);

After you have executed the first of these statements, letterNeighbors will have exactly 123 elements, each of which will be a vector. So when you execute the second statement, if the value of templateLetter is >= 123, the result will be a subscript out of range.

If v is a vector, v has undefined behavior if i is out of range (i.e. if i >= v.size()). Accessing v does not create that element (or any element) if that element does not already exist.

If you want to append a new element x to v, you can execute v.push_back(x), which will increase the size of v by one, and put a copy of x into the newly created element.

The default vector size is 0.

What's the error? Compile time or run time? If run time, have you tried putting in code to determine just which statement is causing the trouble?

This looks like a version of the NP-complete knapsack problem to me.

Two things as starting points:

1) In your second code fragment, you have two members named next. You can't do that.

2) This is really a C program, not a C++ program, so you would be better off asking your question in the C forum.

I missed that even after originally thinking this question would boil down to that rule. The moral of the story is that undefined behavior can catch anybody who's not being careful. ;)

Yeah--bugs are like that, aren't they?

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.

And why do you think that the pre-increment of y is ever executed?

Why do you think y should be 6?

The statements on lines 29 and 31, among others, are nonsense. If you do not understand why, please study your textbook until you do. This is too fundamental a misunderstanding to be worth spending the time to explain.

&*raiz means "give me the address of the contents of the thing the pointer raiz is pointing to"; '&' is an operator. It's a bit silly, as by definition raiz itself equals the address of the thing it is pointing to.

Actually, &*raiz by itself would make sense if raiz were, say, an iterator rather than a pointer. What doesn't make sense is to try to assign a value to &*raiz -- unless *raiz has a type with unary operator& defined. Such types are best avoided in any event.

How about explaining what you expect the statement to do? It looks like nonsense to me.

You said that your teacher gave you code that contains the line:

COORD thing = (x, y);

Either you are mistaken or you should get another teacher. Because this line of code has the same effect as writing

COORD thing = y;

but the form in which it is written suggests that whoever wrote it thought it would do something different--otherwise, why write it that way?

I am guessing that your teacher actually wrote either

COORD thing(x, y);

or

COORD thing = {x, y};

but either way, something is definitely not right about the version you posted.

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.

Nothing like dogging on your own language huh?

No, he was actually aiming at Smalltalk when he said that.

I have yet to see anyone nail down a concrete, consistent, and agreed upon definition of object orientation that excludes C++.

Well, Bjarne once defined object orientation as "slow graphics" -- but as he was being only partly serious, that definition only partly counts.

If you wanted to be sure that member b was always initialized, you should have written a default constructor to initialize it. The reason for this rule is the possibility that a class might contain a (potentially) large array that you might not want to initialize all at once.

Here's the answer to the original question.

If you have a class that defines one or more constructors explicitly, but does not define a default constructor, then every object of that class must be explicitly initialized. For example:

struct A {
    int n;
    A(int i): n(i) { }
};

Here, I have defined a class with a constructor (A(int)) but no default constructor. Therefore, if I write

A a;

my program will not compile because I did not initialize my variable.

Such a type cannot be used as an element type for a vector:

vector<A> v(10);

because there is no way to initialize v's elements.

OK, that handles case (a).

Case (b) talks about a class that does not define any constructors at all. In that case, the class gets a default constructor automatically, and that default constructor value-initializes each data member of the class. For example:

struct B {
    int b;
};

Now the expression B() calls the (implicitly generated) default constructor of B, which value-initializes the data member. So, for example:

void f()
{
    B b1;        // b1.b is uninitialized
    B b2 = B();  // b2.b is zero because B() is value-initialized
}

In summary:

When a class defines one or more constructors but does not define a default constructor, it does not get a default constructor; every time you create an object of that class, you must initialize every object of that class.

When a class …

I see nothing wrong with the code you've posted. Please post a small, complete file together with the error message you get when you try to compile it.

Because you can write

vector<int, some_other_allocator<int> > v;

and if some_other_allocator is appropriately defined, you can impose a vector data structure on memory that is allocated in a way that some_other_allocator defines.

Many people will go through their entire careers without ever needing to do this, but it's there for the applications that need it.

How about inserting code before line 37 to verify that x and y are in range?

Without seeing the program you tried to compile, there's not much anyone can do.

If you have the same problem, it can be solved in the same way.

What is true is that in his paper Structured Programming with goto Statements, Knuth gave an example of a clever programming technique for removing a boolean variable from a program by duplicating the relevant portions of the program and jumping back and forth between then with goto statements. And it is also true that it is possible to write code that uses goto statements that cannot easily be rewritten without them unless you introduce additional variables. But there's a theorem that says that any program that uses goto statements can be rewritten without them as long as you're willing to duplicate code or introduce additional variables; which is why I'm skeptical.

I have heard that Knuth actually designed an algorithm that required a GOTO.

Unless you can provide a citation, I'm skeptical.

I suspect the solution is

std::vector<passenger*>& passenger_queue::passengers_at_floor(int floor_) const

The point is that at present, passengers_at_floor is permitted to modify its object, but you're passing it a const object, namely the key from a map.

So you need to add const to the definition of passengers_at_floor, as a promise that it will not modify its object. Of course you need to add it to the declaration inside the class as well, not just to the definition.

The problem you are trying to solve is a variation of the Knapsack Problem. There is no exact, general, efficient solution to this problem.