Bug 150 - CommandLine::Parse argc parameter should not be a reference
CommandLine::Parse argc parameter should not be a reference
Status: RESOLVED FIXED
Product: ns-3
Classification: Unclassified
Component: core
pre-release
All All
: P3 minor
Assigned To: ns-bugs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-22 13:36 UTC by Gustavo J. A. M. Carneiro
Modified: 2008-07-01 13:32 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gustavo J. A. M. Carneiro 2008-03-22 13:36:33 UTC
Something I found out while working on python bindings:

  /**
   * \param argc the 'argc' variable: number of arguments (including the
   *        main program name as first element).
   * \param argv the 'argv' variable: a null-terminated array of strings,
   *        each of which identifies a command-line argument.
   * 
   * Obviously, this method will parse the input command-line arguments and
   * will attempt to handle them all.
   */
  void Parse (int &argc, char *argv[]) const;

This is wrong; the only explanation for argc being a reference would be that it is inout or out argument.  However, when I looked at the sources I was surprised to discover that it was neither.  In this case the & is misleading and unnecessary.
Comment 1 Mathieu Lacage 2008-03-22 13:58:38 UTC
(In reply to comment #0)
> Something I found out while working on python bindings:
> 
>   /**
>    * \param argc the 'argc' variable: number of arguments (including the
>    *        main program name as first element).
>    * \param argv the 'argv' variable: a null-terminated array of strings,
>    *        each of which identifies a command-line argument.
>    * 
>    * Obviously, this method will parse the input command-line arguments and
>    * will attempt to handle them all.
>    */
>   void Parse (int &argc, char *argv[]) const;
> 
> This is wrong; the only explanation for argc being a reference would be that it
> is inout or out argument.  However, when I looked at the sources I was
> surprised to discover that it was neither.  In this case the & is misleading
> and unnecessary.
> 

You are right.
Comment 2 Mathieu Lacage 2008-04-15 12:53:10 UTC
changeset 3573d91994cc