QtCreator automatic member declaration

[wysota]

Well I can't guess the great wysota can do that : ) From what I can see on this forum, you can freely abandon Qt and start doing something else ([EDIT] Gee in a good sense! : D). But can other people do the same? I can't!

Actually I was thinking about equipping my car with an onboard Qt-driven computer system

I wouldn't bet on that... 90% will come and complain at the beginning, later on they would probably get how it works and, in future, they will be the ones - like me - that come to a forum asking if a certain feature exists.

Nnnnnooo... Maybe 10% of those 90% would do that. Just browse the forum and see for yourself. Call me a pessimist but I'd rather call myself a realist.

Mmmh actually I knew the Back/Forward, but I'm not really loving it. Probably I'm missing something about how it works or I'm just not used to it. Anyway, since you point this out, I'll give it a more deep try.

It used to work better than what it does now but it's still useful. Especially together with F2.

True, but afaik this results in bigger files to compile, slowing down the compilation process.

If you add all the bits, the compilation is much faster. It can save up to ~80% of the compilation time (or maybe even more if your project is complex enough). The downside is you get a really huge file on your disk.

someone told me that he could cut down the compiling time from hours to minutes just by working on include files.

Using precompiled headers would have yielded a similar if not better effect.

So, it's a good suggestion in my particular case, but generally speaking this is the kind of automation that may produce bad results if someone don't know what he's doing.

I may be misunderstanding what you mean because the final binary code with precompiled headers is exactly the same as without them. This is an area where you can't really hurt yourself. Unless you do something insanely stupid, of course.

I remember I did the SAME exact error when I started to learn C It's like 10 years now, but it's not only a matter of automation: I used to program with notepad and compile by hand, but the manual I was using just didn't mention what a "library" was.

That's a different matter.

I'm saying that, with evolution of C++, new approaches can be used.

But you still have to support the legacy code.

If your software crashes with negative wages, it is still correct, because I'm not asking you to handle negative values.

That's your point of view. I see it that any software that crashes is a badly written software. And I don't agree with the rest of the paragraph you have written but I feel I'm not going to convince you so I won't even try.

No sorry, I can't absolutely agree with that. If no requirements are set, multiple interpretations are legit.

And in this moment you can say goodbye to formalism, models and asserting correctness of the code. The most you can do is say your code looks correct or works correctly for the input given. Nothing more. You certainly cannot say your code IS correct.

Correctness is a function which must depend on requirements and specifications, if you don't provide them, you're not talking about correctness.
This is why, I think, being a requirement engineer is so hard

So if you're not talking about correctness please stop saying your code is correct. You can say "my code is." - I can certainly agree with that.

Actually, in mathematics division is not defined with a denominator = 0, so it's perfectly legal to say "for any integer": talking about "division by 0" is a non-sense. The result simply doesn't exists, so specification is not required.

A very strange approach to mathematics. You can't say that dividing two integers results in an integer if you can find such pair of integers that result of the operation is undefined. What you can say is that all results of integer divisions are integers. You can't say that diving any two integers results in an integer.

This doesn't exclude, of course, the fact that you can instruct the computer with a nonsense (i.e. divide by 0) and it will fail.

It's not a nonsense for a computer. It's perfectly viable to build a computer that will return a result for division by zero. Actually any computer does that, it just signals the special case with an exception.

Your question is really funny, because you didn't provide me the interpretation of "correct".

If we continue this path let's start with defining "me", "you", "computer" and the rest of the world. I'm sure you know what I mean by "correct" here.

But since the alternative to crash is to produce a random value, or to hang forever calculating something that can't be calculated, I think program is correct.

Crash or produce random value? Hmm... This should work:

int main(int argc, char **argv){
  if(argc<2) return nan("int"); // or return a predefined value
  int b = atoi(argv[1]);
  if(b==0) return nan("int"); // or return a predefined value
  int a = 7;
  int x = a/b;
  return x;
}

int main(int argc, char **argv){
  if(argc<2) return nan("int"); // or return a predefined value
  int b = atoi(argv[1]);
  if(b==0) return nan("int"); // or return a predefined value
  int a = 7;
  int x = a/b;
  return x;
}

To copy to clipboard, switch view to plain text mode 

If you don't have a specification (explicit, but also implicit of course), you can't talk about "correctness"

Ah, now we're getting somewhere. I think what you mean is "validation" or "verification" and not "correctness" - http://en.wikipedia.org/wiki/Validat...d_verification
Correctness would be an absolute state while the other two terms would be determined against some specification.