Hot answers tagged

15

Languages with binary-compatible compiled form are a relatively new phase[*], for example the JVM and .NET runtimes. C and C++ compilers usually emit native code. The advantage is that there is no need for a JIT, or a bytecode interpreter, or a VM, or any other such thing. For example, you can't write the bootstrap code that runs at machine startup as ...


14

Profile it! It's the only way to know exactly what is happening and what is using what resources and where it's being limited at.


11

This is very possible. If you have defined an identical namespace and type name on different assemblies (or in your project and the added assembly), you will get a conflict with any code that tries to use one or another of these types. If you ensure you have unique namespaces, as do your references you wouldn't have this problem. Another possibility has ...


9

Because the license demands it for your use case (e. g. lib being LGPL vs. your project being proprietary). Because you want to decouple deployed app and lib version. Because you aren't absolutely sure the lib is bug-free. Because the target distribution(s) provide(s) the lib through their packet manager. Because the lib is used by more than one binary and ...


8

No, you shouldn't. You should pass in connection strings as a dependency, or use ConfigurationManager to pick them up from the application configuration. Hard coding them means that you can't change them without recompiling the libraries. The reason I don't want to be connecting to a database through the class library is error handling False logic ...


8

You already spotted most of the pros and cons. Using cs files as references is indeed more lightweight and often easier to manage. However, I recommend to use this approach exclusively when your cs files are fully self-contained and do need have any special build requirements. Using separate DLLs will make dependencies to other utlitites or libraries ...


8

DLLs are handy when an application is large and there are pieces that require updates, but not the entire application. So, if you're writing MS Word, it's handy to have the spell-check code in a DLL that can be updated without having to update the entirety of MS Word. If what you're writing is a small utility app (or a series of self-contained apps that ...


7

Cross-platform and cross-compiler compatibility were not the primary goals behind C and C++. They were born in an era, and intended for purposes for which platform-specific and compiler-specific minimizations of time and space were crucial. From Stroustrup's "The Design and Evolution of C++": "The explicit aim was to match C in terms of run-time, code ...


7

The "means for them to use their own modified version of the library" in this context is letting users use their own libconfig.dll instead of yours if they want. By making it dynamically linked you have fulfilled this requirement. They can just replace the file. If you had made it statically linked instead, where you don't need the libconfig.dll in order ...


6

There is in-fact a book that is precisely what you seek. It is call, appropriately enough, API Design for C++.The book's website has source code from the book and Errata as well.


6

You can call from C# to C/C++ directly using a technology known as P/Invoke. With P/Invoke, a C++ function can be made to look just like a C# function. Here's a simple example from this article in MSDN Magazine: C Method Definition BOOL MessageBeep( UINT uType // beep type ); P/Invoke Definition in C# of method in C [DllImport("User32.dll")] ...


6

By directly coupling the clients to the database, updates will always be a problem. With a layer in between, you can call it a microservice or an SOA layer or whatever, you can keep the two separate. The service that sits in between can forward requests on to the database to begin with (or send requests to both and just return the original answer) and no ...


5

Take a look at this. By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too ...


5

This is an ordinary sandbox model (the one which is used with plugins/addins). Instead of calling the libraries directly, you load them in a different AppDomain. Doing this actually allows you to update the corresponding libraries while the application is still running. If you want to automate the process, the client application can monitor the directory ...


5

The problem described in the quotation is caused by the quite deliberate avoidance of standardisation of symbol-name mangling schemes (I think "standardisation at the binary level" is a misleading phrase in this respect although the issue is related to a compiler's Application Binary Interface (ABI). C++ encodes a function or data object's signature and ...


5

That very problem is what COM was designed to address. I'll leave it to my good friend Jeremiah Morrill to explain what the problem is: I explained briefly how simple exporting regular ā€œCā€ methods can be to share code between DLLs and the application. I also explained how C++ classes get flattened and compiled down and also how they are seen to ...


4

If you need this data then it should be either a) passed into the dlls (as you suggest), or b) stored in a "global" dll from which you can reference it from other dlls. Given you're talking about session information I'd go with the latter so that you only have to keep in up to date in one location. If you passed it into each dll when it got initialised ...


4

Does executable compression hurt performance? As with most performance questions, I suspect the answer is, "Do some performance tests / profiling for yourself and see what you find out." Performance might be worse, because you have the run-time overhead of decompression. Performance might be better, because you have less data that you need to read off of ...


4

Memory usage wont be a problem for you. A couple of my Delphi apps routinely use a GB or more. So long as you are not running into the platform limits you'll be fine. I'm not sure if resources themselves are loaded from disk when the exe starts. Certainly they would be for auto-created forms. So you'll want to avoid those, and continue to create the ...


4

Yes, you're allocating memory but not freeing it, so there is a memory leak. A good approach is to allocate and deallocate the memory in the same place, i.e. wherever the DLL is called from - in your case, LabVIEW. That is, make your function void Foobar(char *array) (or int Foobar(char *array) and return the array length). Then you just need to make sure ...


4

Some reasons NOT to sign an assembly: Because signed assembly can only load other signed assemblies. - a real problem if you rely on 3d party libs. When project is signed it's requires to have the versions, so you can't use direct bindings between your projects in the same solution or you'll have to recompile the application to be able to use a different ...


4

Sure, C# will support that. Take a look at this example that uses the System.Collections.Generic.Dictionary as the base class. public class MyDictionary : Dictionary<string, int> { } public class MyMain { public MyMain() { MyDictionary dictionary = new MyDictionary(); dictionary.Add("hello", 1); } } There are some ...


4

Export a C interface. Not only does that solve the DLL problem, but it allows for plugins in languages other than C++. Then write a C++ wrapper for the C API as a header only library. You can't use C++ non-standard-layout objects in the API because there is no standard ABI for them, so you would be requiring the library and users to all be compiled with ...


3

Inside COM, Inside ATL and Inside COM+ for starters. Yeah, they're 10+ years old, but they're still valid as far as they go, and I need to start reviewing the basics right now. I haven't touched COM professionally since the 90s. There are some new interfaces in C++/CX (e.g. IInspectable), but I am not aware of any books on the subject yet. C++/CX neatly ...


3

This is pretty much impossible. The simple fact is that sometimes, you need the compiler to do a job, and you can't just magic that necessity away. There is no function that can make std::vector not a header-only library. The compiler can make many magics work, but you can't have them without invoking it, and that's a fact of life. Here's what you can do: ...


3

There are two drawbacks to keeping just the managed DLL: a) you will need the .NET Framework on the target machine b) there will be two layers of marshaling between an unmanaged caller and the code you've wrapped: a COM Callable-Wrapper between the native caller and the COM interface of your .NET Assembly, and the managed-unmanaged transition between your ...


3

Seeing as nobody else mentioned this, you asked: what are the possible ways to mitigate this There is a clean solution just for this case, without constraints, and without annoying workarounds. You can define Assembly alises so that the compiler would know which ones to refer to in the right place. Have a look at ...


3

It's actually not a different story on Windows. You'd typically create an installer for your application. The user runs the installer, the application gets installed. That's it. There's two main approaches to use on Windows. You can use Windows Installer, which is the installer service that runs on Windows and installs .msi files (kind of like .rpm's or ...



Only top voted, non community-wiki answers of a minimum length are eligible