C / C++ / MFC

User 5838522-Jul-07 18:02

User 583852

2-Jul-07 18:02

Jeremy Falcon wrote:
if you don't hold it against me for sneaking the occasional macro or two in some code when you're not looking.

Its a long piece of rope, you do what you like with it

Stephen Hewitt2-Jul-07 17:24

2-Jul-07 17:24

No, I'm not missing the point. Perhaps you can explain the advantages of macros over inline functions? There are some things inline functions can't do like stringisation and token pasting and such; but when inline functions can be used they're a better solution for many reasons including the following:
- Type safety.
- Automatically disabled in debug builds to aid debugging.
- Can use multiline constructs without having to end each line with a "\".
- Can be put into namespaces!
- Can be members of classes and structs!
- Can be overloaded!
.
.
.

Steve

Jeremy Falcon2-Jul-07 17:33

2-Jul-07 17:33

Stephen Hewitt wrote:
Perhaps you can explain the advantages of macros over inline functions?

Perhaps you can read my posts and find the answer there already seeing as I said it more than once.

Stephen Hewitt wrote:
- Type safety.

Addressed twice. The type safety you refer to isn't a real issue since a macro expands to type safe code.

Stephen Hewitt wrote:
- Automatically disabled in debug builds to aid debugging.

And like typing #ifdef _DEBUG will break your arm.

Stephen Hewitt wrote:
- Can use multiline constructs without having to end each line with a "\".

You know you're reaching deep when you have syntax as reasoning. Laugh | :laugh:

Stephen Hewitt wrote:
- Can be put into namespaces!
- Can be members of classes and structs.
- Can be overloaded.

Actually these are very good points, but it doesn't really mean inline functions should always be used in place of macros as you suggest. Besides, this has contradicting logic. I mean, why write an inline function... usually for speed right? Using the second two of your three points quoted would effectively break that anyway.

Jeremy Falcon
"It's a good thing to do and a tasty way to do it." - Wilford Brimley[^]

Stephen Hewitt2-Jul-07 17:48

2-Jul-07 17:48

No one says macros should never be used, just that they shouldn’t be used when other superior constructs exist for the same task; the specific example in this case is that macros should not be used as inline functions. I have constantly argued the point, complete with examples and data (compiler output) to support my claims; while you seem intent on arguing the person and accusing people of missing the point. Well I've had my say and I'll let my comments speak for themselves.

Steve

Jeremy Falcon2-Jul-07 17:54

2-Jul-07 17:54

Stephen Hewitt wrote:
No one says macros should never be used, just that they shouldn’t be use when other superior constructs exist for the same task; the specific example in this case is that macros should not be used as inline functions.

I'm sorry you don't understand context - my bad. I'll have to remember that next time I write something.

Stephen Hewitt wrote:
I have constantly argued the point, complete with examples and data (compiler output) to support my claims;

And that makes you correct how?

Stephen Hewitt wrote:
while you seem intent on arguing the person and accusing people of missing the point. Well I've had my say and I'll let my comments speak for themselves.

Fair enough, but don't accuse me of what you did, and that is to argue a point I never spoke against. Have a nice day.

Jeremy Falcon
"It's a good thing to do and a tasty way to do it." - Wilford Brimley[^]

Jeremy Falcon2-Jul-07 17:56

2-Jul-07 17:56

Stephen Hewitt wrote:
No one says macros should never be used, just that they shouldn’t be use when other superior constructs exist for the same task; the specific example in this case is that macros should not be used as inline functions.

Actually, I just reread what I said. I did mention inline functions. Perhaps you should bother reading my posts... oh wait.

Jeremy Falcon
"It's a good thing to do and a tasty way to do it." - Wilford Brimley[^]

Jeremy Falcon2-Jul-07 17:46

2-Jul-07 17:46

Stephen Hewitt wrote:
- Can be members of classes and structs!
- Can be overloaded!

Now that I think about it, that extra cost my be placed on the compile time rather than the run time. But alas, I'm too lazy and and it's getting too late for me to look into it.

Jeremy Falcon
"It's a good thing to do and a tasty way to do it." - Wilford Brimley[^]

Christian Graus2-Jul-07 17:08

Christian Graus

2-Jul-07 17:08

inline is the standout, it's different to the others.

inline is a *suggestion* to the compiler that this function is so simple, that it's more efficient to write the code for this function in the places where it's called, instead of paying the cost of a call to another memory address to run it. The vital thing to understand is that hte compiler is both free to inline things itself, and to decide you're wrong and *not* inline the function.

Christian Graus - Microsoft MVP - C++

"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )

Jeremy Falcon2-Jul-07 17:35

2-Jul-07 17:35

Christian Graus wrote:
inline is a *suggestion* to the compiler that this function is so simple

I hate to use your post, but that's a great reason I forgot. There is no real guarantee inline will even work. You're guaranteed to have inline expansion with macros though.

Man, old age is getting to me. Blush | :O

Jeremy Falcon
"It's a good thing to do and a tasty way to do it." - Wilford Brimley[^]

Stephen Hewitt2-Jul-07 18:11

2-Jul-07 18:11

The only times I've seen MSVC ignore an inline directive is when its had no choice such as with recursive functions: in this context this is a feature.

