Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I wonder whether LLVM by virtue of its newer design is to replace GCC in the open-source world?
LLVM should feature several techniques of inspecting code, so that IDE's are easier to program etc. However, GCC should still be good in terms of performance.
Short answer: No. They're both widely used depending on the context.
Long answer:
Depends, it's a matter of adoption as well as other factors.
For example, Apple uses LLVM (and Clang) for pretty much everything including building the kernel (previously built using GCC), bootloader and the userspace. As well as that, LLVM is used in the graphics drivers for compiling shaders to SGX USSE bytestreams, though here it's largely a case of eating your own dogfood.
As well as that, LLVM is also used in open source projects, for example in Mesa and in the Dolphin Emulator for JIT compilation.
Aside from that, GCC still has predominant usage, for example, Linux is built using GCC and while there have been attempts to build Linux using Clang+LLVM, they were more of an experiement than anything. As well as that, in the embedded world, a lot of embedded applications (for example, UBoot and Little Kernel) rely on features provided by GCC extensions and outright won't build with Clang+LLVM failing either at compilation to objects or linking stages.
For userspace applications however, it's largely a matter of personal (or your company's preference) since both of them offer roughly the same feature set including stuff like SIMD support and full support for C++14 and C11 (though GCC has some annoying unresolved bugs when it comes to C++ support, for example, Bug 61636).
The code inspection techniques are largely provided by Clang and in my personal experience provided a substantial amount of overhead (for example in Qt Creator and less so in XCode).
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Let's say I want to create a modern c++ application. I have zero legacy code that requires backward compatibility with c++98/03. Is there a reason to choose c++11 or c++14 over c++17?
From researching this, there don't appear to be any breaking changes between c++11 and c++17. It looks like c++17 is c++11 with more and more features. I realize that there are more compilers that support c++11 features than all the new c++17 changes.
So Compiler support is a consideration because it can affect portability. Also c++17 is not officially released, but at some point it will be.
What are the criteria I should evaluate in order to choose between C++11 and C++17? I'm looking for non-opinion based reasons.
Thanks!
I feel like this is going to get closed as vague, opinion based, but what the heck. Keep in mind that 14 is between 11 and 17 as well, and much more widely supported. There's basically no reason to use 11 over 14 for a new codebase now, that I can think of. For 17, the problem is like you said, compiler support. If you need to target windows, MSVC is still missing tons of 17 support: http://en.cppreference.com/w/cpp/compiler_support#C.2B.2B17_features.
In order to write cross platform, 17 code right now, you almost certainly need some heavy duty continuous integration that will build and run your code on at least 2 if not 3 compilers every time you push.
If you are not targeting windows, or even if you can just commit to a single compiler, I don't see any reason not to use 17. (by that I mean: if you are only targeting MSVC, it's 17 support is partway there but there's little downside to using whats available, if something isn't supported it won't build. It's when you support different compilers that support different things, and you aren't building them all locally that it becomes a nightmare).
In general, that means independently from C++, when they are no restriction due to legacy stuff, it is recommended to use the most recent version of a system or language.
Reasons to go a version step back may be
tool support for this version is unsufficient (this may differ from project to project)
tools are known to be buggy
version spec is not completed
only judge about you really get, not what other promise for the future.
This list may be incomplete
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
What kind of software or programming language that I've to learn for creating single executable program without any .dll or other formats independently?
Any suggestion I would appreciate!
It is operating system specific (and not defined by the language itself). Read more about linkers.
You may want to use C++11 (or C++14) and instruct your C++ compiler to statically link your executable. So you should read the documentation of your compiler; with GCC you could pass -static to the g++ command.
You may also want to use the Go language. The usual compiler for Go is trying to generate statically linked executables.
BTW, a statically linked executable still have dependencies, e.g. to its operating system kernel (and perhaps utilities and some system files) : obviously, a statically linked executable for Windows won't run on Linux.
(for instance, on Linux, any program using the standard system(3) function silently depends upon /bin/sh....)
In practice, I generally would not recommend statically linking the C standard library, but YMMV.
Of course, you need some source code editor to write your code (I prefer GNU emacs). Some people are using IDEs, but I prefer to run explicitly the compilation command (perhaps using some build automation tool like GNU make).
(notice that DevC++ or CodeBlocks is an IDE, not a compiler)
NB: I recommend reading Operating Systems : Three Easy Pieces (freely downloadable, each chapter has its own PDF file) to understand more about operating systems.
A truly independent "executable" is an image that you flash onto an embedded device. Your image may (but doesn't need to) bundle a library such as FreeRTOS that functions as a sort of mini-OS. Other than actual hardware, your program will be entirely self-sufficient.
Otherwise, you are at least beholden to having an operating system in place, with access to the "runtime" support library for your language (although this can often be statically linked) and possibly third party libraries on top of that (which may often be statically linked too).
Sometimes when trying to be self-contained, you go so far in the other direction that actually your "program" is not executable at all, but just a script to be passed through a Python or Go or JavaScript or VBScript interpreter. This is in fact the opposite of self-contained, though it is nice and portable if implementations of that language exist on all your target platforms.
Code that runs on a VM (Java, .NET) is a sort of half-way house between these.
Visual Studio:
Project->'project' Properties
Configuration Properties -> C++ -> Code Generation
Runtime Library -> Multithreaded [debug]
Don't use Multithreaded [debug] DLL
Also, set [debug] for Debug build and NOT [debug] for Release build. You can switch between build types with the 'Configuration' dropdown in the upper left corner.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I´m looking forward to learn an assembly language.
I searched web for the tutorial and found different tutorials with different syntax of assembly.
There is any difference between 8086 assembler, nasm and gcc?
What is the better way to learn code with in assembly language?
thanks.
Basically there are two flavours on the x86 chipset which is AT&T or the Intel snytax. Most people I know prefer the Intel syntax because it is much easier to understand, but of course this is also a matter of getting used to. When I learned assembly on 6510 or M68000 I found the AT&T syntax closer related, it is rather confusing with it's adressing modes IMO.
If you instruct gcc to write the assembly sourcefile it uses AT&T syntax by default, but you can switch that to Intel as well using
gcc -S -masm=intel test.c
nasm is an assembler and gcc is a compiler so they have quite different purposes.
As for learning assembly there are lots of tutorials, for example The Art of Assembly. But if you really want to learn it, IMO the best way is to start debug and enter some instructions and see what they are doing and how they change reigsters and flags, writing small loops first.
This way you can focus on the instructions and not fight with the assembler source syntax as well.
I wouldnt start with x86, not a good first instruction set even if you have the hardware. ARM, msp430, avr, and some others are better and have open source simulators where you can get better visibility. I would start small, simply adding or anding a few numbers, write a memory location, read it back, that kind if thing. The simulators (can) prevent you from needing to make system calls to "see" your results, likewise they can definitely help you work through hangs and crashes, which you will get and which IMO leads to giving up on the whole thing. Once you know more, you can switch to hardware or try another instruction set (each new one gets exponentially easier than the prior) leading to x86 if you by then still feel there is a need...With x86 I recommend going back to the early days, find an 8088/86 simulator, learn the original instruction set, then if you still feel the need, then skip to 80386 and newer. You will also need to be able to switch formats in your head, gnu using AT&T was a cardinal sin (gnu assembler folks commit these sins regularly BTW, it is almost expected), but unfortunately we now have these two competing formats. With practice you should easily be able to tell what format is being used on inspection of code, but mentally switching back and forth may still be a challenge.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Well, I've been asking myself this question for quite a long time by now.
I started using the GNU Fortran compiler (gfortran) and I was quite happy. But then I started hearing that the Intel Fortran compiler (ifort) was better because it was optimized for Intel processors (and therefore optimized for most computers today as a consequence that Intel has the greater share of the market). After that I started using ifort, but the truth is that I'm not completely happy with it because it does not detect some errors that gfortran does (i.e. Question: "Reference passing is changing the values of a matrix").
It is also true that there are other Fortran compilers but, actually, I never use other than gfortran and ifort.
So I would like to ask you: What are the advantages and disadvantages of each one? Which is the best one, if optimization is not important?
In my opinion, it is best to stick to the Standard you're comfortable with, and write code that is conforming to this Standard. Then, the choice of compilers is dictated by the support for said Standard.
Here is an extensive list of the compiler support for the 2003 and 2008 Standards.
I myself used g95 a lot because I liked the debug messages. Nowadays, I commonly use Fortran 2008 features, and use gfortran (because it's open source), and ifort (because it's free for non-commercial use). g95's support for Fortran 2003 and 2008 is quite limited.
I usually compile code with both compilers and all warnings turned on, and quite often I'm surprised what errors are missed by one of the compilers. In terms of performance of the compiled code, I never noticed a difference (excluding bundled math libraries).
Most commercially available compilers have non-standard extensions, like OpenACC (e.g. Cray, PGI) or special features (e.g. PGI CUDA Fortran) and bundled libraries (e.g. Intel MKL). These might also influence your choice. For some hardware you might need / might profit from special compilers (like the Cray compiler).
EDIT: Here are some benchmark results for different compilers and machines.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'd like to learn assembler. However, there are very few resources for doing assembler with OS X.
Is there anyone out there who has programmed in assembly on a Mac? Where did you learn?
And, is there any reason I shouldn't be doing assembly? Do I risk (significantly) crashing my computer irreparably?
If you're using a PowerPC Mac, look into gcc inline assembler. Otherwise, look into nasm. I can't give any decent references to PPC ASM (they're few and far between), but I suggest the following things to learn x86 asm:
The book Reversing by Eldad Eilam
Compile simple C source with gcc -S and read the assembly generated
Use Sandpile
Join #openrce on irc.freenode.net and use OpenRCE
Also, if you're not in kernel mode then there's no chance of screwing anything up, really, and even if you are in kernel mode it's hard to really destroy anything.
Edit: Also, get gcc and such from XCode not Macports or somesuch. You're in for a world of malformed Mach-O files if you don't. Not fun to diagnose file format issues when you're just starting asm hacking.
The assembler language is determined by the hardware platform, not the operating system. Given that OS X runs on Intel platform and is 64-bit, you should look for information on x64 (also called AMD64) assembler. Check the Wikipedia article (http://en.wikipedia.org/wiki/X86-64) for a lot of links to documentation about x64.
Also, the OS X tools documentation might contains a lot of information about x64 assembler. In particular, the Netwide Assembler (NASM - http://developer.apple.com/documentation/DeveloperTools/nasm/nasmdoc0.html) might have documentation on how to build OS X applications using assembler.
To start learning assembly, you might want to start with simple C programs and ask GCC to generate the assembler code for it using the -S option:
gcc -S hello.c -o hello.asm
You will then be able to understand how to call functions, pass arguments, etc.
Nasm/yasm are your best bet; gcc inline syntax is quite crippling and can be very painful to use at times, plus there are literally some things it cannot do. Nasm's macro syntax is also much much more useful, a godsend in a language like assembly that has no built-in templating features.
XCode (ie. GCC) has great support for writing assembler. It's a fun thing to learn (although you're unlikely to need it much), and the worst you can do is crash the program you're writing, same as in C. Just Google for 'gcc inline asm x86 tutorial' and you should find plenty of starting points. Don't worry that some will seem to be Linux specific, they'll generally work just as well in XCode.
(edit) ...assuming you have an Intel Mac of course; if not then replace 'x86' with 'ppc'.
here
I programmed assembly on a Mac. It was Motorola 680x0 assembler using MPW. I've touched on the PowerPC assembler a few times in CodeWarrior and ProjectBuilder. Now ProjectBuilder is called XCode, and there is Intel. The assembler is one of the many tools within XCode.
I originally learned assembler on the Apple II: the 6502 machine language monitor built in ROM, the Sweet16 mini-assembler, and others. Later, I used Intel 80186 assembler to speed up slow bits of C code, and work paid for a one day course on Intel 80186 assembler at a university. Later, I had to maintain some 680x0 assembly for the Mac. That was a long time ago.
I don't think there is any reason not to do assembly. Learning is great. Learn all you can. Drop into a low enough level debugger and look at the disassembled code.
My advice is:
Don't be scared.
There's no reason why you shouldn't; there is nothing you can do in assembly language that you can't do in a higher level language like C.
As far as tools go, you might want to install MacPorts and get the GNU assembler. That may or may not be the easiest way, but it's free and you can probably find tutorial documentation for writing Unix programs in GNU assembler somewhere on the net.
There are two three things you to know need for writing assembly language on a system with an operating system (as opposed to 'bare metal' assembly which is a world of its own):
How the instruction set works - loads of resources for Intel X86 if you have an Intel Mac, still reasonable set for PPC for example Mac OS X Internals.
How to assemble link your programmes - if you have the Developer tools installed you have GCC and associated tools
How to talk to the OS - here is where Mac assembly is a lot less well documented than Windows or Linux. It may be you have to write equivalent C programs and use 'gcc -S' to see what calling/stack restoration conventions are appropriate. It depends what you want to do but at a miniumum you need OS system calls for IO and memory allocation.
A good starting point is here.
If you've got Developer Tools installed, you can simply open Terminal and type as (GNU Assembler - part of Binutils).
For PPC try Lightsoft