Posts by grumpier

The only way in which a constructor can report an error is by throwing an exception.

The C++ standard has this to say (in Section 15.2 "Constructors and destructors" which is within Section 15 "Exception Handling"). [Note: I have not preserved font changes or emphasis in the quote]

1 As control passes from a throw-expression to a handler, destructors are invoked for all automatic objects constructed since the try block was entered. The automatic objects are destroyed in the reverse order of the completion of their construction.

2 An object that is partially constructed or partially destroyed will have destructors executed for all of its fully constructed subobjects, that is, for subobjects for which the constructor has completed execution and the destructor has not yet begun execution. Should a constructor for an element of an automatic array throw an exception, only the constructed elements of that array will be destroyed. If the object or array was allocated in a new-expression and the new-expression does not contain a new-placement, the deallocation function (3.7.3.2, 12.5) is called to free the storage occupied by the object; the deallocation function is chosen as specified in 5.3.4. If the object or array was allocated in a new- expression and the new-expression contains a new-placement, the storage occupied by the object is deallocated only if an appropriate placement operator delete is found, as specified in 5.3.4.

3 The process of calling destructors for automatic objects constructed on the path from a try …

When you mark a method of your class as virtual you give the user of your class the possibility to override that method. If you don't, the metod can't be overridden.

That statement is inaccurate on so many levels that I'm speechless. Non-virtual functions can also be overridden, but the behaviour differs from overridden virtual functions due to "name hiding", as described in the C++ standard.

The point of virtual member functions is that they allow functionality to be specified in a base class, and specialised in a derived class. For example, a generic Shape class might declare a virtual function named Area() to compute it's area, and another virtual function called Name(). Derived classes (which represent particular shapes) override those virtual function to give appropriate results for particular shapes.

class Shape
{
     public:
          Shape();
          virtual double Area() const = 0;
          virtual std::string Name() const = 0;
};

class Triangle: public Shape
{
     public:
          Triangle(double h, double w) : height(h), width(w) {};
          double Area() const {return 0.5*height*width;};

          std::string Name() const {return "Triangle";}

     private:
          double height, width;
};

class Circle : public Shape
{
     public:
         Circle(double r): radius(r) {};
         virtual double Area() const {return 4.0*atan(1.0)*radius*radius;};
          virtual std::string Name() const {return "Circle";}
      private:
            double radius;
};

Now, let's say we have a function that only knows about the Shape class, and wishes to print its name and area. For example;

void PrintArea(const Shape &s)
{
    std::cout << s.Name() << " - Area = " << s.Area() << '\n';
}

ah I see - dang that should be an error or a warning or something, shouldn't it??

In an ideal world, where compiler vendors care about perfectly diagnosing all errors in code, yes. In the real world, where compiler vendors prefer to focus attention on other things (eg performance) no.

In the real world it is undefined behaviour: it is actually a runtime error (tromping over memory) but compilers can't always predict runtime behaviour.

Your example;

char pos[5];
sprintf(pos, "%05d", 1);

can easily be converted into;

char pos[5];
some_function(pos);

//   and in some other source file

void some_function(char *x)
{
    sprintf(x, "%05d", 1);
}

so, at the point of the sprintf() call, the compiler has no information about the allocated length of string passed to some_function(). It is often technically VERY difficult for compilers to detect such cases.

Because of these possibilities (a compiler might be able to detect your case, but not technically able to detect the same problem after a minor code restructuring), the C++ standard simply defines both cases to be "undefined". This allows compiler vendors to simply ignore the thornier problems.
Compiler vendors therefore tend not to bother with detecting such things, particularly when programmers insist on the compilers giving features (fast compilation, good runtime performance) while remaining inexpensive.

It is necessary for the derived class to override all inherited pure virtual functions, otherwise the derived class remains an abstract class.

Provide a small but complete example of code that exhibits your problem.

Your code sample and description is not complete, and the cause of the error is probably in something you haven't shown or described.

Your first problem description had almost no relationship to your second.

The %x format specifier (for scanf() and related functions) reads a hex value (with the 0x prefix) and stores it in an int. If that integer is within the range of values that can be stored in a char, convert it to char. Otherwise report an error.

