Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
The community reviewed whether to reopen this question 10 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I am curious if anyone have used UnderC, Cint, Cling, Ch, or any other C++ interpreter and could share their experience.
There is cling Cern's project of C++ interpreter based on clang - it's new approach based on 20 years of experience in ROOT cint and it's quite stable and recommended by Cern guys.
Here is nice Google Talk: Introducing cling, a C++ Interpreter Based on clang/LLVM.
NOTE: what follows is rather CINT specific, but given that its probably the most widely used C++ interpreter it may be valid for them all.
As a graduate student in particle physics who's used CINT extensively, I should warn you away. While it does "work", it is in the process of being phased out, and those who spend more than a year in particle physics typically learn to avoid it for a few reasons:
Because of its roots as a C interpretor, it fails to interpret some of the most critical components of C++. Templates, for example, don't always work, so you'll be discouraged from using things which make C++ so flexible and usable.
It is slower (by at least a factor of 5) than minimally optimized C++.
Debugging messages are much more cryptic than those produced by g++.
Scoping is inconsistent with compiled C++: it's quite common to see code of the form
if (energy > 30) {
float correction = 2.4;
}
else {
float correction = 6.3;
}
somevalue += correction;
whereas any working C++ compiler would complain that correcton has gone out of scope, CINT allows this. The result is that CINT code isn't really C++, just something that looks like it.
In short, CINT has none of the advantages of C++, and all the disadvantages plus some.
The fact that CINT is still used at all is likely more of a historical accident owing to its inclusion in the ROOT framework. Back when it was written (20 years ago), there was a real need for an interpreted language for interactive plotting / fitting. Now there are many packages which fill that role, many which have hundreds of active developers.
None of these are written in C++. Why? Quite simply, C++ is not meant to be interpreted. Static typing, for example, buys you great gains in optimization during compilation, but mostly serves to clutter and over-constrain your code if the computer is only allowed to see it at runtime. If you have the luxury of being able to use an interpreted language, learn Python or Ruby, the time it takes you to learn will be less than that you loose stumbling over CINT, even if you already know C++.
In my experience, the older researchers who work with ROOT (the package you must install to run CINT) end up compiling the ROOT libraries into normal C++ executables to avoid CINT. Those in the younger generation either follow this lead or use Python for scripting.
Incidentally, ROOT (and thus CINT) takes roughly half an hour to compile on a fairly modern computer, and will occasionally fail with newer versions of gcc. It's a package that served an important purpose many years ago, but now it's clearly showing it's age. Looking into the source code, you'll find hundreds of deprecated c-style casts, huge holes in type-safety, and heavy use of global variables.
If you're going to write C++, write C++ as it's meant to be written. If you absolutely must have a C++ interpretor, CINT is probably a good bet.
cint is the command processor for the particle physics analysis package ROOT. I use it regularly, and it works very well for me.
It is fairly complete and gets on well with compiled code (you can load compiled modules for use in the interpreter...)
late edit:: Copied from a later duplicate because the poster on that questions didn't seem to want to post here: igcc. Never tried it personally, but the web page looks promising.
I have (about a year ago) played around with Ch and found it to be pretty good.
Also long ago I used a product call Instant C but I don't know that it ever developed further
Long ago, I used a C++ interpreter called CodeCenter. It was pretty nice, although it couldn't handle things like bitfields or fancy pointer mangling. The two cool things about it were that you could watch when variables changed, and that you could evaluate C/C++ code on the fly while debugging. These days, I think a debugger like GDB is basically just as good.
I looked at using ch a while back to see if I could use it for black box testing DLLs for which I am responsible. Unfortunately, I couldn't quite figure out how to get it to load and execute functions from DLLs. Then again, I wasn't that motivated and there may well be a way.
There is a program called c-repl which works by repeatedly compiling your code into shared libraries using GCC, then loading the resulting objects. It seems to be evolving rapidly, considering the version in Ubuntu's repository is written in Ruby (not counting GCC of course), while the latest git is in Haskell. :)
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 8 years ago.
Improve this question
As try to learn C/C++, I'm always finding it frustrating that I need to use the header files. It makes it seem like it's not my code, but I am using some other person's code instead. I simply want it to be pure, and be written by myself without using the header files.
I know for certain that C/C++ includes libraries that can give the developer some functions in order to for example create a vector. The Boost library are similar to that, but again, I want to write my own code, and maybe create my own library for my work.
But is this possible? If I wrote my own header files for C/C++ that almost acted like the iostream.h file for example, only that I've made it my own, and optimized it, will it be beneficial for my applications/projects, or should I just use the standard library that is included with the programming languages?
My answer comes, at least partially, in the form of a rhetorical question:
Are you also going to write your own compiler?
You're always using something that someone else wrote, and for general-purpose use this is a very, very good thing. Why? Because they are the experts in their field, because they are multiple people, and because their code has gone through decades of rigorous peer review, thorough testing by millions upon millions of people, and many iterations of improved versions.
Shying away from that as an instinct is one thing, but refusing to use standard headers due to it is quite another, especially when you draw the line so arbitrarily†.
In short, there is a damned good reason why the C++ standard defines the standard library and why your compiler vendor ships an implementation of it. My strong recommendation is that you work to that principle.
† …which is why mine is not a "slippery slope" argument!
Off course you should use the standard library. The only reasons not do so are:
The class you want does not exist.
You are a pro C++ programmer and something about its implementation really annoys you.
You as a beginner want to learn something by trying to build your own simple data storage types (like for instance any vector type )
Your thoughts about "all should be made by yourself" are not that uncommon, but once you've implemented one of the standard types and have spent hours on it while your actual project hasn't progressed one line and when your new "own" type still misses half of the functionality - Then you'll realize that using an existing library (especially the standard library or well known others like boost) might actually be a clever thing.
It makes it seem like it's not my code, but I am using some other person's code instead.
How would you write the <fstream> library? Opening files is not something that can be done in the pure C++ language. A library that provides that capability is needed. At base, opening files has to be done by the operating system and the OS exposes that to your code. The OS itself has to deal with other software that enables it to do these things.
Or what about this: Addition doesn't happen by magic, so somebody had to spell out exactly how to do it for your program to be able to do a + b. Does writing a + b make you feel like you're using other people's code, the code which describes how the add instruction is implemented on the CPU?
No single piece of software is going to do everything. Every piece of software will have to interact with other components, and virtually always some of those other components will be the results of someone else's work. You should just get used to the idea that your software has its own area of responsibility and it will rely on others to handle other things.
Re-inventing the wheel is a bad idea. Especially if that wheel has been designed and built by people smarter and more knowledgeable by than you and is known to everyone else who is trying to build cars (program C++).
Use the headers; don't be daft.
By the time one re-implements most standard routines, one might as well make a new language. That why we has a wide selection of languages from which to choose. Folks have dreamed-up a better idea. Re-inventing the wheel is good - we don't drive on chariot tires much these days.
C and C++ may not be the greatest, but with 40 years of history, they do have holding power (and lots of baggage). So if you are going to program in a language - use its resources, with its strengths and weaknesses. Chances are far greater, your solution, will not be better than the existing libraries improved 1,000s of others.
But who knows - you code may be better.
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 7 years ago.
Improve this question
So about 2 weeks ago, I started learning C++ and Lua, and I would like to be able to:
compile C++ code (it would be a nice bonus if i could have a C compiler as well, as that's next on my list of languages to learn)
interpret (is that correct terminology?) Lua, and
do all of this from my usb drive WITHOUT downloading anything from the internet or changing the path variable. (I will mostly be working on school computers.)
As a side note, I have fallen in love with Sublime Text 2 (the portable version of which is already on my usb drive). If it's ABSOLUTELY necessary, I'll make do without it, but I would prefer being able to use it wherever I go.
Please be patient with me, as i have mentioned before, I just started learning how to program, and I have little to no knowledge on how things work. I have seen similar questions, but they never seem to help me much due to my limited knowledge, so PLEASE don't mercilessly close my question like others I have seen on this site.
Thank you in advance!
I recently added a page on Lua WIKI (great source of info) that may help you. It is a tutorial for complete newbies on how to build Lua from the sources using only free and "portable" (in the sense of "can be put on usb drives") tools. It is meant for Windows OS users. Do not forget to check the official getting started page and the main Lua site as well!
The fact that you cannot download anything is quite restrictive (how could you get a free compiler then?). Anyway as greatwolf mentioned TDM-GCC is a great C/C++ compiler for 32 bit x86 PCs. It is also patched to be perfectly "portable": I usually use it from a portable USB HD. The tutorial I mentioned shows you how to download it and "install it".
Note that although your sysadmin at school may have blocked your ability to change the path variable globally, you can set it for individual processes ("launched programs") using simple batch files (aka Windows command shell scripts).
Create a file named "myshell.cmd" with this content:
#set path=%path%;c:\the\path\to\my\app&cmd /K
the part c:\the\path\to\my\app must be the actual path of the directory (folder) where the application executable is placed. When you double-click on myshell.cmd a black box will open (assuming your sysadmin hasn't blocked this feature) where you can invoke the app executables.
For example, if you "installed" the TDM_GCC compiler in c:\myprogs\GCC inside that dir you will find a subdir named bin. That subdir must be put in the path, so your myshell.cmd file will be like this:
#set path=%path%;c:\myprogs\GCC\bin&cmd /K
Then in the "black box" I mentioned you can invoke the compiler typing:
gcc --help
As for your learning path, if you intend to learn both Lua and C or C++, I will advice you to try C instead of C++. C++ has more "high-level" features, but it is huge and although Lua can be used embedded in C++ code (of course this is an advanced topic anyway), it is designed to be directly embedded in a C application (it has an API which conforms to C conventions), so for a beginner probably the path Lua --> C --> C+Lua would be a bit easier. C in itself, although difficult to master, is a rather minimalistic language, so the information to digest about it is not that big.
Not to discourage you, but IMO both C and C++ are not the most suitable languages for absolute beginners (they are plenty of pitfalls and have almost no "safety nets" for beginners). But that's up to you, it heavily depends on your skills, dedication and motivation ;-)
Hope all this helps.
For windows,
Take a look at
http://nuwen.net/mingw.html
You should be able to extract the download to a usb directory. Then you can click on the .bat file open a command prompt with the correct path settings.
As a bonus, it already includes prebuilt boost, which will make your c++ use easier.
For the C/C++ piece would also recommend you start with C. Not for ideological reasons, just that it's a lot simpler if you're trying to work out the basics of compiling/linking etc.
As a first C compiler I would recommend the tiny C compiler
Tiny C Compiler
It's one of the simplest to get your head around that I've seen and you can still build lua libraries etc.
Once you're comfortable with that then progressing to one of the more powerful environments such as gcc under MingW or Visual C++ should be a bit less daunting.
Lua is trivial. Download the binaries, put them on your drive, and configure Sublime Text to invoke them on Lua files.
C/C++ is more complicated only because of the range of options is so vast. I use a 2003 version of Microsoft Visual C++, which covers my needs. I find a copy here.
Keep in mind that C++ is a vastly more complicated superset (non-strict) of C, so you're going to learn most of C in the process of learning C++. IMO, learning C first is better for a whole host of reasons. You'll hear some people argue the opposite, but in this case there's a clincher: Lua is written in C and its API is designed for C. Exposing idiomatic C++ (i.e. objects) to Lua is a big ball of complexity that you just don't need right now, while learning two languages.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I'm doing a Windows Application the uses lots of charts. Its practically a dataviewer. I started doing Matlab, because its easier, but I realized it's too slow. I wanted to change to another language. Somebody recommended me Visual C++ or Java. But Im not sure. What language should I use??
In my opinion the speed gain from going to another "faster" language is not as much as refining your algorithm.
The "problem" with MATLAB is that it allows you to do some nasty things, such as resizing your matrix in a tight loop. You should really try to pinpoint your bottlenecks using the following command:
profile on
... run your program
profile off
profile report
This will give you nice information about which function takes how long to execute and which line creates the biggest bottleneck. You can also see how many times a function is called and a M-Lint Code Check Report is included.
These measurements and hints can show you the bottlenecks of your algorithm. if your sure there isn't a way to reduce the callcount/speed of a function using a smarter algorithm. Such as do I really need that big 2d matrix where a smart vector would be large enough, or if I found a artifact, why would I still continue searching for artifacts. You could write the functions you're experiencing the most performance problems with in c/c++ and use it as a function in matlab. You can get a big speedup out of correctly choosing which functions to implement in c/c++. There is an amount of overhead with calling a c/c++ function from MATLAB, or more correctly there is a overhead in c/c++ to get the data from MATLAB, so a function which is called 10000 times will not be the best to implement in c/c++, you'd be better of with the function higher up the callstack.
It depends on what your requirements are.
The advantage of using matlab is that it's strong in numerical calculations. If you don't need that, then there is no advantage to using matlab. In this case, all those languages are okay, and many others (Python, C#, ...) as well. It depends on which language you are most comfortable with.
If you do want the advantages of matlab then:
Try optimizing in matlab. Most optimization techniques are language independent.
There are tools to translate matlab to C automatically. You can then try to compile with all optimizations on. I seriously doubt this will help much, however, especially considering the GUI part.
First and foremost, as other answers have mentioned, you need to profile your code to find out where the bottleneck is. I would check out Doug Hull's blog at The MathWorks, specifically this entry about using the profiler. This will help you find out where all the work is being done in your code.
If the source of the slowdown is associated with data processing, there may be a number of ways to speed things up (vectorizing, writing a mex file, etc.).
If the source of the slowdown is your GUI, this may be even easier to solve. There are a number of blog posts, both from Doug and other MathWorkers, which I've seen that deal with GUI design. There have also been a few questions on SO dealing with it (here's one). If you're dealing with displaying very large data sets, this submission from Jiro Doke on The MathWorks File Exchange may help speed things up.
It's hard to give you more specific advice since I don't know how you are designing your GUI, but if that turns out to be the bottleneck in displaying your data there are many resources to turn to for improving its speed before you go through the hassle of switching to a whole other language.
Don't forget that you can create functions in C++ that can be called from Matlab. And TADA, you have access to both environments !
I would use C#. It is easier than C++ and integrates well with the Windows platform. Just find a free graphing library for it and you're good to go.
There are plenty of other options depending on your preference of language. Eg. Qt with Python or C++.
As far as I know, the most common methodology is to first do the proof of concept or just the main algorithm on Matlab, because of its ease of use and convenience for math calculations, and after that to translate it to a "real" programming language in order to improve the performance. Usually C or C++ act as the "real" language, but in your case, aiming to do a Windows application, perhaps C# will be the best option.
I found that GUI programming in MATLAB can get really nasty if your application gets more complex. BTW MATLAB can also be called from Java easily (and vice versa, current versions basically provide an interactive Java console).
Just as a side note, if you still need the math power of Matlab, you may want to check out Scilab. It's open-source and free, and it has examples of how it can be integrated with other C# or C++. I have created projects on which Scilab was running in the background to perform all the data math operations; and displaying them with C#'s ZedGraph library. Worked like magic!
I suggest you using Java and the JFreeChart (http://www.jfree.org/jfreechart/) library. I found very easy (and fast) developing applications with a lot of charts of different typologies. If you don't need particularly fast performances, you can use Java. I suppose that there are similar libraries for C#, but I'm not sure.
An alternative to Matlab and Scilab is another free software: Octave.
I don't know about Scilab, but Octave syntax is nearly the same as matlab so you can import code with minimal effort.
If you need fancy toolboxes though, Scilab and Octave might let you down, so check this.
You can execute Octave functions in a C++ program:
http://en.wikipedia.org/wiki/GNU_Octave
I do not think that you can call your own m-files functions from your C++ program though. In the past, the Matlab compiler would let users run matlab programs without installing Matlab, but not without installing a huge library (250 MB if I remember correctly). Nevermind if your Matlab program took 20 kB, you had to distribute the huge library.
Please someone edit/comment on the situation today!
It has been a while since I used the GUI "ability" of Matlab, but back then (2005) I found it awful. Ugly, hard to use, very hard to maintain, dependent on user settings of windows parameters.
Please comment or edit on that too, they may have made progress!
If they have not, I believe that Matlab is NOT the way to go for a program that you want to deliver to anyone.
If you can use Visual Studio for doing your GUI, do that. I second the earlier opinions: go with what you're comfortable with.
If you need the Matlab functions, go with what you're comfortable with, that supports Matlab libraries.
First of all Visual C++ is not a language is an IDE for developing applications.
Second... Which languages do you know? You can have several options. Take a look to:
C++ + Qt (Mine preferred option, powerful and easy to understand)
C# + .NET or WPF
Java
If you can tell more information we could find a language that matches your needs.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I'm having a debate with a friend and we're wondering why so many open source projects have decided to go with C instead of C++. Projects such as Apache, GTK, Gnome and more opted for C, but why not C++ since it's almost the same?
We're precisely looking for the reasons that would have led those projects (not only those I've listed but all C projects) to go with C instead of C++. Topics can be performance, ease of programming, debugging, testing, conception, etc.
C is very portable, much more than C++ was 10 years ago.
Also, C is very entrenched in the Unix tradition. Read more in 'The Art of Unix Programming', about Unix and OO in general, and about specific languages on unix (including C and C++).
There are numerous counter examples: everything based on Qt for one.
Also, on my Debian testing system:
edd#ron:~$ apt-cache rdepends libstdc++6|wc -l
4101
So that's 4101 packages depending on the basic C++ library. For comparison, I get about 14,982 for libc6 or roughly 3.6 as many. But it is not if there aren't any C++ projects in Open Source land.
Edit: Thinko on my part: as the C++ packages also depend on libc6, the ratio really is
(14982 - 4101)/4101 = 2.65
so there are roughly 2 1/2 times as many packages implemented in C than there are in C++.
Eric Raymond's wonderful book "The Art of Unix Programming" has some reflections on this issue (the whole book is well worth reading in either the paper or free online editions, I'm just pointing to the relevant section -- Eric was involved with the coining and introduction of the term "open source", and is always well worth reading;-0).
Summarizing that section, Raymond claims that "OO languages show some tendency to suck programmers into the trap of excessive layering" and Unix programmers (and by extension open-source programmers) resist that trap of "thick glue".
Later in the book, you find some considerations specifically about C++, such as "It may be that C++'s realization of OO is particularly problem-prone". Whether you agree or not, the whole text is well worth reading (I can hardly do it justice here!-), and rich with bibliography pointing you to many other relevant studies and publications.
Linus Torvalds has ranted several times on the topic of C++ -- he uses C for git, and of course the Linux kernel is mostly C:
on C++ and git (warning: don flame-retardant first)
an interview with Linus from 1998
You can easily find more of these, and while it's in his nature to get a bit flamey about these things, there are some valid points.
One of the more interesting (from where I'm sitting, anyway) is the observation that C++ compilers and libraries were (and to some degree are) a lot more buggy than the corresponding C compilers. This stands to reason given the relative complexities of the two languages.
It smells a little of "not invented here" (NIH) syndrome, but when you have the entire Linux kernel developer base, you can sometimes afford to reinvent things "The Right Way".
A lot of the projects started before C++ was standardized, so C was the obvious choice and a change later would be hard. C was standardized about a decade before C++, and has been more nearly portable for even longer. So, it was largely a pragmatic decision at the time, inspired in part by the Unix heritage of using C for most code.
C++ is a mess. It is overly complicated language, so complicated that only few people can say that they know all the bits. And fewer compilers which really complies to C++ standard.
So I think the reason is simplicity and portability.
If you want higher-level and object-oriented programming, then I think C++ is just competed with others like Python. (Note that I programmed in C++ few years, it's fast and has some features from higher-level languages that speeds up development, no offence.)
I have worked on a few C++ projects in my time, all of which have ended in tears one way or the other. At the most fundamental level, the truth is that people can't be trusted. They can't be trusted to write good code, they can't be trusted to debug it, and they certainly can't be trusted to understand it when they have to come back and modify it again weeks/months later.
C code doesn't have a lot of the weird stuff in C++ that makes it hard to debug (constructors/destructors, anything that happens with static global objects during cpp_initialize() time, etc.). That just makes it easier to deal with when developing and maintaining a big project.
Maybe I'm a luddite, but every time someone says "C++" around me I get shivers.
Some people have mentioned portability, but in this day, the portability of C++ isn't much of an issue (it runs on anything GCC runs on, which is essentially anything). However, portability is more than just architecture-to-architecture or OS-to-OS. In the case of C++, it includes compiler-to-compiler.
Let's discuss ABI, or Application Binary Interface. This basically means "how your code translates into assembly." In C, when you write:
int dostuff(const char *src, char *dest);
You know that you're making a symbol in your object file called _dostuff (C global names are all prefixed by an underscore in the resultant assembly). But in C++, when you write this:
int dostuff(const char *src, char *dest);
int dostuff(const char *src, char *dest, size_t len);
Or even:
int dostuff(std::string src, std::string dest);
All bets are instantly off. You now have two distinct functions, and the compiler has to make each, and has to give each a unique name. So C++ allows (where I believe C doesn't) name mangling, which means those two functions might get translated to _dostuff_cp_cp and _dostuff_cp_cp_s (so that each version of the function that takes a different number of arguments has a different name).
The problem with this is (and I consider this a huge mistake, even though it's not the only problem with cross-compiler portability in C++) that the C++ standard left the details of how to mangle these names up to the compiler. So while one C++ compiler may do that, another may do _cp_cp_s_dostuff, and yet another may do _dostuff_my_compiler_is_teh_coolest_char_ptr_char_ptr_size_t. The problem is exacerbated (always find a way to sneak this word into anything you say or write) by the fact that you have to mangle names for more than just overloaded functions - what about methods and namespaces and method overloading and operator overloading and... (the list goes on). There is only one standard way to ensure that your function's name is actually what you expect it to be in C++:
extern "C" int dostuff(const char *src, char *dest);
Many applications need to have (or at least find it very useful to have) a standard ABI provided by C. Apache, for example, couldn't be nearly as cross-platform and easily extensible if it was in C++ - you'd have to account for the name mangling of a particular compiler (and a particular compiler version - GCC has changed a few times in its history) or require that everyone use the same compiler universally - which means that, every time you upgrade your C++ compiler with a backwards incompatible name-mangling scheme, you have to recompile all your C++ programs.
This post turned into something of a monster, but I think it illustrates a good point, and I'm too tired to try to trim it down.
As someone who dislikes C++ and would pick C over it any day, I can at least give you my impressions on the topic. C++ has several attributes that make it unappealing:
Complicated objects. C++ has tons of ability to speed up OO, which makes the language very complex.
Nonstandard syntax. Even today most C++ compilers support quirks that make ensuring successful and correct compilation between compilers difficult.
Nonstandard libraries. Compared to C libraries, C++ libraries are not nearly as standardized across systems. Having had to deal with Make issues associated with this before I can tell you that going with C is a big time saver.
That said, C++ does have the benefits of supporting objects. But when it comes down to it, even for large projects, modularity can be accomplished without objects. When you add in the fact that essentially every programmer who might contribute code to any project can program C, it seems hard to make the choice to go with anything else if you need to write your code that close to the metal.
All that said, many projects jump over C++ and go to languages like Python, Java, or Ruby because they provide more abstraction and faster development. When you add in their ability to support compiling out to/loading in from C code for parts that need the performance kick, C++ loses what edge it could have had.
If you look at recent open source projects, you'll see many of them use C++. KDE, for instance, has all of its subprojects in C++. But for projects that started a decade ago, it was a risky decision. C was way more standardized at the time, both formally and in practice (compiler implementations). Also C++ depends on a bigger runtime and lacked good libraries at that time. You know that personal preference plays a big role in such decision, and at that time the C workforce in UNIX/Linux projects was far bigger than C++, so the probability that the initial developer(s) for a new project were more comfortable with C was greater. Also, any project that needs to expose an API would do that in C (to avoid ABI problems), so that would be another argument to favor C.
And finally, before smart pointers became popular, it was much more dangerous to program in C++. You'd need more skilled programmers, and they would need to be overly cautions. Although C has the same problems, its simpler data structures are easier to debug using bounds checking tools/libraries.
Also consider that C++ is an option only for high-level code (desktop apps and the like). The kernel, drivers, etc. are not viable candidates for C++ development. C++ has too much "under the hood" behavior (constructor/destructor chains, virtual methods table, etc) and in such projects you need to be sure the resulting machine/assembly code won't have any surprises and doesn't depend on runtime library support to work.
One important aspect in addition to others that will doubtless be mentioned is that C is easier to interface with other languages, so in the case of a library intended to be widely useful, C may be chosen even nowadays for this purpose.
To take examples I am familiar with, the toolkit GTK+ (in C) has robust OCaml bindings, while Qt and Cocoa (respectively in C++ and Objective C) only have proof-of-concepts for such bindings. I believe that the difficulty to interface languages other than C with OCaml is part of the reason.
One reason might be that the GNU coding standards specifically ask you to use C. Another reason I can think of is that the free software tools work better with C than C++. For example, GNU indent doesn't do C++ as well as it does C, or etags doesn't parse C++ as well as it parses C.
I can list a couple more reasons
C code produces more compact object
code. Try to compile 'Hello World'
as C and C++ program and compare the
size of the executable. May not be too relevant today but definitely was a factor 10+ years ago
It is much easier to use dynamic
linking with C programs. Most of
the C++ libraries still expose entry
points through C interface. So instead of writing a bridge between C++ and C why not to program the whole thing in C?
First of all, some of the biggest open source projects are written in C++: Open Office, Firefox, Chrome, MySQL,...
Having said that, there are also many big projects written in C. Reasons vary: they may have been started when C++ was not standardized yet, or the authors are/were more comfortable with C, or they hoped that the easier learning curve for C would attract more contributors.
If correctly implemented C is very fast and very portable and the compilers are there
C++ is different for each compiler available, the libraries dont agree, the standards don´t match.
You can read Dov Bulka to find what not to do in cpp, you can read tesseract ocr at Google code, you can read lots of things - most of which depend on where you are to determine which code linguistic is superior. Where did you read that c has more source code up in open source than cpp? Well of course you read that in a c forum. That's where. Go to some other programming linguistic. Do the same search, you will find that that code has more open source.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
Does anybody know a fully featured refactoring tool for C++ that works reliably with large code bases (some 100.000 lines)?
I tried whatever i can find again and again over the last years: SlickEdit, Eclipse CDT. They all were not at all usable.
SUMMARY:
I took time and evaluated "Visual Assist X" as well as "Refactor for C++". Both have some impressing features, but both as well are far from perfect. Extracting a large block of code usually is not done satisfying without manual modifications - and therefore does not pay off.
"Visual Assist X" has nice features such as much more complete autocompletition etc. But it leads to so much flickering and slows down much at certain points.
By my opinion therefore the answer is: "No, there is no production ready refactoring tool for C++"
UPDATE March 2015
As for hdoghmens reply today i tried Resharper for C++.
His link
https://www.jetbrains.com/resharper/ does not say anything about C++. But i found Resharper C++ that was announced more than a year ago here:
https://www.jetbrains.com/resharper/features/cpp.html
I gave it a try with VC2010 using a code base of 20MB.
Test 1: Extract Method:
results in a Resharper exception. No source code changed.
Test 2: Extract Method with different source:
Works fine
Test 3: Change signature of extracted function: Results in broken C++ code:
bool myclass::do_work123(<unknown long Color>int& Filled*&, long, int&)
Maybe thats why C++ its not listed on the main page.
By my opinion the answer to this question still is "NO".
Visual Assist and Visual Studio make dealing with large codebases much easier. Visual assist is good at tracking down how a class or member is used and is more effective at renaming it without false positives than search and replace.
I find Visual Assist X with Visual Studio very useful. Another choice is Refactor for C++.
I expect clang will significantly change the landscape of C++ refactoring tools out there over the next couple of years. It's an open-source, modular compiler that exposes an API for parsing and semantically analyzing C++ code. IDEs and other tools will be able to use this API rather than doing the difficult work of writing their own parser and semantic analyzer.
Google already made a large-scale refactoring tool using clang.
Mozilla has their own refactoring tool named Pork (Wiki, Developer Wiki). Here is the blog of the developer behind Pork. From what I've read Pork was successfully used in refactorings at Mozilla.
Pork should help if you come from *nix land, for Visual Studio I too recommend Visual Assist.
Our DMS Software Reengineering Toolkit is a transformation engine designed to carry out complex transforms over large bodies of code, including C++. It has been used to make reliable changes on systems of millions of lines of code. It operates by using compiler-accurate langauges analyzers and transformers.
It has a full C++ parser with name and type resolution, builds ASTs of code, can apply procedural or source-to-source transformations (with C++ surface syntax) to revise those trees, and regenerate compilable output with comments preserved. (Edit: 7/1/2011: Now does C++1X to the extent we understand the standard :)
It has been used on large scale reengineering projects, including C++ component re-architecting, and 100% fully automated translations between langauges.
You can read about this at the website.
DMS is also used to build arbitrary source analysis tools. Examples include clone detection, test coverage, smart difference (comparision of source code structures and abstract editing operations rather than lines with simple insert and delete), etc.
What it is not (presently) is an interactive refactoring tool. We believe that to do most refactorings well, you need deep control and data fow analyses. DMS has generic machinery to support this, and that machinery is implemented for C, COBOL and Java at this point, with C++ being next in line. This is a tough job. You won't see a lot of serious C++ refactoring tools from anybody until this kind of problem has been solved well.
First you need a full C++ parser :-}
EDIT 7/5/2011: Looks like we are going to take a run at the interactive version. We have won a Department of Energy Phase I SBIR to investigate how to do this. See http://science.energy.gov/sbir/awards-and-general-stats/fy-2011/phase-i-by-state/?p=1#tx (Look for Semantic Designs under "Texas").
Don't expect a result in a hurry; this is just the start of 3 phase multi-year program to get to a tool.
EDIT 8/11/2011: First progress... we now handle all of C++0x and OpenMP directives.
EDIT 1/4/2012: Does full control flow analysis of C++ code.
EDIT 9/15/2014: Now have C++14 front end parser/transformation engine well in hand. Even does rename pretty reliably at this point :-}
If you're using emacs, try Xrefactory . It supports method extraction, renaming of classes/functions/variables and insert/delete/move parameters.It also has very good/fast code completion engine.
Currently I can't recommend any refactoring tool for C++, certainly not for large code bases of 100k lines and above. I've been hoping this will change, like the OP, and I hope one day there will be something. I fear that the language itself might have to change significantly before we see any really good tools.
btw, has SlickEdit dropped its refactoring features?
I recommend to try rtags if you use emacs and haven't tried it yet (there is also a package for vim available). It is a clang based client/server application that indexes C/C++ code, with these features included:
go to definition/declaration
find all references, go to next/previous
rename symbol
integration with clang’s “fixits”
I decided to give it a try after watching this talk which introduced rtags (and emacs) for me.
(I have to say that I went this far only after my QtCreator failed to rename some symbols properly, which is a show-stopper for my using this great IDE for now)
Besides what is supported by rtags, I also need some additional neat features, including:
create function definition/prototype
extract function
create getter/setter methods
For these, I recommend to use a semantic-refactor package for emacs (not sure if there are alternatives for vim)
Generally, clang based tools looks very promising. If you are interested in more information about clang tools for C++ refactoring, including for projects with large codebase, there are some great talks by Chandler Carruth.
The DMS software rengineering toolkit does this I think. It is a code transformation engine, designed for large scale and handles C++. Have no idea how elegant the output is though.
The problem are C++ templates. As of 2019 I'm not aware of any refactoring tool that supports C++ templates. I've tried VS2019, VisualAssist, Clion, QtCreator.
Consider example:
#include <iostream>
struct foo { void print() {} };
struct bar { void print() {} };
template <typename T>
void call_print(T&& v) { v.print(); }
void print() {}
int main()
{
call_print(foo{});
call_print(bar{});
return 0;
}
If I run Rename Refactoring on foo::print, bar::print should be also renamed automatically. Because they are linked through call_print function template instantiations.
One surely has to mention Klocwork as a commercial code refactoring suite. It does look very promising when you go through the demo video.
Definetely Resharper Ultimate is the way to go. Happiness guaranteed :)
In Beta version as of march 2015.
Sorry to only find this question so late. My students and assistants work on C++ refactoring since about 2006. Most of CDTs refactoring infrastrucure was built by my team at IFS institute of software. since a couple of years we provide Cevelop our version of CDT with support for C++ code modernization refactorings etc. Cevelop can work with large code bases, if workspace is set up correctly. Free available at https://cevelop.com
If you are using Visual C++ (Express Edition is free), you can use Visual Assist from www.wholetomato.com (link to the C++ refactoring features).
It has a 30 day trial period and we have found it to be faster and more feature-full that the built-in intellisense in the Visual C++ product itself.
If your looking to reengineer your codebase: MOOSE. But that's a large collection of analysis and reengineering tools, not an editor.
There is now a C++ refactoring extension for Visual Studio 2013 from Microsoft:
http://visualstudiogallery.msdn.microsoft.com/164904b2-3b47-417f-9b6b-fdd35757d194
CLion looks very promising.
Disclaimer: I've not tried it yet as I need to convert my projects to CMake format in order to use it.
I recommend you try Lattix. It allows you to analyze large C/C++ codebases to discover the archtecture, identify problematic dependencies, and re-engineer the code to improve modularity and reduce technical debt. Lattix also provides a number of algorithms to help in the refactoring process. These algorithms help you figure out how to move elements from one part of the hierarchy to another, to break cycles and to move subsystems so that the coupling and cohesion of subsystems can be improved. Here are the results of Lattix analyzing the Android Kernel (1.6 million LOC of C/C++).
Full disclosure: I work for Lattix
I found the following plugin for Visual Studio 2013:
Visual C++ Refactoring by Microsoft.
It is just a simple rename tool but it works flawlessy. It adds the following context menu after right-clicking on a symbol: