|
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 
|
|
|
|
|
There was no need to remove your message. Your idea was a good one but I am guessing you didn't test it. And with all of the egos on this site (not saying anyone who responded necessarily has one) if you say something wrong or that can be perceived as wrong there are many who jump at the opportunity to attack. Lots of vultures.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
And in this case, most of the posts looked like they were trying to help (except mine ).
|
|
|
|
|
As CM says "Leave the egos at the door"
When the going gets weird the weird turn pro - Hunter S Thompson RIP
|
|
|
|
|
I bumped into this Java code in a project I'm supposed to 'make work correctly'.
Every method in the class works like this. (userBase checks if the user with the given email is allowed to execute the action and then fetched stuff out of the database.)
How many weird things can you spot? It's not hilarious or something, just weird.
public class Controller
{
public User getUserByID(String email, long id) throws Exception
{
final ObjectHolder<User> userHolder = new ObjectHolder();
final AtomicBoolean done = new AtomicBoolean(false);
userBase.handleAction(email, new GetUserByIDAction(), new GetUserByIDActionExecutionDetails(id), new IActionListener<User>()
{
@Override
public void actionFinished(User user) throws Exception
{
synchronized (done)
{
userHolder.set(user);
done.set(true);
done.notifyAll();
}
}
@Override
public void exception(Exception exception) throws Exception
{
synchronized (done)
{
done.set(true);
done.notifyAll();
throw exception;
}
}
});
synchronized (done)
{
while (!done.get()) {
done.wait(100);
}
if (userHolder.get() == null) {
throw new UserNotFoundException(id);
} else {
return userHolder.get();
}
}
}
private class ObjectHolder<T>
{
private T t;
public ObjectHolder(T t)
{
set(t);
}
public void set(T t)
{
this.t = t;
}
public T get()
{
return t;
}
}
}
|
|
|
|
|
WTE does ObjectHolder do? That I can see no value to.
The userBase model is common. You use an execution container to encapsulate permissions etc. The use of an anonymous class is, however, poor work.
Why aren't the methods synchronized, instead of filling the method with a synchronise block? Damned weird, but there may be a reason.
Reality is an illusion caused by a lack of alcohol
"Nagy, you have won the internets." - Keith Barrow
|
|
|
|
|
I guess ObjectHolder is to make the variable assignable from inside the anonymous code as that can only use final variables.
|
|
|
|
|
Yes, i thought that's what it was for.
However, I was more puzzled by:
- The double synchronization of the AtomicBoolean. It is synchronized in the method itself (waiting for it to become true) AND in the listener. Since the method returns, something is smelly.
- The throwing of 2 exceptions (one in the listener and the other in the method)
|
|
|
|
|
I wanted to mention that, the point of an AtomicBoolean is that it doesn't need synchronisation because it's, well, atomic. 
Reality is an illusion caused by a lack of alcohol
"Nagy, you have won the internets." - Keith Barrow
|
|
|
|
|
Nagy Vilmos wrote: I wanted to mention that, the point of an AtomicBoolean is that it doesn't need synchronisation because it's, well, atomic.
The synchronization isn't necessarily for the setting/getting, but for the wait()/notifyAll(). They are using the variable both as a flag and a synchronization object, though it is a little unusual to wait with a relatively short timeout and then loop if you are going to signal the monitor as well.
I personally would have used CountDownLatch or CyclicBarrier.
|
|
|
|
|
brisingr_aerowing@Gryphon-PC $ rake in_the_dough
Raking in the dough
brisingr_aerowing@Gryphon-PC $ make lots_of_money
Making lots_of_money
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
