Tag Info

Hot answers tagged

12

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 ...


8

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 ...


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 ...


5

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 ...


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 ...


4

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.


4

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")] ...


4

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 ...


3

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 ...


3

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 ...


3

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 ...


3

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 ...


3

QA as a whole is about assessing the risk that the product is suitable for the users to use. In reality, QA is not a 100% guarantee in part because it is usually impossible to test every possible action (including all non valid actions) in every possible environment. Since you have limited QA resource, you have to make decisions about where to focus that ...


3

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 ...


2

As Andy said cross platform compatibility wasn't a big goal, whereas broad platform and hardware implementation was a goal, with the net result that you can write conforming implementations for a very wide selection of systems. Binary standardization would have made this practically unachievable. C compatibility was also important and would have ...


2

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 ...


2

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 ...


2

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 ...


2

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 ...


2

You are probably better off having the DLL's in their own respective directories. This way if one group changes one of them in a way that conflicts with an application from another group, it wont impact that application. I wouldnt worry about having duplicate DLL's - in the scheme of things its probably not much disk space. Another approach to consider ...


2

Something is wrong indeed. There are two approaches to organize development of something split in modules: Separate and asynchronous: you version every DLL separately and treat the rest of modules similarly to third-party components. In this case every DLL should make some kind of release to provide its functionality to users (other developers). This will ...


2

You quite clearly need a dedicated team member who's job it is is to update their code to the head every time anyone commits a change, and also does a full, clean build every night and copies the dlls produced each and every time to a central location where the other team members can grab the dlls. Unfortunately this is a laborious and tedious task. ...


2

I don't think that it's a good idea to have a branch purely for executables and DLLs. Executables and DLLs should be a by product of building master branch on the build server. Build server will build the branch, execute tests (if any) and store compiled assemblies somewhere on the network. Whenever deployment is needed, you will take compiled artefacts ...


1

Your language of choice supports calling any native DLLs written in any language. It's not really limited to those made with C, C++ or Delphi. You could call Fortran DLLs too, for example. The problem is that the C# DLL is a managed DLL. That's a completely different beast from a native DLL. You will need to put a bridging layer in between the C# and your ...


1

Normally one puts everything related to data access in a data access layer (DAL) which would be a separate DLL-file. Creating this class library is pretty straight forward. Just remember to add a reference to your newly created project in you main project. Whether or not you deal with exceptions in the DAL or you let the business logic layer deal with it is ...


1

No, I don't think it's ethical to incorporate GPL software into your close-sourced project. Any action that begins with an attempt to "bypass" the GPL is probably violating the spirit of the GPL. I don't find it an acceptable solution. If your software runs GPL code, then your software should be GPL. That's the sort of give and take relationship that the ...



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