|
This is often the case. I don't mind too much except when I go to fix the code and find it is an unformatted mess with little structure that is a pain in the eyes to read. Then I usually go and write my own.
With DirectX I would say it depends how much COM you know. If you're happy with COM principles then just go straight to DirectX it's not at all difficult. If you hate or don't know COM then I would probably use with the toolkit unless it is hopeless.
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
I've not used SharpDX, but my understanding is that a very thin wrapper around DirectX, so probably diving in the DirectX documentation can help you (actually DirectX documentation is full of examples that, hopefully, could be easily translated into C# or used directly in most cases).
|
|
|
|
|
the toolkit is a high level abstraction like XNA, the wrapper part is actually well documented with references to the unmanaged documentation and descriptions of the small differences.
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
"Given the chance I'd rather work smart than work hard." - PHS241
"'Sophisticated platform' typically means 'I have no idea how it works.'"
|
|
|
|
|
Your English is as good as many of the programmers I know who speak it as it's first language...and as I tell people who complain about understanding people who speak/write English as a second/third/fourth... language, "It's better than my Portuguese (Hindi, Chinese, Russian...take your pick)."
cat fud heer
|
|
|
|
|
|
Matthew, it is hard to believe that you get different behaviors with all build options being identical. Shouldn't you double check that ? It is also hard to understand the value 16. short s are never 8 bytes long, are they ? Could it be a struct member alignment option silently set in a preceding header file ?
|
|
|
|
|
YvesDaoust wrote: Could it be a struct member alignment option silently set in a preceding header
file
I suspect it might be just that, but leaking from a Windows header. Including <windows.h> pulls in <string.h> which in this case is a project header not a system header. My guess is that the string support code is being included in the middle of a windows header section that for some reason has different alignment options. Tracking it down or doing anything about it would be rather difficult though.
I've worked round this one but I'll be on the lookout next time and also need to get pragma pack support into my Compiler support library as soon as I can.
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
Yes, it also occurs to me that your core problem is not the size but the inconsistency.
I would look for a platform specific solution to this problem rather than trying to find a platform generic packing instruction.
Good luck anyway.
|
|
|
|
|
Is this on a 16-bit, 32-bit or 64 bit environment? If you are using Visual Studio, check the preprocessor directives in all the projects. Also check the code generation struct member alignment. I've had this before: all projects just used default settings except some were VS6, some were VS2003 and some were VS2005. I just got random unexplanable crashes, so, like you, I decided to look at the sizeof things and they were very different. Nowadays I avoid such things by not having inline functions. It may run slower but at least you don't spend weeks trying to figure out stuff like this.
|
|
|
|
|
Maybe it's my bad experience with headers, but I'm immediately suspicious of the _tChar's type...
|
|
|
|
|
May be you can try to print out actual alignment settings with #pragma pack(show)
If this is indeed the problem then you'll search where and how it's set
|
|
|
|
|
Nice I didn't know a show option existed, that will get added to my Compiler support diagnostics, thanks
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
To guard against issues like that where the size of objects REALLY mattered, I've always used a static_assert [^] to express static constraints like that:
protected:
_tChar* m_p;
struct sHeader
{
unsigned short usAlloc;
unsigned short usLen;
};
static_assert(sizeof(sHeader) == 4, "sHeader is an unexpected size!");
struct sFooter
{
unsigned short usRefCount;
};
virtual unsigned short HeaderByteSize( void ) const
{
return sizeof( sHeader );
}
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
CodeProject MVP for 2010 - who'd'a thunk it!
|
|
|
|
|
A good point, thanks. I have a static_assert and I should be using it.
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
Matthew Faithfull wrote: Now what do I do?
I would start by figuring out what in fact is different in that build.
Might also help to investigate what is actually driving the size difference. Presumably packing, or lack thereof, however there is another option.
|
|
|
|
|
Message Automatically Removed
modified 19-Jul-13 15:02pm.
|
|
|
|
|
I'm not sure if you were showcasing a weird or a wonderful here, because the second method won't perform as expected.
Brisingr Aerowing wrote: public static void RemoveAllBut(this ICollection source, params object[] notRemove)
{
RemoveAllBut<object>(source.OfType<object>().ToArray(), notRemove);
}
|
|
|
|
|
With any decent implementation of ICollection<T> your method will produce an InvalidOperationException with the message: "Collection was modified; enumeration operation may not execute."
You'll need to store the items to remove in a separate list, and remove them outside of any enumeration of the source list:
public static void RemoveAllBut<T>(this ICollection<T> source, params T[] notRemove)
{
var itemsToRemove = source.Except(notRemove).ToList();
itemsToRemove.ForEach(item => source.Remove(item));
}
As Andrew pointed out, your non-generic version won't work. It would need to be:
public static void RemoveAllBut(this IList source, params object[] notRemove)
{
var itemsToRemove = source.Cast<object>().Except(notRemove).ToList();
itemsToRemove.ForEach(source.Remove);
}
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
At least in .NET 3.5, your first function will throw an exception, since you are modifying the collection being enumerated.
Software Zen: delete this;
|
|
|
|
|
In addition to the comments above, each of those Remove statements will incur an array copy cost. Count the occurrence of each item in notRemove, clear the collection, then add the items in notRemove by their respective counts.
Possibly something like this:
public static void RemoveAllBut<T>(this ICollection<T> source, params T[] notRemove)
{
Int32[] counts = new Int32[notRemove.Length];
EqualityComparer<T> comparer = EqualityComparer<T>.Default;
foreach (T itm in source)
{
for (Int32 i = 0; i <= counts.Length - 1; i++)
{
if (comparer.Equals(notRemove[i], itm))
{
counts[i] += 1;
break;
}
}
}
source.Clear();
for (Int32 i = 0; i <= counts.Length - 1; i++)
{
for (Int32 j = 1; j <= counts[i]; j++)
{
source.Add(notRemove[i]);
}
}
}
|
|
|
|
|
Posting in this particular forum triggers a find-what-is-bad thinking. Sorry.
1. It's O(n^3) which is not good. Did you consider working on sorted collections? Then it would be just O(n). (more precisely, O(max{n,m})).
Why O(n^3):
1. foreach loop
2. Contains method which searches notRemove
3. Remove(itm) method which has to find index of itm (in worst case, n calls to Equals method) and, if it's an array list, it has to shift all elements by one which makes it even worse.
Besides, I though that you cannot edit a collection inside foreach.
2. I method 2: Why copy all elements to a new array? Without it, it would be memory complexity of Ω(1), in situ operation. Now it's Ω(n) because it allocates a new array in the process.
3. Formatting horror, but maybe it was screwed up during pastying*.
if (notRemove.Contains(itm)) continue;
source.Remove(itm);
Shouldn't it be:
if (notRemove.Contains(itm))
continue;
source.Remove(itm);
IF it is known that all items in notRemoves appear in the source exactly once, then what about:
public static void RemoveAllBut<T>(this ICollection<T> source, params T[] notRemove)
{
source.Clear();
foreach(var x in notRemove)
source.Add(x);
}
which is O(m) and Ω(1).
* -- "pastying" - is it a correct spelling? (derived from a verb "paste").
Greetings - Jacek
|
|
|
|
|
Jacek Gajek wrote: * -- "pastying" - is it a correct spelling? (derived from a verb "paste").
The word you're looking for is "pasting".
However, I like the idea of using "pastying" when referring to anything connected to the Cornish foodstuff[^].
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Thanks. Finally I know it. I didn't write "pasting" because it seemed to be related to "the past" and made no sense to me (or did it?).
Greetings - Jacek
|
|
|
|
|
|
Brisingr Aerowing wrote: Message Automatically Manually Removed
FTFY
|
|
|
|