The only other bit you need to worry about is the 0x prefix in your file. You can work out for yourself what to do with those characters.

Your problem has nothing to do with use of namespaces.

DarkObject::Object::imageID is a non-static member of DarkObject::Object, so it would usually be initialised within a constructor of DarkObject::Object.

Your are attempting to initialise it as if it is a static member of DarkObject::Object.

Your basic problem is that some of your code can encounter errors, but you're not testing for them.

What do you expect a sequence of calls to content.get() (with different argument types) to do if one of the previous calls encounters an error? And, if an error occurs, what do you expect the contents of line1, line2, etc to be?

If your instructor is insisting your code loop based on content.eof() s/he should be summarily shot for encouraging bad practice.

I've been reading up on templates and they just seem like so much hastle for so little reward. I can't find anyway to effectively use it over vectors.

The standard vector is a template. A std::vector<int> is a different thing from a std::vector<double>, but both are implemented (within the library that comes with your compiler) using the same code.

I am just having a lot of trouble learning them because the concept seems so weird.

There are lots of scenarios. I'll just give you one. It is real, although I've described it in a hand-wavy manner. You'll have to think through it and understand in order to be convinced.

Picture you've designed a class or an algorithm (let's call it X) that works with data of type int.

Late on, you think to yourself "X only works with integers, but it could work with data of other types".

Without templates, you might copy the code from X and create a new version X1 that does the same thing with the double type, and a new version X2 that does the same thing with a string type, and X3 that works with some other type of data. To do that, you effectively have to copy the same code three times, with the only real difference between X1, X2, and X3 being their names and the type of data they act on.

After you've done that, you find and fix a bug in X, or add a feature …

Your problem is actually the first four lines of the main() function. I've added comments to the code that are related to problems on each line.

void main()    // main should return int, not void
{
sLink* pChainLink; // uninitialised pointer
sLink ChainLinkNo1 (pChainLink, 1);   // undefined behaviour: accessing value of uninitialised pointer
sLink ChainLinkNo2 (ChainLinkNo1, 2);    // compiler error: ChainLinkNo1 not a pointer, sLink's constructor expects one
sLink ChainLinkNo3 (ChainLinkNo2, 3);  // compiler error: ChainLinkNo2 not a pointer, sLink's constructor expects one

The only reason the compiler is complaining about the line you have highlighted is that it is the only constructor that might be invoked by your code, but you've provided the wrong type of argument.

mayabo's original code (other than the line cout << (A)DUDE; ) should actually work. The line name="bob"; in B's constructor is not required (and A::name can be made private).

The compiler is able to do the conversion "derived class to public base" (i.e. B to A) implicitly.

If you're getting errors, then either there is some code in play not being shown or you have a buggy compiler (really old versions of VC++ come to mind).

It would probably be better to make getName() a const method (optionally virtual) and for the operator<<() to have its second argument a const reference.

And "using namespace std;" before a class definition: wash your mouth out with soap, particularly if you do that in a header file.....

The C++ standard explicitly allows compilers to eliminate temporary objects if the only way of detecting if those temporary objects exist is to track constructor and destructor calls.

A special case of this is the Return Value Optimisation (RVO), which your compiler is implementing. This optimisation basically means the compiler can avoid multiple copies if a variable within your function (eg temp within operator+()) will only be copied into a variable in the caller (eg S3 in main()).

Tip: If a and b are integral values then a % b gives the remainder that is left over when dividing a by b.

Your main.cpp needs to have visibility of the definition of the conversion (or cast) operator. In other words, the implementation of the operator needs to be inlined into the vector.h: otherwise the compiler cannot instantiate the template.

Unrelated to your problem: it is usually a good idea for copy constructors to have their arguments const: copying an object usually does not change the original.

You are making the mistake of assuming that integer division yields a floating point result - it doesn't: it yields an integer result and integers can't represent fractions.

In your code i/2231 is an integer division, and yields an integer result by rounding towards zero (hence always yields zero if i is in the range [0,2231) ).

You need to force the division i/2231 to be a floating point division to get the result you expect. For example;

ShowProgress = ((double)i / 2231) * 100;

or

ShowProgress = (i / 2231.0) * 100;

Use reinterpret_cast or c style cast to casting..

That's using a sledgehammer to crack a nut. Problem is, it doesn't work because it destroys the nut.

A cast forces the code to compile, but then the result is a program that won't work as expected. Effectively it forces the compiler to pass an argument to a function when that function expects something different. If that function does anything with that argument, the result is undefined behaviour.

The better approaches are;

1) Change the argument types the function accepts, so it matches what you'll attempt to pass. I gave an example of that in my previous post.

