Managed C++/CLI

16-Dec-07 4:53

Hi,

Sorry, I don't know and I even do not want to know.
Regional settings is where the user, a human being, tells the system his preferences,
a program should never change those. It is up to the user to choose a language, a currency,
a date and time format, etc.

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

Sorry for any delays in replying, I currently don't always get e-mail notifications.

Bit Copying

Jeffrey Walton15-Dec-07 15:21

15-Dec-07 15:21

Hi All,

I've got the following code (it's been abbreviated to simplify the discussion). I'm getting a byte order swap. How do I avoid it? Casting gives no joy, since these are cast to void* by memcpy().

byte ctr[ AES::BLOCKSIZE ];    // AES::BLOCKSIZE = 16
memset( ctr, 0x00, sizeof( ctr ) );

int pos = 12;         // derived at runtime
int t = 0xAABBCCDD;   // derived at runtime
memcpy( &ctr[ pos ], (byte*)&t, sizeof( t ) );

I expect ctr[12]=0xAA, ctr[13]=0xBB, ctr[14]=0xCC, ctr[15]=0xDD. However, it's reversed: ctr[12]=0xDD, ..., ctr[15]=0xAA.

Can anyone explain the behavior? I sure did not expect it.

Jeff

Christian Graus15-Dec-07 15:47

Christian Graus

15-Dec-07 15:47

This does not look like C++/CLI to me. It looks to me like you want the visual C++ forum.

Christian Graus - Microsoft MVP - C++

"also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )

Jeffrey Walton15-Dec-07 15:51

15-Dec-07 15:51

Hi Chrisitan,

Christian Graus wrote:
This does not look like C++/CLI to me.

It's clearly not a Visual C++ question. C++/CLI seems most appropriate. What do you suggest?

Jeff

Jeffrey Walton16-Dec-07 7:32

Re: Bit Copying [modified]

16-Dec-07 7:32

Hi Chrsitian,

My apolgies. Chris did state this is a Managed forum. Hopefully next he will change the name of Visual C++ to C++\Visual C++. That will probably stop the extraneous posts.

Looking at the group layout, the following would probably better align the forums:

C++\STL
ATL\WTL
Managed C++\CLI
Visual C++\MFC

Jeff

Luc Pattyn15-Dec-07 16:18

15-Dec-07 16:18

Hi Jeff,

you must be running on a "little-endian system" (LE) such as an Intel x86; this means values get
stored with their least significant byte at the lowest address.
Other processor families such as PowerPC are "big-endian" )BE) and store the most significant byte
"first", i.e. at the lowest address.

It is just a convention, and yes BE seems the more natural one.

The byte order does not matter much in most circumstances; it does when exchanging data:
- through files, following some convention, so they can be exchanged all around;
- through networks (e.g. Ethernet packets)
- with a specific hardware interface

A byte swap is a costly operation.

The IPAddress class offers some methods that may interest you.

