|
Some of those "snippets" were indeed pasted all over the place ... Imagine my surprise when the original author could not understand why his updates didnt work like it should
|
|
|
|
|
Maybe he should use the "C preprocessor" with his BASIC code.
|
|
|
|
|
Very nice resusable code
Regards,
Sylvester G
sylvester_g_m@yahoo.com
|
|
|
|
|
If txtProvCt.Text = txtProvCtS Then
Else
giUpdate = True
End If
|
|
|
|
|
and not unusual...
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
CPallini wrote: and not unusual...
Queue the Tom Jones soundtrack.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Lol, i used to do that when i first was teaching myself, then i discovered if not.
Posted by The ANZAC
|
|
|
|
|
Ah a VB users snippet, lack of understanding promotes bad coding.
.net is a box of never ending treasures, every day I get find another gem.
|
|
|
|
|
It's one of my coding rules, which is really useful once you get the point :
if(NULL != l_poStrTest)
{
l_poStrTest->Format
( "My code : %d"
, l_nErrorCode
);
}
else
{
}
It's also all about defines :
#define MY_TEST
#ifndef MY_TEST
int l_nSize = GetStringSize(l_poStrText);
#else // MY_TEST
#endif // MY_TEST
By doing so, I write the full structure of the code which is then ready to fill up, and it also helps to keep an eye-track of the execution logic (inequal statement first) so that you don't have to know if the test is about inequality (!= or #ifndef) or equality (== or #ifdef). You just have to spot the upper or lower block of code and see if it is defined/filled or not...
This also force to structure carefully your code and put some air between the lines, instead to write a rock-compact block of code...
Kochise
PS : I often write empty equality code like this
if(NULL != l_poStrTest)
{
l_poStrTest->Format
( "My code : %d"
, l_nErrorCode
);
}
else{}
In Code we trust !
|
|
|
|
|
= is more faster than !=..thats why
Regards,
Sylvester G
sylvester_g_m@yahoo.com
|
|
|
|
|
I was never one for the intricacies of the C preprocessor. On my latest project, apparently (or rather, unfortunately) someone is.
An .h file has a bunch of definitions (real variable names changed to protect the innocent):
statedefs.h:
<br />
makeState(State1, 0x01)<br />
makeState(State2, 0x02)<br />
makeState(State3, 0x03)<br />
Odd, I think, but ok. Then I go look up "makeState". What the... 3 entries? That's not a good sign.
Instance 1:
<br />
#define makeState(NAME, NUM) ST_##NAME## = ##NUM##,<br />
typedef enum {<br />
#include "statedefs.h"<br />
ST_LAST } statetype;<br />
Instance 2:
Embedded in the middle of a function(!)
<br />
#undef makestate<br />
#define makeState(NAME, NUM) somevariable++;<br />
#include "statedefs.h"<br />
Instance 3:
<br />
#define makestate(NAME, NUM) { "ST_"#NAME,0,0},<br />
sometype stateinfo[] =<br />
{<br />
#include "statedefs.h"<br />
}<br />
There are no external programs being used, no weird autogeneration stuff.. the entire set of code is a replacement for:
<br />
enum<br />
{<br />
ST_State1 = 1,<br />
ST_State2 = 2,<br />
ST_State3 = 3,<br />
<br />
ST_LAST<br />
}<br />
Most editors I've tried cannot tag it, due to the preprocessor concatenation used ("##" in instance 1). References don't work either. And this is one of the easier to read examples of preprocessor abuse...
I just try and remind myself that code written this way makes it that much easier on my next job interview!
|
|
|
|
|
#define makeState(NAME, NUM) ST_##NAME## = ##NUM##, 
To add insult to, well, insult - he only needed the first ##. Maybe he thought the macro params needed to be "quoted" with ## ?
|
|
|
|
|
That's somebody trying to be clever just to show off. I'm a great believer in the KISS principle, and this person deserves to be severely slapped with a wet haddock.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Pete O`Hanlon wrote: KISS
Yeah I wish people would remember that...dangit!
CleaKO
"I think you'll be okay here, they have a thin candy shell. 'Surprised you didn't know that.'" - Tommy (Tommy Boy)
"Fill it up again! Fill it up again! Once it hits your lips, it's so good!" - Frank the Tank (Old School)
|
|
|
|
|
KISS -
1) Lots of small, primitive working components that perform a specific task and clip together?
2) Few large complex classes?
Which one?
[Edit: Typo - Simple = Complex in 2nd option]
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
You got something here! At a certain point, complexity can be moved around between "participants", but it remains in the project.
"clipping components together" can increase complexity by one (thinking on a logarithmic scale)
If your target is, however, still two or three orders of complexity away, you are in trouble. I think the idea is to plug together the next layer's "small, primitive classes" from the layer below. However, plugging components may give you the robustness of an application, but components have much higher requirements to be pluggable. At each layer, you spend more and more glue code to fit things together.
It helps to start with a "more skilled", higher level language (i.e. start at higher complexity already, so the gap gets smaller), or apply KISS to the project goals (but that's not always possible).
Hmmm... no solution, nope.
|
|
|
|
|
From my experience, combining the smallest atomic parts together to create another simple atomic part is simply part of good system design. I've encountered HUGE function classes which have masses of dependancies on other stuff and it's a complete nightmare to figure out.
At least with lots of small components you can black box at each level and the whole system becomes that much simpler to comprehend.
T
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
Complexity does not necessarily contradict the KISS principle. Many problems are complex, but the constituent parts to the solution should be as simple as possible to solve the problem.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
somestateinfo gives you literal strings for the names, so it's a replacement for:
enum
{
ST_State1 = 1,
ST_State2 = 2,
ST_State3 = 3,
ST_LAST
}
sometype stateinfo[] =
{
{ "ST_State1", 0, 0 },
{ "ST_State2", 0, 0 },
{ "ST_State2", 0, 0 },
}
If he'd used, say, #define makestate(NAME, NUM) { "ST_"#NAME,NUM,0},
you could derive a name-value mapping for enums. It could even remove a prefix from the enum constant.
The "inside a function" counts the values actually defined, which would be better derived from sizeof(stateinfo)/sizeof(stateinfo[0])
Not that I ever endorse such conding practices 
But it's a not-to-unusual way around lack of reflection in C / C++.
|
|
|
|
|
I'm just trying to figure out how I'd do this.
I never liked having an enum and a separate string array that had to be kept in sync.
I learned some more about the "C preprocessor" today.
More reason to like C#
|
|
|
|
|
I think the best thing would be an Excel sheet (or similar) and a code generator that is included in the build process.
|
|
|
|
|
I'm now pondering storing the values in XML and using XSLT to create the h file.
XSLT: the new C Preprocessor
|
|
|
|
|
that'd be worthy of a fresh thread here in and of itself.
--
CleaKO The sad part about this instance is that none of the users ever said anything [about the problem].
Pete O`Hanlon Doesn't that just tell you everything you need to know about users?
|
|
|
|
|
Correct you are, but should I? Or should it go in, perhaps, the XML/XSL forum? Or an article?
Aw heck, here it is, you decide:
state.xml
<state Prefix="ST_" Type="sometype" >
<State1>0x01</State1>
<State2>0x02</State2>
<State3>0x03</State3>
</state>
state.xsl
<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" >
<xsl:output omit-xml-declaration="yes" method="text"/>
<xsl:template match="/">
<xsl:for-each select="*">
typedef enum {
<xsl:for-each select="*">
<xsl:value-of select="../@Prefix"/><xsl:value-of select="name()"/>=<xsl:value-of select="."/>,
<xsl:if test="position()=last()"><xsl:value-of select="../@Prefix"/>LAST=<xsl:value-of select="last()"/></xsl:if>
</xsl:for-each>} <xsl:value-of select="name()"/>type ;
<xsl:value-of select="@Type"/><xsl:text> </xsl:text><xsl:value-of select="name()"/>info[] = {
<xsl:for-each select="*">
<xsl:if test="position()!=1">,</xsl:if>{"<xsl:value-of select="../@Prefix"/><xsl:value-of select="name()"/>",0,0}
</xsl:for-each>}
</xsl:for-each>
</xsl:template>
</xsl:stylesheet>
result
typedef enum {
ST_State1=0x01,
ST_State2=0x02,
ST_State3=0x03,
ST_LAST=3} statetype ;
sometype stateinfo[] = {
{"ST_State1",0,0}
,{"ST_State2",0,0}
,{"ST_State3",0,0}
}
As mentioned elsewhere, the counting of the entries in part two is unnecessary, but notice that here I set the value of ST_LAST to the number of entries.
|
|
|
|
|
I call a WTF!
--
CleaKO The sad part about this instance is that none of the users ever said anything [about the problem].
Pete O`Hanlon Doesn't that just tell you everything you need to know about users?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
