Anything that prevents the program from compiling correctly is a bug as far as I'm concerned and anything that helps get rid of these is a debugger. Coincidentally compiler errors are in effect a debugger tool. I find it therapeutic to solve the problem most of the time.
You should abandon that definition because that's not the definition used by the rest of the world.
"A software bug is an error, flaw, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways. Most bugs arise from mistakes and errors made by people in either a program's source code or its design, and a few are caused by compilers producing incorrect code." - Wikipedia
I see no difference. A Syntactic error is still an error made "...by people in either a program's source code..."
But I already told you. A bug is anything that prevents a program from doing what it should. i.e. if you compile a program you expect it to complete, if it doesn't that's a bug. I'm not saying that it's the only type of bug (at no point did I say it was).
But I do accept the definition as Wikipedia has it noted. A common error that prevents a compiler from building is a Syntax error, where someone perhaps not declared a main function. This is a bug.
That's not a bug at all. I'm not sure you're not trolling here actually.
Lets say you have a car that takes unleade gasoline. You decide instead to just fill it up with potatoes. You go to start your car and sure enough it doesn't start. This is not a fault of the car, it's a fault of the user. Therefore, not a bug.
But I already told you. A bug is anything that prevents a program from doing what it should.
But if your source doesn't compile... there's no program.
There can't be a bug in a program when the program doesn't exist.
A common error that prevents a compiler from building is a Syntax error
No... a syntax error is not a bug. It's a syntax error.
The syntax bug wikipedia refers to is actually valid syntax which has a logical mistake.
Look at the example it gives:
For example, in some languages x=5 will set the value of x to 5 while x==5 will check whether x is currently 5 or some other number.
It's referring to the classic "= is not ==" problem:
if( x = 5 ) // this is a bug, but NOT a syntax error, because it's legal C/C++ syntax
that is a syntax bug.
This is not:
if( x @$ 5 ) // this is not a bug, because it will not compile. It's a compiler error
Nowhere in that wikipedia article does it even suggest that compiler errors are bugs, nor does it give any examples of compiler errors.
I'm not restricting my definition to 'only' conceptual errors like Disch seems to be trying to do.
I don't know why you're so dead-set on refusing this. I'm telling you... the entire world of programmers (both professional and independent) disagree with you. You are all alone in your definition -- with maybe a handful of other misguided souls.
If you continue to use the term incorrectly, 2 things will happen:
1) You'll make yourself look foolish
2) You'll confuse (and will be confused by) people you talk to who are using the term correctly. Again... this will be everyone.
I think ResidentBiscuit might be right. You must be trolling. And I'm being a sucker for it. Blarg.
I am serious. I just have a wide definition of what I call a program too apparently but never mind, I don't think we're going to agree on this matter. Even though it has Syntax errors under bugs XD. I think we need a lesson about where the term 'Bugs' came from in the first place. I.e bugs actually getting fried (or is that an urban myth), don't have a program if it can't run right? =D (waaaaay before C++, when transistors were still a foot tall).
Everyone understands (even beginners) that a bug prevents a program from working, for whatever reason most don't care whether it's a logical bug, a concept bug or a syntax bug. They're all bugs.
Resident biscuit. If you expect your car to take potatoes because that's what you wanted it to do in the first place, yet built it to be unleaded... you see where I'm going.
I think the problem here is that it is the difference between a program not working correctly, or no program being made. When a syntax error occurs, there is simply no program that exists- it doesn't compile whatsoever, and won't until the syntax error is fixed. A bug in this instance is when the program does compile, but does not function correctly. Essentially, a syntax error doesn't stop a program from working. It simply denies the program the ability to exist in the first place.
Boy oh boy. If you're expecting something to do something and it's doing something else...we'll call it a glitch and be done with it. =D
~Ispil, I get the point, it just doesn't matter, the pedantic definition does not change my behaviour. If you want to limit the word bug to only computer programs and things that don't 'quite' work as they should but in effect it still works, that's purely up to each and every person. However it doesn't matter to me where in the process of software development I encounter the error, an error is still an error and a bug is still a damn bug and I will beat it with a club until either it works or I invent something new. (What I mean by that is that I will look at what's wrong, go through the program and attempt to solve it). Whether it's a compiler error or a logical bug...it's really all the same.
But it's nice to see some hard-core devs really sticking up for their definitions XD. It's like walking into a comic store and telling someone their hero is a 2d character that doesn't actually exist. Heheh.
~Cire, ....scrap the word file for 'thing'. If something doesn't work how it was intended perhaps to the point of not working at all, to me, it's buggy. If the handle on my cup breaks, the cup is buggy/faulty/ has a serious structural error. I really don't understand why it is useful to differentiate one error from another, an error is still an error and you still have to solve them.
> if something goes wrong with the IDE...you have to get another IDE.
>> The likelyhood of this is extremely low unless you're using some
>> experimental beta version of an IDE or something. Well established,
>> commonplace IDEs are extremely stable and reliable.
Dev-cpp, Borland-C++, Turbo-C++
> Have you even tried getting a * working on Windows?
> sudo yum install libstdc++ gcc gcc-c++ gedit cmake
>> A beginner to programming probably doesn't even know what a command
>> line is, let alone how to use it. An example from a quick tutorial would
>> probably be copy and pasted without changes.
I expect for them to know how to use a computer
> if you don't understand Sudo Yum...are you using Linux?
_ cASe seNsItiVE
_ ¿what are you eating? ¿yogurt?
_ apt-get, aptitude, pacman
> you should understand the basic idea:
> - Create a project
> - Add files to that project
> - Edit them
> - Press the "build" button
¿a project? ¿what's a project?
I just want to test something quickly
My files are all in the same directory, ¿why they are not in the project?
> until you start getting into multi-file programs (which absolute begginers
> are not going to do)
you learn functions, you've got several files.
> I have never been able to simply install a compiler.
o_O Read your computer manual.
--- Hi, I need help speeding up my program (...)
--- ¿Are you compiling with optimizations?
--- I don't know.
Well start acting serious. Saying you are serious is not enough to convince anyone that you are.
One of the clues about a TROLL :
Asking a question designed to provoke lots of replies, then defiantly arguing against the quality advice being given, in order to provoke more replies.
If you ask questions - then be prepared to accept the advice, especially when you have a demonstrated (or putting out a perception of) lack of knowledge.
The reason why we don't like trolls is they are a big waste of time. So I am not going to bother with any more of this. I just hope it doesn't descend into a debate between senior members here (Disch vs ne555 say). Of course they can do whatever they want - I just hope they don't waste their time doing it.
So this a suspected troll that I am picking early, I hope we are not here in 500 posts time debating how to get rid of this troll.
> My files are all in the same directory, why doesn't gcc build them?
g++: fatal error: no input files
$ g++ .
.: file not recognized: Is a directory
collect2: error: ld returned 1 exit status
$ g++ *.cpp
> So tell them how to do it.
> Compiling with optimizations in an IDE is just as easy as compiling with them without one.
Whatever tool they are using, it's their tool, so they should RTFM and learn how to use it.
I don't know about you, but I used a computer for five years before I found out about command lines. I used it for another year before I found out about the use of the asterisk for file names. And I used the computer for long durations every day experimenting and reading about things - something I expect most beginners probably haven't or can't have done. Most people at my school come to me for computer problems which generally tend to be caused by not scrolling down a list to see the rest of the options.