[added]
To swap with your own code, the easiest I could ever figure was using a union between
your type and a byte array (write the type's value, swap the bytes in the array, read the type).
But now some languages don't support that very well (C#, Java).
[/added]

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

Sorry for any delays in replying, I currently don't always get e-mail notifications.

modified on Saturday, December 15, 2007 10:33:56 PM

Jeffrey Walton16-Dec-07 1:59

16-Dec-07 1:59

Hi Luc,

Thanks. What I don't understand is why _both_ sides of the equation do not exhibit the behavior. It seems only the right hand side does.

For example, imagine a world where:

int a, b;
memcpy(&a, &b, sizeof(a));

results in an endian swap. This should be equivalent to

a = b

but it is acting more like

a = ENDIAN_SWAP(b)

Jeff

Luc Pattyn16-Dec-07 4:26

Re: Question about redeclaring header files

16-Dec-07 4:26

Hi Jeff,

memcpy (or code that you would write yourself using two byte pointers that autoincrement)
just moves bytes, one after the other; it does not swap bytes, it does not understand or care
about the meaning of those bytes. It is just a physical operation on memory, as it name implies.
And all is fine as long as the two pointers have the same type.

But then the semantics of your data may kick in:
Multibyte integers need a byte order convention, that is what big and little endianness is about.
If you memcpy using two pointers of different types, you may get a surprise, since now the
first byte of a byte array is the one with index 0, whereas the first byte of an integer may be
the most significant (BE) or the least significant (LE) byte of that integer. And the same holds
true for floats.

So if you suspect memcpy of swapping bytes, you are basically saying that you are:
- mixing pointer types
- running on a little-endian processor
- but in favor of big-endian

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

Sorry for any delays in replying, I currently don't always get e-mail notifications.

User Controls

mikobi15-Dec-07 0:09

mikobi

15-Dec-07 0:09

Dear Sirs,

I Use Splitcontainers in my form

On the right side , I need to add many User control I create.

How can I add it to my Forms manuelly or programmatically

Re: User Controls

Christian Graus15-Dec-07 0:24

Christian Graus

15-Dec-07 0:24

Assuming this is really a C++/CLI question, just add them to the Controls collection of your form.

[Message Deleted]

(Steven Hicks)ⁿ⁺¹14-Dec-07 12:39

(Steven Hicks)ⁿ⁺¹

14-Dec-07 12:39

[Message Deleted]

Christian Graus14-Dec-07 14:48

Christian Graus

14-Dec-07 14:48

It doesn't look to me like this is a managed C++ question, why not try the visual C++ forum ?

Re: [Message Deleted]

Hamid_RT20-Dec-07 2:23

Hamid_RT

20-Dec-07 2:23

Wheres your question?

Class intantiation renders app unresponsive

Dewm Solo14-Dec-07 9:42

Re: Class intantiation renders app unresponsive [modified]

14-Dec-07 9:42

Good afternoon to all,

I have been having this fight with my code since early this morning and I am running short on ideas....real short.

Lets start with the characteristics of the issue.
-On my development station everything is fine. The app is complete and ready to ship actually, once this is resolved.

-On the client station the app becomes unresponsive.

-Since there is nothing...not even a single exception thrown during debugging, I ended up posting MessageBox messages throughout the application to nail down exactly where the problem happens.

-I nailed it down to this. The application uses a DLL that I built. The DLL holds one class. The class is a CFileTemplate that takes a XML file reads it and returns an array. The xml file being a template file for columnsId, field names, data type, and length .....to read a CVS or Excel file.

-------------------------

Ok...lets describe the behavior now. When the application runs the user clicks a button to open an OpenFileDialog object, which returns the path to the template file. When it does so the application creates an instance of my CFileTemplate class. When I do this on the client station the application becomes unresponsive when I click the button to get the file dialog. If I put the instantiation in another method and call that method instead of the instantiation directly, I will see the dialog and use the Ok...and then the application becomes unresponsive.

Basically the method that holds the instantiation becomes unresponsive. Not executed at all!!!

If I comment out the instantiation of the class the method that holds the instantiation runs fine...and the application keeps working....as long as I don't use anything that requires that template file of course. So I assumed the problem was within my DLL

Still I don't understand why it is the method that holds the creation of my object that becomes unresponsive. It should at least run in the method as far as the instantiation, but no....if there is a compiled instantiation line in the method. The whole method is not executed. The call appears in the call stack, but nothing in the methods is executed.

None the less I looked at my DLL and changed the way the constructor works, by leaving variables initialization in there and use an Init() method to start working....basically read the xml file and assimilate its data. Then I put messageboxes in there to see what would happen. Of course on my development machine I see everything...all the messages....everything is executed and I see no problem.

On the client machine though, if I instantiate the object, the whole method that holds the instantiation is skipped and the app becomes unresponsive. Therefore my ctor is never called....therefore I do not get to see any of my messages.....hence I don't know what is going wrong.

This whole behavior and non stepping in the method is driving me out of my mind. The whole behavior beats me.....Instantiation of a class, even flawed class, wouldn't affect execution of the instructions that come before it. Why would the whole method that holds the instantiation become unresponsive????

Does this kind of behavior means anything to anyone? Is there anything I can do to figure out what is going? If you want snippets, ask and I'll post. I am even ready to send some code if required, because this is mind blowing. I have been thinking about my first article on here for a while. I guess I just found a good idea, once I figure this out.

Edit: Everything .Net 2.0. All stations, dev and clients, are WinXP SP2. The DLL only has .Net dependencies, mainly System, System.Xml, System.Windows.Forms

Dewm Solo - Managed C++ Developer

Luc Pattyn14-Dec-07 10:24

14-Dec-07 10:24

Hi,

some ideas:

1.
is there any static code in your class? i.e. code that needs to execute as soon as the class
gets loaded (because somewhere else a method gets JIT-compiled that will eventually need something
from your class). Your static ~~class~~ code may either take a long time to complete,
or fail all together,
even before you actually ask it to do something for you. Inserting one more method may alleviate
(or just delay) the problem, since the new method will be looked up but not yet JIT-compiled
until it is needed for execution.

2.
exceptions that occur in a constructor or in another thread may go unnoticed, unless you
implement a try-catch construct in the constructor; of course in the catch you should output
as much information as possible, at least Exception.ToString().

3.
I guess 2 also holds true for any static code in a class.

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

Sorry for any delays in replying, I currently don't always get e-mail notifications.

modified on Friday, December 14, 2007 4:49:28 PM

Dewm Solo14-Dec-07 10:36

14-Dec-07 10:36

1. This class does 3 things.
-Instantiate itself by saving the path for the file
-Read through the file and assimilate the template
-Return the template array

I didn't want to have to call the reading part. I wanted to initialize and return the template when asked. So the ReturnTemplate() method is public, but the ReadFile() method is private. ReadFile() is called in the ctor as you said. For test purposes I will make it public and call it from my application after initialization of the class. If it does initialize at that point.

2 & 3. When trying to figure out what was going on I did insert try-catch constructs everywhere. In the calling method, in the ctor, in the ReadFile() method, ......everwhere....nothing gets intercepted...nothing, nothing, nothing.

I will go change the ctor and make that read method public right now. I will post back my findings within the next minutes.

Dewm Solo - Managed C++ Developer

Dewm Solo14-Dec-07 10:50

14-Dec-07 10:50

Well I'm almost beat....I changed the way it works like I said I would. So now the ctor does nothing but save that path until the read method is called.

Yet instantiating this class still makes the application stop responding. Just as a reminder....only on client stations. On a dev station no problem.

Class Declaration:

<br />
typedef cli::array< cli::array<string^>^ > TemplateArray;<br />
<br />
	public ref class CFileTemplate{<br />
		//ctor and dtor<br />
	public:<br />
		CFileTemplate(String^ sPath);<br />
		~CFileTemplate();<br />
<br />
		//members<br />
	private:<br />
		String^ m_FilePath;<br />
		TemplateArray^ arrCurrentTemplate;<br />
	public:<br />
<br />
		//methods<br />
	public: //private: ->Changed for test purposes...<br />
		void Process();<br />
	public:<br />
		void SwitchTemplate(String^ sPath);<br />
		TemplateArray^ ReturnFormat();<br />
<br />
<br />
	};<br />
</string^>

The class' ctor:

<br />
CFileTemplate::CFileTemplate(String^ sPath) : m_FilePath(sPath)<br />
{<br />
	MessageBox::Show("ctor");<br />
}<br />

In the main application, here is the call:

<br />
private: System::Void button1_Click(System::Object^  sender, System::EventArgs^  e) {<br />
        String^ myStream;<br />
<br />
	MessageBox::Show("Opening dialog");<br />
	if ( this->openFileDialog1->ShowDialog() == System::Windows::Forms::DialogResult::OK )<br />
	{<br />
		MessageBox::Show("Making sure the stream is not empty");<br />
		if ( (myStream = this->openFileDialog1->FileName) != nullptr )<br />
		{<br />
			MessageBox::Show("Instiating the file template object");<br />
			this->aTemplate = gcnew MFG::CFileTemplate(myStream->ToString()); //THIS IS THE CULPRIT.<br />
			MessageBox::Show("instance created");<br />
		}<br />
	}<br />
}<br />

Ok....to complete the explanation.....like this I never get to see the file dialog....nothing gets executed in the click event.

BUT!!!!!!!!!!

If I comment the line that instantiates the class.....everything goes fine. Except I cannot call the read method of course...the thing isn't instantiated.

Dewm Solo - Managed C++ Developer

Luc Pattyn14-Dec-07 11:14

14-Dec-07 11:14

Hi,

I'm not fluent in C++ (doing almost everything in C#) so I may miss the obvious.

I see no static code in your class, except for the fact that it refers to a generic array,
for which it needs to assemble the code. So I would suggest you try again without the line
TemplateArray^ arrCurrentTemplate;, it is my guess that line (or more likely the
typedef it uses) is the culpritt somehow.

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

Sorry for any delays in replying, I currently don't always get e-mail notifications.

Dewm Solo14-Dec-07 11:20

14-Dec-07 11:20

Removed it and compensated with the appropriate array.....

Still...same problem!!!!

Dewm Solo - Managed C++ Developer

Luc Pattyn14-Dec-07 11:34

14-Dec-07 11:34

OK,

in the mean time I'm puzzled by the line CFileTemplate::CFileTemplate(String^ sPath) : m_FilePath(sPath)
which seems to indicate inheritance although the class declaration itself did not have any.
Anyway m_FilePath is not a type, it is a member Confused | :confused:

Luc Pattyn [Forum Guidelines] [My Articles]

Sorry for any delays in replying, I currently don't always get e-mail notifications.

Mark Salsbery14-Dec-07 11:41

Mark Salsbery

14-Dec-07 11:41

Luc Pattyn wrote:
I'm puzzled by the line CFileTemplate::CFileTemplate(String^ sPath) : m_FilePath(sPath)

Hi Luc!

After the colon is the initializer list Smile | :)

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Luc Pattyn14-Dec-07 12:05

14-Dec-07 12:05

Hi Mark,

thanks for reminding me. I knew once, but forgot again.
Anyway the OP is in good hands now. Cool | :cool:

Luc Pattyn [Forum Guidelines] [My Articles]

Sorry for any delays in replying, I currently don't always get e-mail notifications.