However, networking is still a ridiculous thing to be missing from a modern programming language. I wish they’d just break this off into a separate committee, and get it done relatively quickly. No language changes are going to be needed.

Chance to have Herb Sutter back as chair: even better!

Thanks to P.J. Plauger for all his services.

Algorithm correctness has nothing to do with implementation correctness, and making bugs does not mean incompetence, it’s how well you respond to them that matters. C++ is just so complex that even if you virtually never make an error in logic or design judgement it’s impossible to anticipate all the problems…or at least not the ones you haven’t yet experienced, especially the ones that crop up every time you change your OS, compiler, or team.

I think the problem is people like to try to metaprogram too much. Not so much just with templates and complicated designs so much as programming themselves. Every fad seems to come and go and come again but it’s always an issue of judgement not any algorithm you can follow to ensure you are the perfect coder or designer.

@peirz: True, Concepts isn’t in C++0a because it needs polish. But one of the demonstrations of that need for polish was the GCC implementation. Another problem was that the GCC version stopped being developed, so new ideas for Concepts could not effectively be tested. That’s why they need more time on it.

@Brendan: Networking is not a “no brainer” in terms of design. The need for one is important, but not nearly as important as a standard threading layer. Threads will be far more important in the coming years than having to manually abstract the differences between WinSock and the Linux and MacOS equivalents.

Not every application needs networking. Threading is something that, particularly with multicore coming up, virtually every application of any real size will use.

2009, and they aren’t even *talking* about adding a standard networking library.

struct Validator {
int location;
char contents;
};

static const Validator VALID[] =
{
{0, {‘a’, ‘b’, ‘c’}},
{3, {‘d’, ‘e’}},
{6, {}},
{7, {‘v’, ‘w’, ‘x’, ‘y’, ‘z’}},
};

template inline size_t ARRAY_SIZE(const T (&array)[N])
{
return N;
}

