multiple main functions

[fiat42lux]

Hi.
I have a file1.cpp that uses functionality implemented in file2.cpp, and I want each of them to have its own main function. That is, file2 is a standalone application whose functions can also be called by file1, and I want the compiler to output two accordingly different executables. How do I convince it to do that? (The linker is complaining about duplicate _main symbols at the moment.)

Thanks for any advice.

[zerocool2k]

Nevermind. I was confused multithread with something else.

[ninja9578]

Most IDEs support having multiple targets. You can have one of those files be compiled with one target, and use the other one with the second target. You can use one or the other, but not both. C++ does not allow you to have multiple process entries. I don't think any languages do.

Either that, or you can make your file2 a dynamic library.

Give us more specifics of what you're trying to do and we can help figure out which approach is better for you.

[Ajay Vijay]

Well, you can run two instances of same application. Back each instance with some command line argument.
Or, you may create multiple thread within same process.

All depends on your exact requirements.

[fiat42lux]

Thanks for your replies! I appreciate the interest. Some more details:
My application is a digital analogy to an audio mixing board with effects sidechains.
Mixer.cpp contains mix() functions for mixing multiple audio streams into one. Echo.cpp contains functions for applying a delay effect to an audio stream -- where the "wet/dry mix", ie. the ratio of the delayed, "wet" signal to the original, "dry" input signal, is controlled by mix(). So I want to be able to call mix() EITHER as part of its own standalone CLI application (Mixer) OR from within the Echo application. An alternative would be to require the user to run Echo and then explicitly pipe its output plus the dry signal into Mixer in an additional step, but there are various reasons I'd like to avoid that. I'm guessing I'll have to turn Mixer.cpp into a shared library; I dunno yet how to go about doing that, so I'm still looking for alternatives.
?

[Ajay Vijay]

I am afraid to say that your requirements are still not clear.
Do you want Mix function to be available across multiple files or your project?
Or you want to share is across multiple projects, so you need Mix into DLL and export as function?
How CLI is coming into picture?

You can acheive either (ALL) of these, but you need to have/give exact requirements.

[fiat42lux]

I'm not sure what exactly you mean by a project... I'm only familiar with the term as an IDE mechanism, and I'm not using an IDE. But I would guess this is all a single project. It will be distributed as a single, complete set of source files with a makefile included.

The source files:
- Mixer.cpp, contains mix()
- Echo.cpp, calls mix()
- various other files that aren't relevant

What I want to end up with after compilation:
- a command-line executable called Mixer -- so Mixer.cpp needs a main function
- a command-line executable called Echo -- so Echo.cpp also needs a main function

What I was getting:
ld: duplicate symbol _main in Mixer.o and Echo.o

I've found a solution of sorts: I moved Mixer.cpp's main function into a new file called Mix.cpp, which contains nothing else, just a main() that calls mix(). Seems a bit clunky to me, but it works until I find something better...

[Ajay Vijay]

Just wondering how you are working with such complicated multimedia project, that involves audio-mixer kind of thing. I request to you clear your basics, and find what your exact requirements are.
For your problem, there could be couple of solutions - but again, all depends on your requirements.

[fiat42lux]

I'm pretty sure I know what my exact requirements are. It seems to me that I've explained them repeatedly, but apparently I haven't done it well enough. Could you be a little more specific about what's still unclear? Or tell me what possible solutions you have in mind, and I'll figure out myself whether they work for me.
Either way, thanks for trying.

[Ajay Vijay]

The source files:
- Mixer.cpp, contains mix()
- Echo.cpp, calls mix()
- various other files that aren't relevant

What I want to end up with after compilation:
- a command-line executable called Mixer -- so Mixer.cpp needs a main function
- a command-line executable called Echo -- so Echo.cpp also needs a main function

You probably need to create two projects for Mixer and Echo, export the 'mix' function using a DLL.

You did not mention if 'mix' is global function or class' method.

And why you say that both files "need" main function? No one needs main, it's the main which directly/indirectly calls other functions.

You cannot run same executable and run two times, without:
* Creating two instance of application
* Having two different processes
* Having multi-threading (within one executable)

[fiat42lux]

You probably need to create two projects for Mixer and Echo, export the 'mix' function using a DLL.

Since Mixer.cpp now has no main() and only contains service functions that are called either by Echo or Mix, I guess it's basically a library. However, I expect these components to be distributed only as source to be compiled locally, so as I understand it, dynamic linking is unnecessary, right?

You did not mention if 'mix' is global function or class' method.

At the moment it's global, though I think it would be cleaner and better style to turn Mixer into a class and make mix() a static (class) method. It's on the to-do list.

And why you say that both files "need" main function? No one needs main, it's the main which directly/indirectly calls other functions.

You cannot run same executable and run two times, without:
* Creating two instance of application
* Having two different processes
* Having multi-threading (within one executable)

Ok, I think this might be where I lost you...
I'm making the two components (mixer and echo) separate executables because I intend them to be used Unix-style, ie. as small self-contained CLI commands whose stdin and stdout are to be piped together. Since the mixer's functionality has nothing to do with sound effects, they don't belong in the same executable. That way, as I write more sound effects, I can hook them up to the mixer and the actual mixer executable won't know or care or even need to be recompiled.
Does this clear things up a little?

[Ajay Vijay]

However, I expect these components to be distributed only as source to be compiled locally, so as I understand it, dynamic linking is unnecessary, right?

Well... If the code that you want to share (or say duplicate) into multiple modules is small, you can keep the source code. This way you'd have code duplication, but you can avoid that by using same set of header and souces files into multiple projects.

But the code you want to share is meduim or large, you may like to put them in DLL, which would be shared by both (or more, in future, may be!). This would reduce the runtime file size.

At the moment it's global, though I think it would be cleaner and better style to turn Mixer into a class and make mix() a static (class) method. It's on the to-do list.

Not necessarily. Why would you put 'mix' into any arbitrary class, which is non-relevant. Just for the sake that mix mixes with Mixer? (no pun!)

I'm making the two components (mixer and echo) separate executables because I intend them to be used Unix-style, ie. as small self-contained CLI commands

Well, in that case it is absolute that you have to have two projects that generate EXE's. And those executables take input and produce output in pipe-lined manner.