Steve

Jeremy Falcon2-Jul-07 18:14

2-Jul-07 18:14

Stephen Hewitt wrote:
The only times I've seen MSVC ignore an inline directive is when its had no choice such as with recursive functions: in this context this is a feature.

And MSVC is the only compiler in existence too.

Jeremy Falcon
"It's a good thing to do and a tasty way to do it." - Wilford Brimley[^]

Stephen Hewitt2-Jul-07 18:22

2-Jul-07 18:22

No, it isn't. Until recently it was one of the worst (MSVC 6) in common use. I have inspected the machine code generated by MSVC 6 (I do a lot of postmortem debugging at work) and the inlining works as expected except when that’s not possible, as I mentioned before. The Microsoft compilers after MSVC 6 produce even better code from what I’ve seen. All modern C++ compiler support inlining just fine.

Steve

User 5838522-Jul-07 18:25

User 583852

2-Jul-07 18:25

And some even inline code without you asking for it if the optimisation is set right Smile | :)

Stephen Hewitt2-Jul-07 18:29

2-Jul-07 18:29

On MSVC this can be controlled with the /Ob[^] compiler switch.

Steve

Jeremy Falcon2-Jul-07 18:37

2-Jul-07 18:37

Stephen Hewitt wrote:
Until recently it was one of the worst (MSVC 6) in common use. I have inspected the machine code generated by MSVC 6 (I do a lot of postmortem debugging at work) and the inlining works as expected except when that’s not possible, as I mentioned before. The Microsoft compilers after MSVC 6 produce even better code from what I’ve seen.

And you just felt the need to say this right? I don't really see how this has anything to do with the point that was quoted - which I'm sure you could've guessed is sarcasm.

Stephen Hewitt wrote:
All modern C++ compiler support inlining just fine.

Nice blanket statement there. Notice the extra little comments in these links that have nothing to do with recursion.

http://gcc.gnu.org/onlinedocs/gcc/Inline.html[^]
http://www.osc.edu/hpc/manuals/ia64/docs2/c_ug_lnx.pdf[^]

I don't know about you, but it seems easier to me to just use a macro rather than learn all the quirks of every compiler in the world.

Jeremy Falcon
"It's a good thing to do and a tasty way to do it." - Wilford Brimley[^]

Effect Class

Force Code2-Jul-07 11:30

Force Code

2-Jul-07 11:30

The GDI+ documentation describes the Effect Class and numerous subclasses of it (HueSaturationLightness, Tint, ColorBalance, Blur, etc.) I can't find these in any of the GDI+ header files downloaded as part of the PlatformSDK from Microsoft. Also, they don't even appear to be in gdiplus.dll. Does anyone know the header files and dll they're in.

Thanx

Perspx2-Jul-07 11:34

2-Jul-07 11:34

They should be in gdiplus.dll.. Check that you have the latest version.. I know that GDI+ is fully supported in Visual Studio so you could use that if you have access to that? I'm not sure if it's supported in the Express versions, if it is you could try using Visual C++ express free from MS

Hope this helps!
--PerspX

Force Code2-Jul-07 11:43

Force Code

2-Jul-07 11:43

Do you know which header files they're declared in?

Perspx2-Jul-07 11:53

2-Jul-07 11:53

Well the main header file for GDI+ is obviously gdiplus.h. There are then other GDI+ header files which are used, however I believe that they are all included from gdiplus.h anyway, so that shouldn't be a problem.. What happens at compile time with your project?

Hope this helps!
--PerspX

Force Code2-Jul-07 12:24

Force Code

2-Jul-07 12:24

Perspx wrote:
Well the main header file for GDI+ is obviously gdiplus.h. There are then other GDI+ header files which are used, however I believe that they are all included from gdiplus.h anyway, so that shouldn't be a problem.. What happens at compile time with your project?

The compiler's not finding the declarations (compiler error). I'm using Dev-C++ as a compiler (mingw - its gnu or something). I downloaded the PlatformSDK a couple of weeks ago, and have compiled and ran GDI+ code using The Bitmap, Font, and TextureBrush classes, etc. with no problem. I have numerous GDI+ headers, none of them contain the Effect classes. If you can do a "Find in File HueSaturationLightness *.h", I'd appreciate it.

Perspx2-Jul-07 21:59

2-Jul-07 21:59

Hmm.. It is pretty odd.. I have looked through the VS header files and there doesn't appear to be any reference to any of the effects classes as previously mentioned (I am using VS 2005 Professional). I have used GDI+ on several occasions, but I have not used any of the effects classes.

I'm very sorry I cannot help you any further.

--PerspX

Mark Salsbery2-Jul-07 12:32

Mark Salsbery

2-Jul-07 12:32

GDI+ is included with the operating system, not a part of Visual Studio.

As stated by Perspx, according to the docs for the Effect class: "Declared in Gdipluseffects.h, include gdiplus.h"

Mark

Mark Salsbery
Microsoft MVP - Visual C++

Perspx2-Jul-07 22:01

2-Jul-07 22:01

Odd.. my copy of Visual Studio doesn't seem to have Gdipluseffects.dll :S sorry about that.. I would have been able to help you sooner otherwise.. Thanks for clearing that up Mark Smile | :)

--PerspX