int main(int, char**) {
for (int i = 0; i < ARRAY_SIZE(VALID); i++)
{
cout << "The Contents at location " << VALID[i].location << " are:";
for (int j = 0; j < ARRAY_SIZE(VALID[i].contents; j++)
{
cout << VALID[i].contents[j] << ", ";
}
cout << endl;
}
}

There are good scenarios where you would want 0 length stack based arrays.

Sullivan Web Development

#define UNUSED(x)

is ONLY usable for function formal parameters, and actually it is different “thing”, so UNUSED_PARAM would be better name…

As for omitting unused formal param names – sometimes it is good to leave variable name, for the sake of description, etc..

Thanks.

I think it’s a matter of personal taste or coding style. However, I prefer to not delete parameter names. When you read code with deleted parameter names, you basically have no idea as to WHAT that parameter actually means, thus you have no idea as to WHY it is unused. Maybe it’s ultimately uninteresting for the function, or it’s just not yet supported but must be supported. Moreover, if need that parameter back, you will have to find the name somewhere and retype it.
Sometimes I just comment unused parameters out:

void foo(…., int /*some_flag*/, …) {…}

However that badly cooperates with other multi-line comments – there is no nested multi-line comments.

So I prefer to explicitly mark it as unused, it also provides a good place for comment regarding a reason why it is unused. For example:

inline int rl_WaitForSingleObjectEx(rl_HANDLE obj, unsigned long timeout, int alertable, debug_info_param info)
{
(void)alertable; //not yet supported – support it!
…
}

template
void unused(T&) {}

std::string foo() { return std::string(); }
int bar() { return 0; }

int main()
{
unused(foo());
unused(bar());
}

Why not use
sizeof pb;
Is there a compiler on which this doesn’t quiet the warning?

Before trying it, my guess/expectation is that it would get the same result as just mentioning the variable name (e.g., “pb;”, see earlier comments), because it falls into the same category of using the name in an expression that has no effect. Therefore, whether or not it quiets the original “unused variable” warning, it is likely to generate a new warning saying that the expression has no effect or its result was unused.

Then I tried it, and the result… drum roll please… was: It doesn’t suppress the warning on Borland, and just changes it to “expression has no effect” on EDG. Not exactly the same effect on every compiler as just writing a statement containing only the variable name, but it’s close.

So the solution I posted (and Boost’s identical facility) is still the only technique that works on all the compilers I tried. Any more suggestions of variants to try?

Maybe these are two I would actually vote for:

int a [[unused]];
int f( int a [[unused]] );

more “creatively”:

// Maybe this could cause all calls/side effects to trace (in the following line) to
be ignored but allowing the calls to be left left
in the code when [[unused]] can be removed if required later.

void trace [[unused]] ( int x, int y);

// Maybe this to strip out calls to and creates of trace_logger.
class trace_logger [[unused]] { }

// Getting silly but couldn’t a [[used]] be, er, used too?

// Construction wanted, but no further
// use required so compiler don’t complain
// about unused. At least I think this error sometimes happened back when i Used to use C++ (ho ho).

Object y[[used]](); // Prevent unused error.

// How about?
void used_this [[deprecated("we used to use this but now we use_that instead")]]( int x, y);

I’ve asked this before but I hear MS aren’t implementing c++0x attributes? Is this true? That might be no bad thing thing because they are so overused in .NET (and just see the sillyness above!) but then C++/CLI has single bracket attributes that though I like better will just make for non standard overuse… what was the committee view in not voting for the C++/CLI type attribute?

Others having “fun” with attributes I see:
http://stackoverflow.com/questions/296838/c0x-attributes-youd-like-to-see

(interesting comments too about a plan for a world with no macros and the “travesty” of MS not doing them? I’m not sure it’s a travesty but I would like to know the reasoning or if true or not.

1. It doesn’t work, because the macro expands to nothing during preprocessing before language rules begin. So writing UNUSED(x) is the same as writing nothing, and you end up with the warning.

2. It doesn’t handle the case when you want an expression with side effects, such as:

  ignore( SomeFunctionWithAResult() );

and you really want the contents of the ignore() to execute normally, not be discarded.

By the way, here’s one option I didn’t present, since this wasn’t intended to be a full article, but here goes: You could simply mention the variable again, such as:

  static void Constraints(D* p)
  {
     B* pb = p;
     pb; // mention the variable again
  }

Unfortunately, this also doesn’t do the trick because it does suppress the original warning on both compilers I tried (good) but creates a new warning on an overlapping set of compilers: Expression has no effect. In my test suite, we went from Borland and EDG reporting the original warning to EDG and Digital Mars now reporting a different warning. No win.

So the original method I presented is still the only portable way that’s been suggested so far, and it’s basically identical to Boost’s (Boost’s just spells out the mostly-redundant “inline” and “const”; see earlier comment above).

#define UNUSED(x)

will do the job.
It can be used for function formal parameters as well.

@Dmitry: The const isn’t needed, my version works correctly already on the code you gave. See below for details.

@Dmitry, @John: Yup, In general I might like the name “unused” better than “ignore”. And Boost’s name contains both words. :-)

@All: Yes, Boost’s is identical to the one I posted except that it does two things that aren’t really needed:

1. Boost’s explicitly says “inline.” This is usually redundant in practice, though I agree that saying it explicitly doesn’t hurt. The reason it’s redundant in practice is: (a) popular compilers aggressively inline functions anyway even if you didn’t mark them inline, as long as their bodies are visible at compile time (and sometimes even if they aren’t, see for example VC++ /LTCG); and (b) this is a template, and all portable templates use the inclusion model and therefore are included with their full bodies, so they are effectively implicitly inline because of (a).

2. Boost’s takes the parameter by const&. That isn’t necessary because template argument deduction will figure out the const anyway. I tried my version with const objects and it worked fine on all compilers, including very old ones.

For bonus points: What about volatile?

Any time you see “const”, also think “volatile” because it’s treated the same way in the type system. Incidentally, that’s another realistic case where the program performs writes that appear to be dead but aren’t because they go outside the program, namely to hardware.

Q: Does my version and/or Boost’s work with volatile objects? A: Yes, both also work fine with volatile objects, because template argument deduction also figures out the volatile for you anyway. If you want to be super explicit, like Boost was with const&, you’d actually want to take the parameter by const volatile &. But now I’m just being picky to point out that writing either qualifier is redundant, and they didn’t need to write the const either.

Nitpicker’s corner: Yes, I know that compilers are much less likely to warn about apparently-unused volatile variables because they know those variables are for hardware communication and writes to them are never dead. But in fact one compiler I’m testing with does still emit the warning even on apparently-unused volatile variables (it’s the Y2K-vintage Borland 5.5.1 again).