2) Construct data in a form that is consistent with what the function expects. vmanes second example (after the // --- OR --- comment) is an example of that.

Try

void func(int (*)[2]);   // declaration

void func(int (*x)[2])
{
    // whatever
}

In this exmaple, func accepts an argument of type "pointer to array of two ints".

The initialisation of A in your example should be something like;

int A[2][2]={{1,2},{3,4}};

Don't use %d to print out pointers.

Other than that, try explaining what you expect the code to do, and then compare that with what the code does.

Saving data in an executable means a self-modifying executable. And self-modifying executables are most often the basis for mutating viruses.

While there are courses on computer security that teach techniques to counter malicious code, no reputable course would have an exam question that involves writing self-modifying executables.

Putting it into the executable would be no more secure than a text file: all a prospective password hunter would need to do is search for data known to be near the strings you store and .....

Access control, running your program with specific privileges, and encryption are more commonly used techniques.

shit lol i got 7 and im from the UK!

So you're now a man without a country?

Firstly, your iterative versions aren't equivalent either: your iterate over a different interval in the loop.

As to the differences with the recursive versions, there are all sorts of possible explanations.

1) The way you're measuring time may have different granularity. The clock time is not infinite resolution - hence the tip by ddanbe to do a large number of calculations: for small duration calculations the error in the computed interval may be larger than the actual interval i.e. your timing results may be meaningless because you're not doing enough calculations.

2) The conversion of an interval (measured with two calls of clock()) is generally required to be divided by the value of the macro CLK_TCK to convert the interval to seconds. You're not doing that, so it's possible you've introduced a scaling factor on the computed times.

3) Compiler optimisation settings can have a significant effect: for example comparing a "Release" build with a "Debug" build in the other languages. "Release" builds tend to be optimised for speed, but "Debug" versions are not.

My guess, in your case, is a combination of all three.

In some compilers (like VSC++) int is implied when only the const keyword is used (like you did). It is always safest to issue a datatype, however, since many compilers require it.

More significantly, the C++ and latest C standards also require it.

The "implicit int" rule was supported by K&R C. I'd have to check the actual standard to be sure, but believe it was deprecated in the 1989 C standard. It is definitely disallowed in both the C++ and 1999 C standards.

The only modern compilers that support "implicit int" are those that are seeking to maintain backward compatibility to very old code (at least 10 years old). Fewer compilers are doing that as time marches on. Those compilers will work if the "datatype" is provided, as const is a more recent innovation than declarations. Accordingly, there is never any practical reason in new code (or code that is newly modified) to avoid the "datatype".

Just to note, this sort of thing is better done with a macro

#define SIZE 101

Chris

Disagree. This sort of thing is sometimes done with help of a macro. That doesn't make it better.

Macros are not type safe, cannot be checked by the compiler, disrespect scope, can be broken by other macros, ...... but, apart from trifling concerns like those, I suppose one can argue they are a better alternative.

Gotta disagree with you on that one. steven woodman argues that science disproves Creationism in post 33 and I think many would agree.

OK.... I'll concede that there are some who argue that science disproves creationism.

However, if you read most serious published work on the topic, most scientists conclude that the creationism is based on a premise that cannot be subjected to a scientific test. Yes, they duck the question.

I do not like dictionary definitions in a discussion of science - they lack the nuance and focus needed

Only if you insist on imposing your own definitions of what science is. Manipulation of definitions is quite a convenient tool in discrediting competing ideas without having to resort to complete analysis or gathering of evidence.

