|
i'm saying that silly array-of-one hack doesn't do it for you. there's nothing 'dynamic' about the array of one. you still have to go and malloc the memory explicitly.
|
|
|
|
|
|
guess what, words have synonyms.
you know, like when you started using the word "dynamic" to describe what i and the OP were calling "variable length"
|
|
|
|
|
Chris Losinger wrote: guess what, words have synonyms.
Guess what... I said "thus dynamic by most definitions".
Chris Losinger wrote: you know, like when you started using the word "dynamic" to describe what i and
the OP were calling "variable length"
My usage of that word is a commonly known term for that. As the links that I posted demonstrate.
|
|
|
|
|
you changed the subject. i didn't follow your lead. hence your confusion.
|
|
|
|
|
Chris Losinger wrote: you changed the subject. i didn't follow your lead. hence your confusion.
No confusion on my part.
My first post was in response to your post in which you implicitly suggested that it wasn't possible to create an array in C/C++ at run time.
And then you decided to apply a non-standard definition to the word "dynamic".
|
|
|
|
|
Calling it an idiom may be misleading - it may be commonly used, but it is most certainly not a recommended practice, and technically not even supported by the standard. Moreover, while it probably works (depending on the strictness of the compiler) in C++, there are much better ways to create dynamic arrays. In fact you have to look no further than std::vector .
In any case, you have to be very careful about allocating and deallocating your structs in exactly the right way. In C++ you could write your own constructor and destructor, but in C it's easy to mess it up, and the compiler won't notice because you actively worked around it.
P.S.: you can certainly use that construct dynamically, but it's also possible to define an instance of that type on the stack instead if you know the required size at compile time. All you need is a sufficiently large char array, and then assign your struct pointer to the start of that array.
|
|
|
|
|
Stefan_Lang wrote: Calling it an idiom may be misleading - it may be commonly used, but it is most
certainly not a recommended practice, and technically not even supported by the
standard.
First part is an opinion but feel free to substantiate it.
Second part there is nothing in ANSI C prior to C99 that disallows it, and except for unusual uses is in specifically defined. And more than that C99 specifically allows for 'flexible array structure' to explicitly define the behavior. See the following link and search for 'flexible' (and note that that that compiler actually extends the support for the type.)
http://pic.dhe.ibm.com/infocenter/lnxpcomp/v121v141/index.jsp?topic=%2Fcom.ibm.xlcpp121.linux.doc%2Flanguage_ref%2Fstrct.html[^]
Stefan_Lang wrote: in C++, there are much better ways to create dynamic arrays. In fact you have
to look no further than std::vector .
Yep - in C++. But not in C.
Stefan_Lang wrote: In any case, you have to be very careful about allocating and deallocating
Yes. Just as you must be careful about anything involving pointers and memory in C/C++. But that doesn't have anything to do with what I said.
Stefan_Lang wrote: but it's also possible to define an instance of that type on the stack instead
if you know the required size at compile time.
Except that is exactly the point - it isn't known at compile time. And moreover, if it was known at compile time they you could create it dynamically as well.
So what does any of that have to do with creating it dynamically or on the stack?
|
|
|
|
|
jschell wrote: First part is an opinion but feel free to substantiate it.
I have deliberately used "may" because it does indeed reflect an opinion. From a C++ programmers point of view it's terribad. From a C-programmers view it admittedly doesn't look bad at all. It looks like a reasonable workaround to overcome a limitation of the language. However, using such structs breaks expectations, such as
a) that a data structure is always the same size, and that size can be determined using sizeof()
b) that an instance of that data structure looks exactly like defined in the header
c) that you can create instances normally, using alloc(sizeof(mystruct))
You need to make sure that everyone seeing that data structure definition in a header understands that (a), (b), and (c) above no longer hold, and what you are supposed to do instead. This information can only be passed by comments, not via source code, and the compiler has no way of telling whether you're doing it right.
I didn't know that this stuff is actually being supported by some compilers (or at least one?) Thanks for the link - you learn something new every day...
jschell wrote: Just as you must be careful about anything involving pointers and memory in C/C++.
That is not quite the same. See my comments above. Managing pointers and avoiding leaks is easy in comparison, and quite easily managed by a decent set of guidelines.
jschell wrote: <layer>Except that is exactly the point - it isn't known at compile time.
Maybe it isn't. But maybe it is - and that is exactly my point.
An example would be a struct for storing string-based data fields from a database, where each column of a table may have a different size. Generally you'd query the field size before allocating the proper amount of memory for your struct. But when a function references a specific field, then you know at compile time which field that is, and how much memory you need. So you could define a sufficiently large memory block an the stack to store values within that function.
Not saying that this is a good idea: where one programmer might consider 2 characters to be "sufficient" to store a year entry, others accessing the same struct might expect 4 characters. Enter the Y2K crisis! 
|
|
|
|
|
Stefan_Lang wrote: From a C++ programmers point of view it's terribad
In general I would agree with that statement.
Stefan_Lang wrote: However, using such structs breaks expectations...,
I would expect that at experienced C developer would be familar with the idiom and thus would adjust their expectations accordingly.
Stefan_Lang wrote: This information can only be passed by comments
Myself I would indeed comment it. But in my experience I comment code much more than almost everyone else. I have in fact never worked with anyone that comments code as rigorously as I do.
Stefan_Lang wrote: not via source code, and the compiler has no way of telling whether you're doing
it right.
Actually the source code, as per many other idioms, is in fact a method of learning how it works. And often the only way for many idioms regardless of how apt they are or not.
And for C there are many things that the compiler can't check.
Stefan_Lang wrote: Managing pointers and avoiding leaks is easy in comparison, and quite easily
managed by a decent set of guidelines.
Myself I find using the idiom easy. There are far more complicated things in C such as building deep data hierarchies dynamically.
Stefan_Lang wrote: So you could define a sufficiently large memory block an the stack to store
values within that function.
Your description is not that clear but best I can tell it is not an apt use for this idiom. Incorrect usage does not of course invalidate the idiom itself.
|
|
|
|
|
This will just lead to program crashes, incorrect results and other strange happenings. You must not write into memory that you have not allocated in advance. If you already have the data in memory chReadData then all you need to do is set a pointer to that data which is of the structure type, like:
struct MessagData
{
DWORD dwSize;
BYTE byData[1];
}
char chReadData[100];
MessagData* pMessagData = reinterpret_cast<MessagData*>(chReadData);
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
first of all I would like to mention that pointer to structure contains two variables 1. size of data and 2.Byte array to store the data. So following line is not applicable here
MessagData* pMessagData = reinterpret_cast<messagdata*>(chReadData);
Second thing i have to assign this data along with size means structure to some out pointer of same data type.that is why I have used memcpy.but after assigning it to out pointer i m trying to delete this memory(which I have assigned here as shown in code.
And i would like to add one more thing in my question
I have made a queue as shown below
std::queue<messagdata*> qDataQueue;
initially I am pushing the structure pointer in one thread after filling the data as shown below
MessagData* pdata = new MessagData;
//read data is filled in pData
qDataQueue.push(pData)
Then in other thread i am poppin out this data in a pointer of same structure type and trying to delete that pointer then it is showing the mentioned error:
MessagData* pTempdata = qDataQueue.front();
//problem occurs in following line
delete pTempdata;
|
|
|
|
|
Rahul from Poona wrote: So following line is not applicable here
I had mis-read your question, and assumed that the data was presented in that format. In your original question you do not specify how you get the value of dwSize, but assuming you have some way of finding it then you need to do something like:
struct MessagData
{
DWORD dwSize;
BYTE byData[1];
}
char chReadData[100];
int dwNumberRead;
MessagData* pMessagData = (MessagData*)new BYTE[sizeof(MessagData) + dwNumberRead];
memcpy(pMessagData->byData, chReadData, dwNumberRead);
pMessagData->dwSize = dwNumberRead;
[edit]Added quick and dirty cast[/edit]
BTW please use the code block and var buttons above to add the correct HTML tags, <pre> or <code> to your code rather than making it bold, as I have done here.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Rahul from Poona wrote: I m reading some data from device whose length I dont know at compile so I made
a structure as of following type to store data
What are you trying to do?
There is a common C idiom which might be applicable for what you are doing and which your structure would support - if you use it correctly.
It however isn't necessarily the best way to do that in all situations.
And as mentioned if you are not very CAREFUL then you can introduce some or all of the following problems.
- Memory leaks
- Crashes caused in any number of ways by pointer bugs.
The standard C idiom for this is found in the following link.
http://c-faq.com/struct/structhack.html[^]
Keep in mind that you must clean this up in the same way that you allocate it.
|
|
|
|
|
Finding crash information using the MAP file in vs2005(MAPINFO/LINES is not available)
|
|
|
|
|
Finding crash information using the MAP file[^]
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
I've used CrashFinder[^]quite successfully with VS2005 and even VS2010.
Good luck.
Karl - WK5M
PP-ASEL-IA (N43CS)
PGP Key: 0xDB02E193
PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193
|
|
|
|
|
Have you got .pdb files? If so forget .map files. If not change how you do things and get them and forget .map files.
Steve
|
|
|
|
|
hi,
i have developed program using MFC in vs2008 and now trying to build single executable file (.exe file) so that it can be used on other PCs. my source file contains both .c and .cpp files. i have tried to compile/build the program in Release mode but getting errors like:
fatal error C1853: 'Release\readtxtfile.pch' precompiled header file is from a previous version of the compiler, or the precompiled header is C++ and you are using it from C (or vice versa)
so i changed the properties of precompiled header from Use Precompiled Header (/Yu) to Create Precompiled Header (/Yc) and now i'm getting errors like:
error C2857: '#include' statement specified with the /Ycstdafx.h command-line option was not found in the source file
can anyone help me in this regard. i.e how to make executable file with source file containing both .c and .cpp files.
Regards
Jawad
modified 10-Sep-12 23:18pm.
|
|
|
|
|
This precompiled header setting isn't a per-project setting. Set it to "Use Precompiled Header" in the project and inherit this setting in all your .c and .cpp files. After this open the properties windows individually for your stdafx.cpp file and set its precompiled header setting to "Create Precompiled Header". The next step is to select all .c files and open the properties window for them and set the precompiled header setting to "Not Using Precompiled Header". Make sure that you don't include stdafx.h in your .c source files.
modified 3-Sep-12 8:20am.
|
|
|
|
|
thank you pasztorpisti for your reply.
i configured my project to release mode from Configuration Manager and did what you earlier suggested. it builds without errors but when i run exe file, one of the serial ports does not open and gives error 0x7B (system error code). it runs fine (both serial ports open) when build in debug mode. any idea what is happening?
Regards
Jawad
modified 5-Sep-12 2:25am.
|
|
|
|
|
That's a bug in your code or one of the libraries you use. 
|
|
|
|
|
sorry, i didn't understand. what kind of bug we are talking about? i didn't understand the reason behind this. can you please tell me why this behavior is happening (i.e running fine in debug mode but in release mode, opens one port and not the other)?
Regards
Jawad
|
|
|
|
|
There are many reasons for a buggy program to behave differently in debug/release mode. For example code optimization can sometimes screw up your code even if its otherwise non-buggy. Fortunately visual C++ is quite safe in this regard so I wouldnt search for something like this. The most dangerous difference between release builds is memory management/allocation. Debug builds use special values to fill up your stack/heap memory areas when they are allocated to detect programming mistakes (like when you try to use uninitialized variables). This fill doesn't happen when you run your program in release mode resulting in different behavior. Another problem is that even if your build is in Release mode the allocated memory is filled with zeros (not the same value as in debug builds) if you start your executable from your ide by debugging it! For this reason sometimes the bug occurs only if you start the exe from outside your IDE and then attach to it with your debugger. I would search for some uninitialized variables/members...
|
|
|
|
|
thak you so much pasztorpisti. that was really helpful
Regards
Jawad
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
