Related
I am not sure if the title of this question gets to the point. I have written a large software system in C C++ for Windows, and want to give the users of this system the option to add compiled code to it. The user should be able to do basic stuff, and exchange data with my program.
Currently the implemented way is via DLLs. But for this, a grown up compiler is needed, and it is not as easy as I wished. Is there a tiny C compiler that can create Windows DLLs?
Another idea is the Java native interface. But this requires a complete Java system to run in the background, and it is not easy to run code in it.
Do you have any other ideas?
Any interpreted language? (TCL and Lua were designed as extension languages, but you can nearly as easily interface with any other).
How about python integration?
You could create an python interface that interfaces with your application. Python is rather easy to learn and should integrate easily with c/c++. The python documentation has an own chapter on that.
You could also use a tool like swig to generate the interface.
The advantage of this is that they wouldn't have to compile anything. They could just supply python files that could be loaded into your application and run within the software. This is a well known use for python, and something its simple syntax promotes.
As the other says you will be best of by providing an embedded language.
I would chip in for javascript and use the google v8 engine
By using javascript you get a language nearly everbody can use and program in.
There is other javascript engines you can embed like SpiderMonkey.
See this answer for what to choose.
An interpreted language is not good enough. I need speed. The software itself is an interpreted language. So I added support for the tiny C compiler. It is only C, and I do check mingw, which probably would not be as tiny as this. Thanks for all your hints.
Added after several months:
I have now two tools, actually: TinyC and Python. The speed difference between those is noticable (factor 5-10), but that usually does not matter too much. Python is much easier for the user, though I managed to integrate both into the Euler GUI quite nicely.
One of the ways is to add scripting. You application can host scripting environment and expose its services there. Users would be able to execute JScript/VBScript scripts and interact with your application. The advantage is that with reasonable effort you can get the power of well known and well documented scripting languages into your application (I suppose there is even debugger for scripting there). You will be required to shape your app services as COM interfaces and scripts will be able to access them automatically using method names you assigned on C++ side.
C++, Win32 and Scripting: Quick way to add Scripting support to your applications
MSDN Entry Point - IActiveScript interface
I have read a few articles in the cross-platform tag. However, as I'm starting a fresh application (mostly a terminal/console app), I'm wondering about the easiest way to make it cross-platform (i.e. working for Linux, Mac OS X, and Windows). I have thought about the following:
adding various macro/tags in my code to build different binary executables for each operating system
use Qt platform to develop a cross-functional app (although the GUI and platform component would add more development time as I'm not familiar with Qt)
Your thoughts? Thanks in advance for your contribution!
Edit: Sounds like there are a lot of popular responses on Java and Qt. What are the tradeoffs between these two while we're at it?
Do not go the first way. You'll encounter a lot of problems that are already solved for you by numerous tools.
Qt is an excellent choice if you definitely want C++. In fact, it will speed up development even if you aren't familiar with it, as it has excellent documentation and is easy to use. The good part about it is that it isn't just a GUI framework, but also networking, XML, I/O and lots of other stuff you'll probably need.
If not necessary C++, I'd go with Java. C++ is far too low level language for most applications. Debugging memory management and corrupt stacks can be a nightmare.
To your edited question:
The obvious one: Java has garbage collection, C++ doesn't. It means no memory leaks in Java (unless you count possible bugs in JVM), no need to worry about dangling pointers and such.
Another obvious one: it is extremely easy to use platform-dependent code in C++ using #ifdefs. In Java it is a real pain. There is JNI but it isn't easy to use at all.
Java has very extensive support of exceptions. While C++ has exceptions too, Qt doesn't use them, and some things that generate exceptions in Java will leave you with corrupt memory and crashes in C++ (think buffer overflows).
"Write once, run everywhere." Recompiling C++ program for many platforms can be daunting. Java programs don't need to be recompiled.
It is open to debate, but I think Java has more extensive and well-defined library. The abstraction level is generally higher, the interfaces are cleaner. And it supports more useful things, like XML schemas and such. I can't think of a feature that is present in Qt, but absent in Java. Maybe multimedia or something, I'm not sure.
Both languages are very fast nowadays, so performance is usually not an issue, but Java can be a real memory hog. Not extremely important on modern hardware too, but still.
The least obvious one: C++ can be more portable than Java. One example is FreeBSD OS which had very poor support for Java some time ago (don't know if it is still the case). C++/Qt works perfectly there. If you plan on supporting a wide range of Unix systems, C++ may be a better choice.
Use Java. As much bashing as it gets/used to get, it's the best thing to get stuff working across any platform. Sure, you will still need to handle external OS related functions you may be using, but it's much better than using anything else.
Apart from Java, there are a few things you can run on the JVM - JRuby, Jython, Scala come to mind.
You could also write with the scripting languages directly( Ruby, Python, etc ).
C/C++ is best left for applications that demand complete memory control and high controllability.
I'd go with the QT (or some other framework) option. If you went with the first you'd find it considerably harder. After all, you have to know what to put into the various conditionally compiled sections for all the platforms you're targeting.
I would suggest using a technology designed for cross-platform application development. Here are two technologies I know of that -- as long as you read the documentation and use the features properly -- you can build the application to run on all 3 platforms:
Java
XULRunner (Mozilla's Development Platform)
Of course, there is always the web. I mostly use web applications not just for their portability, but also because they run on my Windows PC, my Ubuntu computer, and my Mac.
We mainly build web applications because the web is the future. Local applications are viewed in my organization as mostly outdated, unless there is of course some feature or technology the web doesn't yet support that holds that application back from being fully web-based.
I would also suggest Github's electron which allows to build cross platform desktop applications using NodeJs and the Google's Chromium. The only drawback for this method is that an electron application run much slower than a native C++ application due to the abstraction layers between Javascript and native C++.
If you're making a console app, you should be able to use the same source for all three platforms if you stick to the functions defined in the POSIX libraries. Setting up your build environment is the most complicated part, especially if you want to be able to build for multiple platforms out of the same source tree.
I'd say if you really want to use C++, QT is the easiest way for cross-platform application, I found myself using QT when I need an UI even though QT has a large set of library which makes pretty much everything easier in C++.
If you don't want to use QT then you need a good design and a lot of abstraction to make cross-platfform application.
However I'm using more and more Python bindinq to QT for medium size application.
If you are working on a console application and you know a bit of python, you might find Python scripting much more comfortable than C++. It keeps the time comsuming stuff away to be able to focus on your application.
I would like to download and try out LLVM, before that I wanted to know:
(a) What are the factors to consider before finalizing a LLVM platform (Windows/Linux)?
(b) What is the best way to learn LLVM? I would like to get involved in one of the projects there. So I want to get overall idea about it. In the process I got overwhelmed by the sheer size of LLVM, its sub-projects, its tools, the support, etc.
FYI: I have gone through the basics of LLVM from the llvm.org
Also have worked on the compiler related development, static code analysis.
Please help.
Thank you.
LLVM doesn't run on just one platform. As a contributor, your patches will be expected to work on many platforms. If you're not setup to test on more than one, then you'll be reliant on the interest of others in your patches for them to test them for you on other platforms. Your best bet is to use virtual machines (via VMWare or VirtualBox or whatever) to provide you with multiple platforms to work with. You'll find the most stability on OS X (Darwin), with Linux a close 2nd, owing primarily to the large number of buildbot slaves that test these configurations.
Your best bet is to pick a smaller project that is relatively contained. For example, you might choose something that is contained within a single pass, a single target, etc. The modularity of the code should make a lot of projects possible without understanding the entire source base. Pick an area to understand deeply first and then move on to others. It is not expected that somebody who can work on the testsuite is also capable of understanding the nuances of LiveIntervals.
Use the mailing lists and IRC to seek help. Few LLVM contributors seem to regularly visit StackOverflow. As is said frequently within the project, "patches welcome."
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I just posted this as part of a reply to a question about the "best" bug-tracking software...
Well, a tool on its own is just a tool. And while all speak of a toolchain, most just mean a loose collection of tools. Why not look for a problem tracker that "plays well with other children"? That is to say, interfaces well with your IDE, your build tool, your version control system ...
In fact, I think I'll go now and ask a question about the best linked toolchain ...
So, any comments? I would prefer replies for developing C/C++ on Linux and using FOSS (but don't let that prevent you posting Windows based answers if you think that it would help someone else). We don't need a complete chain, but maybe a few groups of linked tools are still better than totally separate "links" in the chain)
I use
Eclipse - for coding and debugging, also its plug-ins for
Doxygen for auto code-documentation
Splint and CppCheck for static code analysis
CppUnit for automated testing
Bugzilla, et all for bug tracking
CVS, Subversion, etc, for version control
Hudson - for automated builds, with plug-ins for
Doxygen for auto code-documentation
CppCheck for static code analysis
CppUnit for automated testing
Bugzilla, et all for bug tracking
CVS, Subversion, etc, for version control
I seem to be missing a tool for project management which interfaces with other "links" in the toolchain. How complete can we make it, end to end, and is there a "best" chain (or, at least, one with the most links)?
Edit: Let's not forget requirements tracking and project planning & tracking - end Edit
And has anyone every diagrammed the relationship between various tools (i.e., which interfaces to which, and in which direction; which can export in the import format of another, etc)?
G'day,
In my experience, I have found that trying to come up with a "definitive" tool chain can cause problems.
One of the worst is that it tends to force people into the "everything looks like a nail" approach to projects. That is, You've done the work to select the tools you think are suitable and you now have your tool suite.
In my experience, it is very difficult to get people to change their "canonical set" of tools for other projects once that tool set has been selected and annointed as such.
I've been doing this for over twenty years now in a variety of projects that ranged from on-board submarine sonar simulators to air-traffic control display systems to helicopter control systems. Even within the same company, different projects need different tool sets to address the various problems that are going to be encountered.
You might think that once you've selected a tool for a particular purpose then you can re-use that tool for all projects, e.g. your selection of BugZilla for bug tracking. But what if there is no suitable SMTP server available because you've got a distributed team and your mail server is internal, locked down, secure, for example.
I'd suggest that it would be better to establish a suite of possible tools from which you can select your project's tool suite from. For example, adding Trac or FogBuzz as a possible bug tracking mechanism.
A lot of things can affect your choice of tools. Off the top of my head I've got:
geographical distribution of teams,
internal lock down, i.e. no public access, of servers e.g. email, source repository, test platform, etc,
having to interface to some existing system because of a desire to reuse aspects of that system, e.g. previous teams had had VisualSourceSafe inflicted upon them,
customer insistence on the use of a particular platform,
the management team for a new project having requirements that differ from the previous management team for regular management type reports,
etc.
Having a suite of possibilities minimises the effect of "trying to squeeze a square peg into a round hole".
Anyway, you might find that you're able to trim down your suite of possibilities after a while because you can demonstrate a successful approach and so get enough traction within the company for the support of doing things the way you've previously done them.
HTH
I think the Unix philosophy militates against these kinds of tightly integrated toolchains. It's no accident that Eclipse, the first thing you mention, came from the Java world. Unix (and by extension, Linux) tends to believe less in things called "plugins" and more in sets of tools that share data stored in flat text files.
By "project management" I'm not sure if you mean something like Make or something to keep track of your team's progress. If you mean something like Make, the Unix world sorely needs a reusable Make that supports "smart recompilation" and will work with multiple compilers. The closest thing is Glenn Fowler's nmake, but that's not very close.
Regarding integrate toolsets more generally,
The best set of tools I've seen are the Advanced Software Technology tools built at AT&T. There's a most excellent book Practical Reusable Unix Software, free to download, which describes the state of play circa 1995. Since then the toolset has only gotten better and richer, but to get an overview of what the hell is going on, you really need the book. These guys started with the Unix group at Bell Labs, and what they've created is not so much a toolchain but a way of life. Joe Bob says check it out.
The other ubiquitous element in many Unix toolchains is (and this is likely to make you laugh or puke) Emacs. Although Emacs Lisp is not anyone's favorite way to write plugins or extensions, sheer accumulation over time has made Emacs into a very rich, powerful programming environment—and it talks to all sorts of other tools. I'm into simplicity, not complexity, so I try to keep to shallow water, but if you're serious about investigating toolchains for Unix, it's something to know about.
I'm looking forward to seeing more answers to your question.
Well its not FOSS but Rational supplies a complete tool chain (except for the compilers!),
You get IDEs, Class diagrams, use cases, requirements tracking, test tools, problem logging tools which integrate well all for a few thousand (or hundreds of) dollars.
None (aprt from the modeling tools) is best of breed, but, they are all pretty good and integrate well with each other.
Disclaimer:-
My "toolset" of choice is vim,make, ddd, gmail and a moleskin notebook for modeling.
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 months ago.
Improve this question
I hope this question does not come off as broad as it may seem at first. I am designing a software application that I would like to be both cross-platform and modular. I am still in the planning phase and can pick practically any language and toolset.
This makes things harder, not easier, because there are seemingly so many ways of accomplishing both of the goals (modularity, platform agnosticism).
My basic premise is that security, data storage, interaction with the operating system, and configuration should all be handled by a "container" application - but most of the other functionality will be supplied through plug-in modules. If I had to describe it at a high level (without completely giving away my idea), it would be a single application that can do many different jobs, all dedicated to the same goal (there are lots of disparate things to do, but all the data has to interact and be highly available).
I find myself wrestling with not so much how to do it (I can think of lots of ways), but which method is best.
For example, I know that Eclipse practically embodies what I am describing, but I find Java applications in general (and Eclipse is no exception) to be too large and slow for what I need. Ditto desktop apps written Python and Ruby (which are excellent languages!)
I don't mind recompiling the code base for different platforms as native exectables. Yet, C and C++ have their own set of issues.
As a C# developer, I have a preference for managed code, but I am not at all sold on Mono, yet (I could be convinced).
Does anyone have any ideas/experiences/ specific favorite frameworks to share?
Just to cite an example: for .NET apps there are the CAB (Composite Application Block) and the Composite Application Guidance for WPF. Both are mainly implementations of a set of several design patterns focused on modularity and loose coupling between components similar to a plug-in architecture: you have an IOC framework, MVC base classes, a loosely coupled event broker, dynamic loading of modules and other stuff.
So I suppose that kind of pattern infrastructure is what you are trying to find, just not specifically for .NET. But if you see the CAB as a set of pattern implementations, you can see that almost every language and platform has some form of already built-in or third party frameworks for individual patterns.
So my take would be:
Study (if you are not familiar with) some of those design patterns. You could take as an example the CAB framework for WPF documentation: Patterns in the Composite Application Library
Design your architecture thinking on which of those patterns you think would be useful for what you want to achieve first without thinking in specific pattern implementations or products.
Once you have your 'architectural requirements' defined more specifically, look for individual frameworks that help accomplish each one of those patterns/features for the language you decide to use and put together your own application framework based on them.
I agree that the hard part is to make all this platform independent. I really cannot think on any other solution to choose a mature platform independent language like Java.
Are you planning a desktop or web application?
Everyone around here seems to think that Mono is great, but I still do not think it is ready for industry use, I would equate mono to where wine is, great idea; when it works it works well, and when it doesn't...well your out of luck. mod_mono for Apache is extremely glitchy and is hard to get running correctly.
If your aiming for the desktop, nothing beats the eclipse RCP (Rich Client Platform) framework: http://wiki.eclipse.org/index.php/Rich_Client_Platform.
You can build window, linux, mac all under the same code and all UI components are native to the OS. And RCP wins in modularity hands down, it has a plug-in architecture that is unrivaled (from what I have seen)
I have worked with RCP for 1.5 years now and I dunno what else could replace it, it is #1 in it's niche.
If your totally opposed to java I would look into wxWidgets with either python or C++
If you want platform independence, then you'll have to trade off between performance and development effort. C++ may be faster than Java (this is debatable FWIW) but you'll get platform independence a lot more easily with Java. Python and Ruby are in the same boat.
I doubt that .NET would be much faster than Java (they're both VM languages after all), but the big problem with .NET is platform independence. Mono has a noble goal and surprisingly good results so far but it will always be playing catch-up with Microsoft on Windows. You might be able to accept its limitations but it's still not the same as having identical multiplatform environments that Java, Python, and Ruby have. Also: the .NET development and support tools are heavily skewed towards Windows, and probably always will be.
IMO, your best bet is to target Java... or, at the very least, the JVM. If you don't like the Java language (and as a C# dev I'm guessing that's not the case) then you at least have options like Jython, JRuby, and Scala. With the JVM, you get very good platform independence, good performance, and access to a huge number of libraries and support tools. There's almost always a Java library, port or implementation that will do what you need it to do. I don't think any other platform out there has the same number of options; there's real value in that flexibility.
As for modularity: that's more about how you build the software than what platform you use. I don't know much about plugin architectures like you describe but I'm guessing that it will be possible in pretty much any modern platform you pick.
If you plan on doing python development, you can always use pyrex to optimize some of the slower parts.
With my limited Mono experience I can say I'm quite sold on it. The fact that there is active development and a lot of ongoing effort to bring it up to spec with the latest .Net technologies is encouraging. It is incredibly useful to be able to use existing .Net skills on multiple platforms. I had similar issues with performance when attempting to accomplish some basic tasks in Python + PyGTK -- maybe they can be made to perform in the right hands but it is nice to not have to worry about performance 90% of the time.
For desktop applications, writing it in an interpreted language, and using a cross-platform UI toolkit like wxWidgets will get you a long way towards platform independence (you just have to be careful not to use any other modules that aren't cross-platform, use things like Python's os.path module, in place of doing things like config_path = "/home/$USER")
That said, to make a good cross-platform application, you will have to do some things differently on each platform..
For example, OS X is probably the most different - preferences are usually stored in ~/Library/Prefernces/ as .plists, UI's are generally based around floating windows, with a single menu-bar docked at the top-of-screen.
I suppose this is where the modularity comes into play.. With the preferences example above, you could have a class UserConfig, of which you have OS-specific versions of. The Windows one stores config data in the appropriate Application Data folder, or the registry. The Mac OS one uses .plist files on ~/Library/Preferences/, and the unix'y one uses ~/.dotfiles.