i use ifort and gfortran to compile my Fortran program.
However i also use a coworkers source and he has got a lot of unused variables.
How can i suppress these for the compile, seeing as they are not really an error?
However i dont want to disable -pedantic and -stan in the compiler options and thus want all the other warnings.
cheers and thanks for the help
With ifort try -warn [no]unused.
And, while I'm here, I suggest you remove unused variables. The compiler may not regard them as an error, but disciplined software engineering regards all dead and unused code as erroneous; it imposes a maintenance burden.
Yes, as High Performance Mark pointed out, the best way to get rid of those warnings is to tell your coworker to fix his code.
As for easy solutions, with gfortran, have a look at the -Wunused-### options in gcc's manual: Warning Options. Notably, -Wno-unused-variable might do what you want.
[...] why the heck would you use gfortran when you have Intel Fortran ?
When developing, running your code through multiple compilers helps in finding bugs and producing portable code.
Related
I have a few related questions about pragmas. What got me started on this line of questions was trying to determine whether it's possible to disable some warnings without going all the way to no worries (I'd still like to worry, at least a little bit!). And I'm still interested in the answer to that specific question.
But thinking about that issue made me realize that I don't really understand how pragmas work. It's clear that at least some pragmas take arguments (e.g., use isms<Perl5>). But they don't seem to be functions. Where do they fit into the overall MOP? Are they sort of like Traits? Or packages? Is there any way to introspect over them? See what pragmas are currently in effect?
Are pragmas built into the language, or are they something that users can add? When writing a library, I'd love to have some errors/warnings that users can optionally disable with a pragma – is that possible, or are they restricted to use in the compiler? If I can create my pragmas, is there a practical difference between setting something with a pragma versus with a dynamic variable, aside from the cleaner look of a pragma? For that matter, how do we decide what language features should be set with a pragma versus a variable (e.g., why is $*TOLERANCE not a pragma)?
Basically, I'd be interested in any info about pragmas that you could offer or point me towards – though my specific question is still whether I can selectively turn off certain warnings.
Currently, pragmas are hard-coded in the handling of the use statement. They usually either set some flag in a hash that is associated with the lexical scope of the moment, or change the setting of a dynamic variable in the grammar.
Since use is a compile time construct, you can only use compile time constructs to get at them (currently) (so you'd need BEGIN if it is not part of a use).
I have been in favour of decoupling use from pragma's in the past, as I see them as mostly a holdover from the Perl roots of Raku.
All of this will be changed in the RakuAST branch. I'm not sure what Jonathan Worthington has in mind regarding pragmas in the RakuAST context. For one thing, I think we should be able to "export" a pragma to the scope of a use statement.
I need to use the CobraToolbox for a course and I am wondering if it is compatible with Octave.
Even googling for this doesn't return much results..
Thanks in advance
Unless someone has published their results, you can't know without trying it. However, there is a very high likelihood that it will work on Octave, here's what Jordi has to say on this issue answering this question.
I am new to Octave and was wondering if it is possible to use matlab
toolboxes in Octave?
It depends on what you mean by "Matlab toolbox". If you mean the code
that came with Matlab, it's probably a license violation to use it
with Octave, assuming you can compile it for Octave when it's
necessary to compile.
If you mean free code out there you found on the internet that was
written for Matlab, it is likely it will work on Octave. Just try it.
If you need to compile mex files, the "mkoctfile --mex" command may be
of use.
If you want to have a rough equivalent of the Matlab toolboxes in
Octave, try the Octave-Forge packages:
My personal experience is that Octave has become extremely good at accepting Matlab code. I would hazard a guess that any time you spend setting up Octave and this toolbox will be worth it. Even the MEX files appear to have a portability mechanism. Unless they are using some very specific features like addpref for toolbox persistent data, it will slide right into Octave. Even if they are using the prefs, it could be modified to live in Octave.
(I defined this program in terms of a C++ program because I faced this thing while coding a C++ program, but the actual question is language-agnostic).
I had to copy chars from one char* buffer to another buffer. So, instead of doing a #include <cstring> for strcpy, I wrote a small snippet of code myself to do the same.
Here are the thoughts that I could think of then:
Standard library functions are generally the fastest implementations that one can find of a certain code.
But it would be unwise to include a big header file if you're going to use only a very minor part of it (that's what I think happens).
I want to know how right I was in doing so, and what can be defined as a bound of coding own snippets after which one should revert to using headers.
The first rule of thumb is "don't reinvent the wheel". And remember that your wheel will probably be worse :-) (there are very good programmers that write the wheel provided by your compiler).
But yes, if I had to include the whole boost library for a single function, I would try to directly copy it from the library :-)
I'll add that the question is marked as "language-agnostic", so we can't simply speak about the difference between C/C++ headers and C/C++ libraries. If we speak of a generic language, the inclusion of an external library COULD have side-effects, even BIG side-effects. For example it could slow down very much the startup of your program even if it isn't used (because it has static initializers that need to be called at startup, or it references flocks of other dll/dynamic libraries that need to be loaded). And it wouldn't be the first time there is an error in the startup of a program caused by the static startup of one of its dependancies :-)
So in the end "it depends". I would say that if only have to copy up to one file (let's say 250-500 lines) from a BSD source there isn't any big problem, for anything bigger linking to the library is probably necessary.
#include-ing a header file should have no effect on runtime performance. It may, of course, slow down your compiler.
A decent linker should only pull in the pieces that it actually needs.
When you are talking about performance what do you want to optimize ? Compile time, size of binary/object, speed of execution ?
Using a standard library has the big advantage to improve code Maintainability and Readability. If someone else has to review or modify your code, it is much better to use the "standard" way.
It is much easier to spot a bug when calling memcpy() or strncpy() than when calling MyMemCpy() or MyStringCpy()
I know when you make a typo in your code, it's called a syntax error. but what do you call errors like using an element out of array bounds?
They're called runtime errors.
The other alternative term is, of course, bugs. I would say that runtime errors includes environmental problems such as network failure and disk corruption, whereas bugs are problems in the code itself.
I think the term you're looking for is Logic error.
Unlike a program with a syntax error, a program with a logic error is a valid program in the language, though it does not behave as intended.The only clue to the existence of logic errors is the production of wrong solutions.
Most introductory programming texts I've read divide programming errors into these two broad categories, syntax and logic errors.
Do you use the debugger of the language that you work in to step through code to understand what the code is doing, or do you find it easy to look at code written by someone else to figure out what is going on? I am talking about code written in C#, but it could be any language.
I use the unit tests for this.
Yes, but generally only to investigate bugs that prove resistant to other methods.
I write embedded software, so running a debugger normally involves having to physically plug a debug module into the PCB under test, add/remove links, solder on a debug socket (if not already present), etc - hence why I try to avoid it if possible. Also, some older debugger hardware/software can be a bit flaky.
I will for particularly complex sections of code, but I hope that generally my fellow developers would have written code that is clear enough to follow without it.
Depending on who wrote the code, even a debugger doesn't help to understand how it works: I have a co-worker who prides himself on being able to get as much as possible done in every single line of code. This can lead to code that is often hard to read, let alone understand what it does in the long run.
Personally I always hope to find code as readable as the code I try to write.
I will mostly use debugger to setup breakpoints on exceptions.
That way I can execute any test or unit test I wrote, and still be able to be right where the code fails if any exception should occur.
I won't say I used all the time, but I do use it fairly often. The domain I work in is automation and controls. You often need the debugger to see the various internal states of the system. It is usually difficult to impossible to determine these simply from looking at code.
Yes, but only as a last resort when there's no unit test coverage and the code is particularly hard to follow. Using the debugger to step through code is a time consuming process and one I don't find too fun. I tend to find myself using this technique a lot when trying to follow VBA code.