16 layers of ifs, Who dare challenge this?

kingsimba0511

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
				}//for
			}//if


			// encoder founded now goes to properties
			if (fIsClsFounded)
			{
				PropertyItem pi;

				// add latitude
				{
					// add longitude
					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 = pImageDecode

Malli_S

:omg: wasn't he aware of

return false

statement? Might wanna to stick with "single entry-single exit" type of function coding..... :-\

[Delegates] [Virtual Desktop] [Tray Me !]
-Malli...! :rose:****

gri

"return false" alone might not help, a CComPtr (was that the name? never did mfc..) would also be useful ;)

Dalek Dave

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

mav northwind

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...

Malli_S

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). :~

[Delegates] [Virtual Desktop] [Tray Me !]
-Malli...! :rose:****

jayart

I somehow do not appreciate the "single return" coding rule.

John M Drescher

I generally follow the single return style but if it is this complex I would have broken the function into smaller parts.

John

PIEBALDconsult

Yes, exactly.

Chris Maunder

Even so, it's easy enough to do something along the lines of:

success = Operation()

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

Luc Pattyn

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 [Forum Guidelines] [My Articles]

Good riddance W

PIEBALDconsult

Luc Pattyn wrote:

belongs in the horror section

Yes, as mentioned the last time it was brought up.

Phil J Pearson

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.

Chris Maunder

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

Chris Maunder

:D I said is was pretty or would not cause gagging.

cheers, Chris Maunder

CodeProject.com : C++ MVP

supercat9

Sorry Chris, but that second option is just a 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).

Mohammad Dayyan

kingsimba0511 wrote:

I hope you have a 22 inch above screen.

I don't have it :(

PIEBALDconsult

And it fits my 20" monitor just fine. Even with the 8-SPACE indenting and large font.

Dan Neely

kingsimba0511 wrote:

I hope you have a 22 inch above screen.

It's not the diagonal, it's the resolution. That fits comfortably on my 18" 1600x1200 CRT. I suspect it would fit on my 1400px wide laptop LCD as well.

Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall

Mohammad Dayyan

I have 17" monitor :-\