I tend to 'Popperian' when I discuss science

Well, that explains a lot of your comments (and the material you have typed in from other sources into your posts).

The Popperian approach to philosophy is more a statement of how Popper believes things should be done i.e. he sought to impose a particular methodology, and deemed anything outside his methodology as invalid or non-scientific.

I read Principia and Principia Mathematica(I thought the second was part of a series - jeez, I kept thinking why didn't Readers Digest condense these) in my youth (I was pretty bored in high school and had already read all 3 encyclopediae in the library) and have no desire to do so again. Newton used 'axiom' and 'law' interchangeably - in other words its truth was taken for granted.

In Newton's day, as in classical philosophy, the words axiom and law were interchangeable (both having a root meaning "a rule or principle established through existing evidence"). The meanings have diverged somewhat since then in common language. Popper also, notably, uses them to mean different things.

If you read any authors work, but apply different definitions than that author did, …

You give too much weight to what a fact is - a scientific fact is an objective and verifiable observation. I may have underplayed, but you have overplayed it.

My definition of "fact" came straight from an english-language dictionary. I suppose I can't stop you questioning veracity of a dictionary to support your argument.

Well, yes and no - so let's go with the wiki version: People refer to a trial solution to a problem as a hypothesis — often called an "educated guess" — because it provides a suggested solution based on the evidence. Experimenters may test and reject several hypotheses before solving the problem.

wiki has it's value, but I would seek independent verification before treating anything there as fact.

The definition of "hypothesis" that I gave is is found in various standard texts on the philosophy or treatises on the scientific method. It is pretty easy to dig out references: there are many such texts, some predating relatively recent religions such as Christianity.

The "educated guess" is one form of hypothesis.

I could, after all, hypothesise that all members here, other than myself, are chimpanzees. It is a hypothesis as it can be used as a premise in any argument, and can be tested on the basis of evidence. An alternative hypothesis is that most members here are not chimpanzees. It is also a hypothesis as it can be used as a premise in any argument, and can be tested on the basis of …

I did reread your post. I'm not arguing for or against the existence of a Creator.

Neither am I. I am simply pointing out it is possible to construct a testable argument for evolution without relying on existence or not of a creator.

Similarly, if the "creationists are right", then point 1 is irrelevant too:

If the Creationists are right, then there IS a Creator, so the second part of the premise about evolution is irrelevant.

That's a self-fulfilling argument though. You can't prove or disprove an argument by assuming that an unproven belief is correct.

Scientific method requires that hypotheses and theories be testable. There is no requirement they be supported by a belief or faith in something that is not testable.

Creationism is a belief or faith, and is not testable: all arguments put forward to make a case for creationism have some element of accepting that the original belief or faith is proven without testing. That is also called the Pygmalian effect.

Interestingly enough, those who point out evidence concerning evolution do not claim it proves or disproves creationism. Only creationists claim that. It is only creationists who argue that a creator would not allow evolution. Again, that belief is not testable.

What's dogmatic about the fact that globals are to be avoided at all cost?

Dogma (n) : A firmly held belief based on faith, and often stated as fact.

This is not true. Scientific methods can disprove creationism, we just need to prove evolution. By proving evolution would we not be debunking creationism?

No. Evolution is not the opposite of creationism, so proving one does not disprove the other.

Facts: Things that just are; examples are bones, DNA, rDNA, RNA, black holes, neutron stars, mitochondria, basalt, marble, leaves, stuff found in rocks that are not rocks. The universe is filled with facts.

A fact is something established beyond all doubt, on the basis of evidence and reasoning, to exist or have happened. To establish something beyond doubt, there must be some awareness of doubt. Which means some cognitive process that can objectively and completely examine the evidence and reasoning.

hypotheses - a method to tentatively organize facts into patterns that can be understood; and, this is one of the important parts, the hypothesis must predict something that is not known yet; another important part is that it must be reproducible; and it must be falsifiable.

Not really. A hypothesis is a proposition assumed as a premise in an argument, and tested on the basis of evidence. A hypothesis may be proposed as a means of organising facts into patterns, but need not be.

It is not necessary that a hypothesis predict something not yet known. It is required to predict something that can be tested through evidence, and falsifiable if conduct of the test yields a result that is not predicted.

A hypothesis is not required to be reproducible. For example, a hypothesis can be tested statistically. The samples, from which statistics are derived, provide a body of evidence and provides evidence to accept or reject a hypothesis to some specified level of confidence. However, given the …

You can also use a switch case statement instead of multiple if / else if

Only if the behaviour sought is comparing an integral variable against a fixed set of values. It is not possible to use a switch statement with non-integral types, or have a case that is not a compile-time constant.

Globals are to be avoided at all cost. They can get you in great trouble.

Like all dogmatic statements, this is correct sometimes and incorrect sometimes. Global variables are useful (without causing trouble) in some circumstances and not in others.

In fact OO was partly invented to avoid globals!

That's not true. It happens that a lot of well-designed OO designs or code will not use globals, but a lot of well-designed programs (OO or not) do not use globals. Eliminating globals, however, was not even a minor goal in creating the OO design or coding techniques.

Premise 2 is flawed because you are neglecting one of the main premises of those who believe in Creationism. God is perfect, all-powerful, all-knowing. Thus unlike when we mere mortals create something, there will be no false starts, no trial runs will be needed, no starting over, since He'll have been able to predict everything and do everything right the first time. No need to evolve, no need to improve, no need for all of the randomness and wastefulness of an imperfect process of evolution. So if "the creationists are right", God would get it right on the first try.

If you read my post again, you will see that I did not claim my theory is proven. I noted the way to disprove my theory is to prove the existence of a creator, and then prove that creator does not require evolution. You are asserting that is the case, not offering proof. Offer proof of your assertion, and I will concede my theory is incorrect. Otherwise, I will maintain that it is not disproven.

That actually leads to something else. Why would such an unflawed Creator create such flawed creations?

If you prove the existence of such an unflawed creator, you will have disproved my theory and you will also have the option of finding and asking her. :icon_lol:

My case in support of evolution is much simpler. And it works whether the creationists are right or not. ;)

