|
geoffs wrote: A static inline function will be indistinguishable from a macro in terms of the code generated
Not necessarily true. A macro will always be expanded by the preprocessor, and the code compiled as is. An inline function will only be inlined if the compiler thinks it's a good idea (for example it might be if you are optimising for speed, it may not be if you are optimising for size). Don't forget inline is a request to the compiler, not a command. It can leave the code as a function if it wants to.
A macro forces the issue - a function leaves it to the compiler to decide.
|
|
|
|
|
Although this is getting away from the original intent of my posting, you are correct that inline is merely a request to the compiler. For all intensive purposes, in most cases, a simple function as shown will be inlined by the compiler. There will be exceptions to that case.
|
|
|
|
|
That's why I put the smiley.
geoffs wrote: intensive purposes
intents and purposes
|
|
|
|
|
PIEBALDconsult wrote: intents and purposes
Thanks for that correction! 
|
|
|
|
|
WTF !!! macros are gold the end.
|
|
|
|
|
"As it's C++, define a macro."
That's a horror in itself. C++ provides inline functions that would do the same job much better. Indeed, the potential pitfalls of the C preprocessor are one of the main motivations for this feature.
|
|
|
|
|
The language provides that feature?
|
|
|
|
|
How is the static_cast better than a normal cast in this case?
David
|
|
|
|
|
Depends on what you mean by a "normal" cast...
1. If you mean a C-style cast (ie: (uint32) <something> ), then my answer would be that the code is C++ and the correct thing to do is to use the new style casts provided by the C++ language. They are there for a good reason.
2. If you mean, why did I not just allow implicit casting to uint32 by the compiler, it's because assigning a double value to an unsigned long produces a warning message ('possible loss of data') depending on the warning level set for the compilation. Since I compile at the higher warning levels and will see the warning, and have a policy of not allowing warnings from my code, I do the explicit cast.
The issues I touched on above are very well described and explained at this site: C++ FAQ Lite. This is a great site for beginners and seasoned c++ programmers.
|
|
|
|
|
Been refactoring some of my code and stumbled upon this.
string XMLCommand = "<<Command Name=\"DoStuff\" ID=\"";
XMLCommand += ID.ToString();
XMLCommand += "\"/>";
The double << are necessary or the site wouldn't display all code (why actually? It shouldn't be any valid HTML tag).
I know, I should use the proper XML classes but I've been too lazy, especially cause 3 lines below it, I'd need to convert it to a string anyway (to send it with a StreamWriter).
|
|
|
|
|
Yes, for a number of reasons including the concatenation of strings.
I suggest you use something more like
string XMLCommand = string.Format
(
"<<Command Name=\"DoStuff\" ID=\"{0}\"/>"
,
ID
) ;
But that still doesn't explain the extra less-than; you should find out what the problem is.
|
|
|
|
|
PIEBALDconsult wrote: string XMLCommand = string.Format
What is string.Format?
PIEBALDconsult wrote: But that still doesn't explain the extra less-than; you should find out what the problem is.
I explained in in my first post already, it's because CodeProject only displays half the code without it.
s_mon wrote: XmlDocument xmlDocument = new XmlDocument();
xmlDocument.AppendChild = xmlDocument.CreateElement("evil");
I know, I know.
I wrote the code before knowing any XML classes and just been too lazy to change it now.
Also, I don't think it's necessary to create a new XMLDoc and append an element and Attribute just so I'll pass the OuterXml to the send method anyway.
It's quick & dirty but it does it's job and for a single line of XML I think it's ok.
I use the proper classes when building larger XML.
|
|
|
|
|
Ohhh... so that's what you meant by "the site wouldn't display all code", I had assumed you meant some site you were working on.
Try escaping the < with < (which is what the "Auto-encode HTML when pasting?" does.
|
|
|
|
|
Megidolaon wrote: It's quick & dirty but it does it's job and for a single line of XML I think it's ok.
That's what I thought until I was passed some text with values that needed to be encoded.
Like < and & and even a Ctrl-C 
I have since worked up a class to make it easier and hide the details.
|
|
|
|
|
Anything to do with XML is a coding horror 
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
|
|
|
|
|
|
XmlDocument xmlDocument = new XmlDocument();
xmlDocument.AppendChild = xmlDocument.CreateElement("evil");
;o)
(yes|no|maybe)*
|
|
|
|
|
That's evil 
Seriously, that is okay, I've seen worse
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
|
|
|
|
|
Megidolaon wrote:
<big>string</big> <small>XMLCommand = "<<Command Name=\"DoStuff\" ID=\""</small><big>;</big>
<small>XMLCommand</small> <big>+=</big> <small>ID.ToString()</small><big>;</big>
<small>XMLCommand</small> <big>+=</big> <small>"\"/>"</small><big>;</big>
My eyes! The goggles do nothing!
-Spacix
All your skynet questions[ ^] belong to solved
I dislike the black-and-white voting system on questions/answers. 
|
|
|
|
|
Why should it qualify as a horror? Admittedly, the use of strings in that fashion is not terribly efficient, but since they're small and the number of operations is comparatively modest I wouldn't consider the inefficiency particularly objectionable if the code isn't executed too often (if 90% of the time is spent in 10% of the code, it wouldn't matter much if the other 90% of the code were twice as slow as it should be).
My own preference, especially if more parts were being assembled into the string, would be to either use something like a StringBuilder so as to avoid repeated allocations for the different partially-assembled strings, but I don't see anything particularly wrong with the code as given, or else (if using C++ or C#, as opposed to VB) spread one statement over multiple lines. The strings in the above example are short enough that using a simple string type is probably fine, though, and spreading statements over multiple lines isn't particularly aesthetically pleasing.
|
|
|
|
|
I need to read a file from the bottom is it possible in c language ?
The exact requirement is
suppose having a file like
========================================
hi
how are you
exit 1
then
you
exit 1
and i can
make this
exit 0
===========================================
I need to read the file from bottom to search the last exit 1
and print the lines above it
the output will be
then
you
Can anybody help me ??
vineesh
|
|
|
|
|
Yep that's a coding horror.
And by the way of course you can do that in C - try poking around in stdio.h and reading a book or two. Maybe use Google.
I am convinced that lobotomising users will make little to no difference.
|
|
|
|
|
Thats a very special kind of humour. 
Greetings from Germany
|
|
|
|
|
Yes.
R.
T.
F.
M.
I still remember having to write your own code in FORTRAN rather than be a cut and paste merchant being pampered by colour coded Intellisense - ahh proper programming - those were the days 
|
|
|
|
|
No, you have it wrong. He said he needed to read the file from the bottom:
M.
F.
T.
R.
Mostly, when you see programmers, they aren't doing anything. One of the attractive things about programmers is that you cannot tell whether or not they are working simply by looking at them. Very often they're sitting there seemingly drinking coffee and gossiping, or just staring into space. What the programmer is trying to do is get a handle on all the individual and unrelated ideas that are scampering around in his head. (Charles M Strauss)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
