I am using wxSlider to adjust gain in my Windows C++ application.
Bind() function code:
sliderAmp->Bind(wxEVT_COMMAND_SLIDER_UPDATED, wxScrollEventHandler(App::OnSliderAmpChanged), this);
With such an implementation, the effect of "bounce" of values appears, i.e. multiple identical values may appear.
How to change the code so that the gain control is more reasonable?
Notice that wxEVT_COMMAND_SLIDER_UPDATED is an alias of wxEVT_SLIDER, and in the latest versions only the latter remained documented.
I think you need to handle only wxEVT_SCROLL_CHANGED. Unfortunately that is documented to be MSW only.
For non-MSW, you might get away with handling wxEVT_SCROLL_THUMBRELEASE. In case you want keyboard support you might need to add handling of other events. See wxSlider Class Reference too.
I have a C++-CLI ref class that exposes a profiling infrastructure implemented in C++.
In C++ I have the preprocessor directive PROFILING_ENABLED to determine whether the intrusive profiling functions are in the code or not.
When exposing these to managed code, I thought that using the managed ConditionalAttribute would be appropriate. But I struggle with the syntax.
Here is my attempt:
#ifdef PROFILING_ENABLED
// c++ macros are defined and active on the project level, I would like the
// conditional attribute to be active as well.
#define MANAGED_PROFILING_ENABLED
// how do I define the managed conditional "MANAGED_PROFILING_ENABLED" in C++-CLI?
#endif
public ref class Profiler
{
public:
[ConditionalAttribute("MANAGED_PROFILING_ENABLED")] // this compile but always inactive
static void PushRange(System::String ^ name, Color color);
[ConditionalAttribute("MANAGED_PROFILING_ENABLED")]
static void PopRange();
};
I would like to achieve the following:
If the native c++ preprocessor directive is active, the managed ConditionalAttribute should be active as well.
If on the other hand the native c++ preprocessor directive is inactive, the managed ConditionalAttribute should be inactive.
The below standards document is pretty old. But assume that, may be still valid.
https://www.ecma-international.org/publications/files/ECMA-ST/ECMA-372.pdf
Go to section 29.4.3 (You can find below content about conditional attributes in c++/CLI).
C++/CLI does not provide this ability; although attributes of this
type are accepted, they have no affect on code generation or
execution.
Is it possible to dynamically create __declspec(dllexport)'ed functions without having the preprocessor involved in MSVC 2015?
I'm creating a DLL plugin-creation toolkit for some kind of measurement software and want to make the later client-programmer being able to add some kind of "extra-features" to the plugin in the DllMain, e.g.:
// Create a new instance of the custom driver
MyPluginDriver *myPluginDriver = new MyPluginDriver();
// Assign it to the core DLL
pluginCore.addDriver(myPluginDriver);
For each of this addDrivercalls, the DLL later has to provide a callback function, whose name can be freely chosen. The main app expects the names of those functions getting passed by request in another callback.
So, what would be the 'best practice' for generating those extern "C" functions dynamically whithout #define's and stuff?
Maybe some kind of Lambda way?
EDIT:
I think I've forgot to mention that it's a commercially available measurement software for which I'm writing that PDK. It's a fixed interface (and a fairly complex one, too) of hard-coded and expected function names by the app for the general callbacks. There's only that particular callback expecting some function names to call for measurement cycles which is relevant here.
Imagine we have a solution with 2 projects: MakeDll (a dll app), which creates a dll, and UseDll (an exe app), which uses the dll. Now I know there are basically two ways, one is pleasant, other is not. The pleasant way is that UseDll link statically to MakeDll.lib, and just dllimports functions and classes and uses them. The unpleasant way is to use LoadLibrary and GetProcAddress which I don't even imagine how is done with overloaded functions or class members, in other words anything else but extern "C" functions.
My questions are the following (all regarding the first option)
What exactly does the MakeDll.lib
contain?
When is MakeDll.dll loaded into my application, and when unloaded? Can I control that?
If I change MakeDll.dll, can I use the new version (provided it is a superset of the old one in terms of interface) without rebuilding UseDll.exe? A special case is when a polymorphic class is exported and a new virtual function is added.
Thanks in advance.
P.S. I am using MS Visual Studio 2008
It basically contains a list of the functions in the DLL, both by name and by ordinal (though almost nobody uses ordinals anymore). The linker uses that to create an import table in UseDLL.exe -- i.e., a reference that says (in essence): "this file depends on function xxx from MakeDll.dll". When the loader loads that executable, it looks at the import table, and (recursively) loads all the DLLs it lists, and (at least conceptually) uses GetProcAddress to find the functions, so it can put their addresses into the executable where they're needed.
It's normally loaded during the process of loading your executable. You can use the /delayload switch to delay its being loaded until a function from that DLL is called.
In general, yes. In the specific case of adding a virtual function, it'll depend on the class' vtable layout staying the same other than the new function being added. Unless you take steps to either assure or verify that yourself, depending on it is a really bad idea.
MakeDll.lib contains a list of studs for the exported functions and their RVAs into the MakeDll.dll
MakeDll.dll is loaded into the application based on what type of loading is defined for the dll in question. (e.g. DELAYLOAD). Raymond Chen has an interesting article on that.
You can use the new updated version of MakeDll.dll as long as all the RVA offsets used in UseDll.exe have not changed. In the event you change a vtable layout for a polymorphic class, as in add a new function in the middle of the previously defined vtable, you will need to recompile UseDll.exe. Other than that you can use the updated dll with the previously compiled UseDll.exe.
The unpleasant way is to use LoadLibrary and GetProcAddress which I don't even imagine how is done with overloaded functions or class members, in other words anything else but extern "C" functions.
Yes, this is unpleaseant but is not as bad as it sounds. If you choose to go through with this option, you'll want to do something like the following:
// Common.h: interface common to both sides.
// Note: 'extern "C"' disables name mangling on methods.
extern "C" class ISomething
{
// Public virtual methods...
// Object MUST delete itself to ensure memory allocator
// coherence. If linking to different libraries on either
// sides and don't do this, you'll get a hard crash or worse.
// Note: 'const' allows you to make constants and delete
// without a nasty 'const_cast'.
virtual void destroy () const = 0;
};
// MakeDLL.c: interface implementation.
class Something : public ISomething
{
// Overrides + oher stuff...
virtual void destroy () const { delete this; }
};
extern "C" ISomething * create () { return new Something(); }
I've successfully deployed such setups with different C++ compilers on both ends (i.e. G++ and MSVC interchanged in all 4 possible combinations).
You may change Something's implementation all you want. However, you may not change the interface without re-compiling on both sides! When you think about it, this is faily intuitive: both sides rely on the other's definition of ISomething. What you may do to add this extra flexibility is use numbered interfaces (as DirectX does) or go with a set of interfaces and test for capabilities (as COM does). The former is really intuitive to set up but requires discipline and the second well... would be re-inventing the wheel!
I want to modify the glBindTexture() function to keep track of the previously binded texture ID's. At the moment i just created new function for it, but then i realised that if i use other codes that use glBindTexture: then my whole system might go down to toilet.
So how do i do it?
Edit: Now when i thought it, checking if i should bind texture or not is quite useless since opengl probably does this already. But i still need to keep track on the previously used texture.
As Andreas is saying in the comment, you should check this is necessary. Still, if you want to do such a thing, and you use gnu linker (you don't specify the operating system) you could use the linker option:
--wrap glBindTexture
(if given directly to gcc you should write):
-Wl,--wrap,glBindTexture
As this is done at linker stage, you can use your new function with an already existing library (edit: by 'library' I mean some existing code which you can recompile but which you wouldn't want to modify).
The code for the 'replacement' function will look like:
void * __wrap_glBindTexture (GLenum target, GLuint texture) {
printf ("glBindTexture wrapper\n");
return __real_glBindTexture (target,texture);
}
You actually can do this. Take a look at LD_PRELOAD. Create a shared library that defines glBindTexture. To call the original implementation from within the wrapper, dlopen the real OpenGL library and use dlsym to call the right function from there.
Now have all client code LD_PRELOAD your shared lib so that their OpenGL calls go to your wrapper.
This is the most common method of intercepting and modifying calls to shared libraries.
You can intercept and replace all calls to glBindTexture. To do this you need to create your own OpenGL dll which intercepts all OpenGL function calls, does the bookkeeping you want and then forward the function calls to the real OpenGL dll. This is a lot of work so I would defintely think twice before going down this route...
Programs like GLIntercept work like this.
One possibility is to use a macro to replace existing calls to glBindTexture:
#define glBindTexture(target, texture) myGlBindTexture(target, texture)
Then in you code, where you want to ensure against using the macro, you surround the name with parentheses:
(glBindTexture)(someTarget, someTexture);
A function-like macro is only replace where the name is followed immediately by an open-parenthesis, so this prevents macro expansion.
Since this is a macro, it will only affect source code compiled with the macro visible, not an existing DLL, static library, etc.
I haven't ever worked with OpenGL, so not knowing anything about that function, here's my best guess. You would want to replace the glBindTexture function call with your new function's call anywhere it occurs in your code. If you use library functions that will call glBindTexture internally, then you should probably figure out a way to reverse what glBindTexture does. Then, anytime you call something that binds a texture, you can immediately call your reversal function to undo its changes.
The driver WON'T do it, it's in the spec. YOU have to ensure that you don't bind the same texture twice, so it's a good idea.
However, it's even a better idea to separate the concerns : let the low-level openGL deal with its low-level stuff, and your (thin, thick, as you want) abstraction layer do the higher-level stuff.
So, create a oglWrapper::BindTexture function that does the if(), but you should not play around with LD, even if this is technically possible.
[EDIT] In fact, it's not in the ogl spec, but still.
In general, the approaches have been catalogued under the heading of "seams", as popularized in M. Feather's 2004 book Working Effectively with Legacy Code. The book focuses on finding seams in a monolith application to isolate parts of it and put them under automated testing.
Feathers' seams can be found in the following places
compiler
__attribute__ ((ifunc in GCC, https://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Function-Attributes.html
preprocessor
change what gets used with a #define
linker
-Wl,--wrap,func_xyz
linking order, first found symbol gets used, program can delegate using dlsym(RTLD_NEXT, ...)
the binary format has a Procedure Linkage Table which can be modified by the program itself when it runs
in Java, much can be achieved in the JVM, see for example Mockito
language features
function pointers, this can actually be done so as to add no syntactic overhead at point of call!
object inheritance: inherit, override, call super()
sources:
https://www.informit.com/articles/article.aspx?p=359417&seqNum=3
https://www.cute-test.com/guides/mocking-with-cute/