|
uncertain = uncertian I'm affraid that Jessica could change a volatile value of the uncertian even during the '= ' symbol.
Greetings - Gajatko
Portable.NET is part of DotGNU, a project to build a complete Free Software replacement for .NET - a system that truly belongs to the developers.
|
|
|
|
|
So there's absolutely nothing you can do -
this code IS dangerous and stays dangerous .
-- Or is it Jessica who is dangerous...
www.thomas-weller.de
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. Programmer - an organism that turns coffee into software.
|
|
|
|
|
If "foo" is volatile, the statement "if (foo == foo) bar();" must read the value of foo exactly twice and compare the two values read. If "foo" happens to be an address in normal RAM, the two reads would be most likely read the same data unless an interrupt or task switch happened to occur between them (not terribly likely). Not everything in a processor-based system is RAM, however. When a typical flash memory chip is performing a write cycle, consecutive read operations are guaranteed to return different data. If the generated code for the above 'if' statement didn't read 'foo' twice, the 'if' test would succeed even while the flash was still being written.
|
|
|
|
|
Thanks for that - wasn't totally sure about it from the top of my head...
www.thomas-weller.de
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. Programmer - an organism that turns coffee into software.
|
|
|
|
|
hey, if would b gr8 if u could explain wat u mean by variable being volatile
Ravie Busie
Coding is my birth-right and bugs are part of feature my code has!
|
|
|
|
|
hey, if would b gr8 if u could explain wat u mean by variable being volatile
This is not a place for programming questions, but in this context, a 'volatile' variable is one that is marked with the 'volatile' keyword. If a variable is declared volatile, expressions involving that variable may not be optimized. If 'foo' were not volatile, the code (assume foo, bar1, bar2, and bar3 are of type int):
foo = bar1;
bar2 = foo*25;
bar3 = foo*25;
foo = 8;
could be safely replaced with:
bar3 = bar2 = bar1 * 25;
foo = 8;
and indeed some compilers would make such a replacement. If 'foo' were volatile, however, all four of the original statements would have to be performed as-is, in sequence.
|
|
|
|
|
No, an if statement is not guaranteed to be atomic as it can be decomposed into multiple binary instructions, and a task switch can occur between any of those instructions unless the compiler designates the entire sequence as a critical section.
|
|
|
|
|
Some code I encountered yesterday included:
if (string.IsNullOrEmpty(client) || string.IsNullOrEmpty(client))
I think it's just a typo.
|
|
|
|
|
ClementsDan wrote: I think it's just a typo.
In my case the code should be:
if (action == InvalidContentActions.Remove || action == InvalidContentActions.CommentOut)
Greetings - Gajatko
Portable.NET is part of DotGNU, a project to build a complete Free Software replacement for .NET - a system that truly belongs to the developers.
|
|
|
|
|
I hope you have a 22 inch above screen.
bool UpdateImageFileWithGPSPosition(LPCTSTR lpszPictureFilePath, char* lat_lon)
{
LPCTSTR lpszModPictureFilePath = lpszPictureFilePath;
IImagingFactory* pImgFactory = NULL;
IImage* pImage = NULL;
bool fIsClsFounded = false;
GUID guidImageEncoderCls;
HRESULT hr = S_OK;
hr = CoCreateInstance(CLSID_ImagingFactory, NULL, CLSCTX_INPROC_SERVER, IID_IImagingFactory, (void **)&pImgFactory);
if (SUCCEEDED(hr))
{
IStream* pFileStream = CreateStreamByFileName(lpszPictureFilePath);
IImageDecoder* pImageDecoder = 0;
hr = pImgFactory->CreateImageDecoder(pFileStream, DecoderInitFlagNone, &pImageDecoder);
if (SUCCEEDED(hr))
{
ImageInfo imageInfo;
hr = pImageDecoder->GetImageInfo(&imageInfo);
if (SUCCEEDED(hr))
{
UINT nEncodersCount = 0;
ImageCodecInfo* pEncoders = NULL;
hr = pImgFactory->GetInstalledEncoders(&nEncodersCount, &pEncoders);
if (SUCCEEDED(hr))
{
for (UINT i = 0; i < nEncodersCount; i++)
{
if (pEncoders[i].FormatID == imageInfo.RawDataFormat)
{
guidImageEncoderCls = pEncoders[i].Clsid;
fIsClsFounded = true;
break;
}
}
}
if (fIsClsFounded)
{
PropertyItem pi;
{
pi.id = PropertyTagSoftwareUsed;
pi.type = PropertyTagTypeASCII;
pi.length = sizeof(char) * 30;
pi.value = lat_lon;
hr = pImageDecoder->SetPropertyItem(pi);
if (SUCCEEDED(hr))
{
IImageEncoder* pImageEncoder = NULL;
hr = pImgFactory->CreateImageEncoderToFile(
&guidImageEncoderCls,
lpszModPictureFilePath,
&pImageEncoder);
if (SUCCEEDED(hr))
{
IImageSink* pImageSink = NULL;
hr = pImageEncoder->GetEncodeSink(&pImageSink);
if (SUCCEEDED(hr))
{
UINT uiPropertiesCount = 0;
hr = pImageDecoder->GetPropertyCount(&uiPropertiesCount);
if (SUCCEEDED(hr))
{
UINT totalBufferSize = 0;
UINT numProperties = 0;
hr = pImageDecoder->GetPropertySize(&totalBufferSize, &numProperties);
if (SUCCEEDED(hr))
{
PropertyItem* pis = (PropertyItem*)malloc(totalBufferSize);
hr = pImageDecoder->GetAllPropertyItems(
totalBufferSize,
numProperties,
pis);
if (SUCCEEDED(hr))
{
hr = pImageSink->PushPropertyItems(
numProperties,
totalBufferSize,
pis);
if (SUCCEEDED(hr))
{
hr = pImageDecoder->BeginDecode(pImageSink, NULL);
if (SUCCEEDED(hr))
{
while (true)
{
hr = pImageDecoder->Decode();
if (SUCCEEDED(hr))
{
pImageDecoder->EndDecode(hr);
break;
}
else if (FAILED(hr))
{
pImageDecoder->EndDecode(hr);
break;
}
else if (hr == E_PENDING)
{
continue;
}
}
}
}
free(pis);
}
}
}
pImageSink->Release();
}
pImageEncoder->TerminateEncoder();
pImageEncoder->Release();
}
}
}
}
pImageDecoder->Release();
}
}
Stream_release(pFileStream);
pImgFactory->Release();
}
return SUCCEEDED(hr);
}
- Currahee! We stand alone together.
|
|
|
|
|
wasn't he aware of
return false
statement? Might wanna to stick with "single entry-single exit" type of function coding.....
|
|
|
|
|
"return false" alone might not help, a CComPtr (was that the name? never did mfc..) would also be useful
|
|
|
|
|
I commented just by seeing return type of the function. Did't dare to look into 16 layers at all...
As per prototype
bool UpdateImageFileWithGPSPosition(LPCTSTR lpszPictureFilePath, char* lat_lon)
my comment meant the function would return false in case of failure (rather increasing the layers).
|
|
|
|
|
Easier to do specific cases surely?
------------------------------------
"The greatest tragedy in mankind's entire history may be the hijacking of morality by religion"
Arthur C Clarke
|
|
|
|
|
Let me guess - there's a coding rule to use only one return statement per method?
Regards,
mav
--
Black holes are the places where God divided by 0...
|
|
|
|
|
I somehow do not appreciate the "single return" coding rule.
|
|
|
|
|
I generally follow the single return style but if it is this complex I would have broken the function into smaller parts.
John
|
|
|
|
|
|
Even so, it's easy enough to do something along the lines of:
success = Operation()
if (success == TRUE)
{
...
}
if (success == TRUE)
{
...
} etc
or
do {
success = Operation();
if (!success) break;
success = Operation2();
if (!success) break;
...
} while(false)
cheers,
Chris Maunder
CodeProject.com : C++ MVP
|
|
|
|
|
Hi,
the former is what I do, the latter is a bit ugly, it basically is a never looping loop construct, maybe it belongs in the horror section
|
|
|
|
|
Luc Pattyn wrote: belongs in the horror section
Yes, as mentioned the last time it was brought up.
|
|
|
|
|
I agree. The first time I saw the latter in use I had a double take and went 'hang on...' in a very suspicious tone.
No, not recommended, but arguably better than 16 levels of bleah.
cheers,
Chris Maunder
CodeProject.com : C++ MVP
|
|
|
|
|
Sorry Chris, but that second option is just a <hushed_tones>goto </hushed_tones> that avoids using the letters 'g' or 't'.
I know you can do better than that!
Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
|
|
|
|
|
I said is was pretty or would not cause gagging.
cheers,
Chris Maunder
CodeProject.com : C++ MVP
|
|
|
|
|
Sorry Chris, but that second option is just a <hushed_tones>goto that avoids using the letters 'g' or 't'.
The reason GOTO has gotten a bad rap is that it has historically been used without any concept of structured control-flow. Programs are generally easiest to understand if they can be subdivided into nested blocks, such that there are few jumps across block boundaries, and all inter-block jumps are of a few specific forms (e.g. jumping to the start or end of an enclosing block). Consider:
if (condition) goto TRUE_CASE;
FALSE_CASE:
do_false_stuff();
goto END_IF;
TRUE_FASE:
do_true_stuff();
END_IF:
Not quite as nice as using the C block constructs, but not particularly nasty. On the other hand, prior to the invention of structured programming, such code would often have been written as:
if (condition) goto TRUE_CASE;
do_false_stuff;
END_IF:
.. somewhere else in the code ..
TRUE_CASE:
do_true_stuff();
goto END_IF;
The code for the true case would often be placed rather arbitrarily. In assembly code written for some machines, it might be placed before the start of the routine which used it, so as to allow an efficient short-displacement branch. Trying to follow code whose physical arrangement bears no relation to its logical flow is, of course, difficult. The problem, though, isn't the use of GOTO per se but rather the use of control flow that doesn't follow any logical structure.
(nb: I do sometimes write assembly code which is more like the latter than the former, particularly in cases where the 'if' case occurs far less frequently than the 'else' case, and the performance impact of adding an extra branch to the 'else' case would be significant and unacceptable. I don't like such code, but sometimes it is necessary).
|
|
|
|