1) If there is no creator, then things must have evolved somehow.

2) No intelligent creator will just build everything first go: there will be trial runs, false starts, starting over, etc. That is evolution!

No need to prove that people are descended from apes (although a lot of people provide strong evidence in support of this).

The only thing needed to disprove my theory is proof of the existence of a creator and then proof that creator does everything on the first go.

If there are common things that all classes which handle triangles have to do, put those functions into their own class (eg TriangleModelFile derived from ModelFile). Derive the specific/multiple classes (eg SpecificTriangleModelFile) from that generic triangle-handling class, and give it specific behaviour it requires.

It's often a good idea to make base classes are abstract (i.e. you can't instantiate them) and derived classes are concrete (i.e. they can be instantiated). That way you reduce the temptation to move things to a base class that are only needed by some derived classes.

Don't use the first option. The whole point of a Base class is capturing functionality that is common to all derived classes.

As to the second option, there are many ways. Such as....

Provide a protected virtual function named UpdatePoints() in your base class. Implement it to do nothing (i.e. a body with nothing in it). Call it from your MovePoints() function, preferably after updating the vector<Point> member.

Override it in the derived class as appropriate (eg in your class with triangles, use it to update the vector<Triangle> based on the updated points).

Making it protected simply ensures it can't be called outside the class hierarchy (as there's probably no point in that). That's optional, depending on whether you want to allow it to be called by arbitrary code, obviously.

but grumpier take an advice stop being grumpy
and btw wash your tongue with soap and rinse it properly with
shampoo and maybe just maybe it could wash off that
sour spot off your tongue...cheers

Pfft! People earn what they get from me: good or otherwise.

void main()

Wash your mouth out with soap. main() returns int.

im trying for over 3 hours to understand and inbed what you suggesting, but get errors during compilation, i'm very new to c, and dont fully understand the terminology yet, do you mean to put && printf("Invalid Entry"); and nest it during condition of while statement?

