|
its not clear how the c# application (3) is using the c++ wrapper (2)
if you're using p/invoke, then the 'reference/link' is in the p/invoke statements themselves, ie, the DllImport clause
|
|
|
|
|
If the C++ dll has been linked to the static library, then you only need access to that dll in your C# code (assuming I have understood the question correctly).
|
|
|
|
|
Member 11201788 wrote: Since the library file is statically linked in our C++ static library, does the dll also need to be linked/referred in our application.
Do you mean dll or lib at this point?
If you mean lib, then it should be a no, you don't need a reference to it while building your C# application. If you mean dll, then yes, your C# application does need a reference to your dll.
|
|
|
|
|
Since the library file(lib provided by client) is statically linked in our C++ static library, does the dll(lib provided by client) also need to be linked/referred in our application.
They(client) have provided their .lib and .dll. Can we use only .lib in our C++ static library.
|
|
|
|
|
Member 11201788 wrote: Since the library file(lib provided by client) is statically linked in our C++ static library, does the dll(lib provided by client) also need to be linked/referred in our application.
Shouldn't have to... if you load the lib into your dll properly.
Member 11201788 wrote: They(client) have provided their .lib and .dll. Can we use only .lib in our C++ static library.
Again, should be able to just use the lib, since it's a collection of objects. Only thing that may be a limiter is that you have to use a lib that was compiled with the same compilation settings as your project, since the name mangling of C++ can affect you being able to find your methods. A lot of people tend to do their exports/imports in a C-style format even within C++ in order to avoid C++ name mangling issues.
|
|
|
|
|
I am expanding my knowledge of class templates so I am building a very basic template of type Array<T>.
I'll include only the code that pertains to the behavior that is confusing me.
Template Header
#include <stdexcept>
#define CORE_ARRAY_DEFAULT_LENGTH 20
template <class T>
class Array
{
private:
T** _array;
int _size;
int _length;
public:
Array(void)
{
_array = new T*[CORE_ARRAY_DEFAULT_LENGTH]();
_size = CORE_ARRAY_DEFAULT_LENGTH;
_length = 0;
}
~Array(void) { Clear(); }
int Size(void) const { return _size; }
int Length(void) const { return _length; }
T operator [] (int index) const
{
if ((index < 0) || (index >= _length))
throw std::out_of_range("index");
else
return * _array[index];
}
void Add(T value)
{
if (_length == _size)
Resize();
_array[_length] = new T(value);
++_length;
}
}
And the source
#include "MyArray.h"
#include <cstdlib>
#include <cstdio>
void main(void)
{
Array<int> iArrayA;
for (int i = 0; i < 10; ++i)
iArrayA.Add(i);
for (int i = 0; i < 10; ++i)
printf("%d\n", iArrayA[i]);
Array<int> * iArrayB = new Array<int>();
for (int i = 0; i < 10; ++i)
iArrayB->Add(i); for (int i = 0; i < 10; ++i)
printf("%d\n", iArrayB[i];
delete iArrayB;
system("pause");
}
Here is what I had to change it to to get the desired results:
printf("%d\n", iArrayB[0][i]);
What I don't get here is why when the array was declared as a local (Array<int> iArrayA;) did the accessor [] pull the stored int at the correct element but when I had the array declared as a pointer on the heap (Array<int> * iArrayB = new iArray<int>();) the accessor [] was seemingly pulling random data until I added the [0] before the [i]?
I am wondering if this has something to do with overloading the array subscript operator. Which is what has jumped out at me while I am writing this.
Also, is there a way I can code the accessor to work for both locals and heap pointers? Is there any way around this?
|
|
|
|
|
private:
T** _array;
Why is this an array of pointers to T types, rather than just an array of T types? Woudl it not be better to have something like:
T* _array;
_array = new T[CORE_ARRAY_DEFAULT_LENGTH];
T operator [] (int index) const
{
if ((index < 0) || (index >= _length))
throw std::out_of_range("index");
else
return _array[index];
}
|
|
|
|
|
For one, I've designed it to create heap copies of everything that gets added. This way it can handle both primitive data types and objects and be able to delete them. My first attempt at this used this approach but I ran into problems when trying to handle objects created on the heap. You can't delete primitives and if you don't delete heap objects, it leaks memory. By making it create all of its data on the heap no matter what get's passed in, I can avoid this problem.
Edit: I got the T** _array; idea from my practice attempts with the DirectX SDK. I saw it use this approach all over the place.
|
|
|
|
|
The reason for the different behvior is that you can only override the accessor [] for an instance or reference but not for a pointer. Using [] on a pointer is always interpreted as pointer + index by the compiler. So the compiler thinks you have an array of Array.
The usual syntax around this is
printf("%d\n", (*iArrayB)[i]);
This makes clear that iArrayB isn't an array but a pointer to a single object, and that you want to call the operator for the object it points to.
The good thing about pessimism is, that you are always either right or pleasently surprised.
|
|
|
|
|
Ah, I was thinking that it was something along those lines. I can see now that overloading the subscript operator is only good in certain situations. This doesn't sound like a good approach since it would require different code to access the data behind an object pointer then behind a local variable. I'll just change the accessor to a function.
T GetValueAt(int index)
{
if (index < 0 || index >= _length)
throw std::out_of_range("index");
return *_array[index];
}
This should work just fine for what I am trying to do.
This was informative, thank you.
|
|
|
|
|
Be careful, you are heavingly doing copy of your objects.
You should pass T& when you add the object and return T& when you retrieve them.
I would also suggest to have a const version of your accessor, returning 'const T&'.
|
|
|
|
|
|
Hi,
I VS 2012 as a makefile project in the nmake properties IntelliSense Preprocessor definitions I specify _AMD64_
Yet I get the following compile error
:\Program Files\Microsoft SDKs\Windows\v7.1\Include\winnt.h(135): fatal error C1189: #error : "No Target Architecture"
|
|
|
|
|
It sounds as though your definitions are not being exported correctly, check the make file to see what it is setting.
|
|
|
|
|
Thanks
I am wondering a on makefile visual studio build where a line command is used
what role do the preprocessor flags play in the build
thanjks
|
|
|
|
|
ForNow wrote: what role do the preprocessor flags play in the build
No idea, but as I said earlier, you should look at the makefile to see whether this value has been propagated correctly.
|
|
|
|
|
Hi to all,
i write a class (A) that works with an object from another class (B); class B needs to call a method from class A, but i would like this function from class A it's not visible when i use class A for my projects.
Example: i write a numeric edit that use spin button; i write a spin button class derived from CSpinButtonCtrl and an edit class derived from a CEdit; edit have a function MyFunction() called from spin button class.
So, when i use numeric edit in my projects, i would like MyFunction() (and also all class spin button) is not visible (protected).
What is the correct way to do that, if it's possible ?
Thanks
|
|
|
|
|
It seems that you are looking for friend[^].
For your example you can make your CEdit derived class a friend class of the spin control class:
class CMyEdit : CEdit {
friend class CMySpinControl;
protected:
void MyFunction();
};
|
|
|
|
|
|
As i can, i try.
Thanks to all
|
|
|
|
|
An alternative to using "friend" classes would be to use messages and message handlers. In MS Windows, messages are what windows already use to communicate with one another. You can easily add new messages and handlers.
|
|
|
|
|
(Bit late to the party... still think this is worth saying and it might help you in future)
If you ever find yourself wanting to use a class but there's aspects of it's interface that you don't want to work with then don't try and modify the class you want to use - that way lies madness and hackiness of the first degree. If the class with the relatively fat interface really needs a big interface somewhere else you don't want to break that. So what can you do about it? Wheel out the software engineer's swiss army knife - another level of indirection!
So if you've got a class:
class fat_and_dangerous
{
public:
void safe();
void dangerous();
};
and don't want clients to use dangerous() implement another class using it:
class skinny_and_safe
{
public:
skinny_and_safe() : fat_( new fat_and_dangerous ) {}
void safe() { fat_->safe(); }
private:
std::unique_ptr<fat_and_dangerous> fat_;
}
and in most of your client code only use skinny_and_safe.
Just out of interest... don't actually implement skinny_and_safe inline. It leaks too many implementation details to the client. Don't worry about performance - most compilers (actually linkers working with compilers) these days will elide the indirect call - until a profiler tells you that it's slow.
|
|
|
|
|
Thanks very much to all: it's works and it's what i need.
For Albert Holguin and Aescleal: i think with "friends" it's more simple; thanks likewise.
|
|
|
|
|
Friends will work but you should always be aware of the coupling that introduces into your design.
|
|
|
|
|
/*
William Strickland
Project 3
Is Leap Year Portion
*/
#include <stdio.h>
#include <stdlib.h>
#include "..\..\stdbool.h"
bool isLeapYear(int *year);
int main(int argc, char *argv[])
{
int year = atoi(argv[4]);
printf("Name: William Strickland \n");
printf("Is Leap Year \n");
if (isLeapYear(&year))
{
printf("%d is a leap year", year);
}
else
{
printf("%d is not a leap year", year);
}
return 0;
}
bool isLeapYear(int *year)
{
if (*year % 4 == 0 && *year % 100 != 0)
{
return 1;
}
else if (*year % 100 == 0 && *year % 400 == 0)
{
return 1;
}
else
{
return 0;
}
}
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