i feel embaressed, sorry for such goofy questions

I'll answer your question with a question.

Under what conditions will

if ((x < 1 || x > 4) && printf("Goofy"))
{
    printf(" is also known as Dippy Dawg");
}

print out "Goofy is also known as Dippy Dawg"?

A post-test loop is a generic name for a loop of the form do { ... } while (condition), as opposed to a while(condition) {} loop.

The solution, if you have to do that, is to have the printf() statement reporting the error within the loop condition. To do that use;

1) shortcutting occurs with operations like && and ||. For example, if x is true, a test x && y does not evaluate y.

2) printf() returns the number of bytes output i.e. if it succeeds in printing your error message, it will return a non-zero (i.e. true) value.

You're missing a closing brace at the end of main(), so the compiler thinks you're trying to implement a function inside the body of a function - which is illegal.

(1) strtok() assumes both its arguments are strings that are terminated with a 0 character. Behaviour is undefined if that is not true.

2) strtok also returns NULL if it cannot find a token being searched for. strcmp() yields undefined behaviour if either argument is NULL.

3) A segmentation fault is one possible symptom of undefined behaviour.

4) The fact that you are observing a segmentation fault is occurring at a "precise point" is irrelevant. The cause of segmentation faults is not necessarily the line where they are reported: the actual cause can be any code executed at or before that point.

1) Get rid of the values array that is declared in biggest .... work with the array a that is passed instead (use a and count, rather than values and SIZE in the loop). Otherwise, biggest() will only ever find the largest value of that particular array.

2) You need to return a pointer to the largest element, not the index.

3) You've been advised to use code tags and have ignored that advice. Be aware, if you persist in not doing so, that people here will not be inclined to help you again. Look here for more information.

getline() approach also allows handling of cases where someone enters a partial name (eg first name only vs first and last name). However, it is necessary to parse the line input to determine whether it contains one or two (or more) fields.

Then ask your teacher for clarification of what he/she means. As worded, the question does not involve writing a program.

1) People here are not free homework generators; at best, you'll get help if you show evidence you've tried and encountered a particular problem.

2) This homework exercise does not require writing a program.

Don't know if it helps. I myself am not sure if it's ok to write it, but compiler doesn't complain:

void func(int n){
    int a[n];
    for (int i = 1; i <= n; i++) a[i+1] = i*i;
    for (int i = 1; i <= n; i++) std::cout<<a[i+1]<<std::endl;
    return;
}

The array declaration int a[n]; is not valid C++. Your compiler doesn't complain because it supports this as an extension. (Your compiler might also support the 1999 C standard (where such things are valid)).

To answer the original question, though, it depends on what you mean by "not using new key (without malloc too)". If you mean that your code does not invoke operator new or call malloc() directly, then you can use a standard container (std::vector, std::list, etc).

However, those containers work by performing dynamic memory allocation behind the scenes ... which means that code you write may not employ operator new or malloc(), but the containers themselves might.

Oh, and I really think you are rude to describe other's comments as rubbish. That's plain rude and uncalled for.

It is equally rude to provide misinformation, and describing a trivial concern as a timebomb is misinformation - and, worse, misinformation that can deceive beginners. I certainly agree it is better not to place function declarations inside the scope of functions, but the consequences are pretty insignificant. Compiler errors (and handling them) are part of the normal learning process by which beginners build knowledge.

It's usually called a compiler!

Quite a few mainstream compilers have an option to emit assembler code (for the target system) rather than compiled object files. You need to read the documentation for your compiler to find the relevant command line option or (with an IDE) configuration setting.

Couple that with options or settings for compiling without optimisation and .... poof!

I don't know about others but to me putting function declarations inside main is just like a potential time-bomb, even if at this moment your functions do not call each other.

Oh, rubbish! Your description is excessive. The worst thing that can happen is that another function needs to call the declared function, and a compiler error occurs unless the function declaration is moved (to file scope) or replicated in the other function. A compiler error that can be eliminated with a simple copy or move of a line of code is hardly catastrophic, so does not warrant being described as a potential time-bomb.