public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Kevin Handy <kth@srv.net>
To: Robert Dewar <dewar@gnat.com>
Cc: gcc@gcc.gnu.org
Subject: Re: c++ "with" keyword
Date: Sun, 05 Jan 2003 00:37:00 -0000	[thread overview]
Message-ID: <3E1780BD.5040605@srv.net> (raw)
In-Reply-To: <20030104233549.44473F29F3@nile.gnat.com>

Robert Dewar wrote:

>>And to search for references to a structure becomes much more
>>complex.  Instead of looking for a '.x' or '->x', you must now search
>>for 'x', and then look to see if the reference is within a 'using'
>>clause.
>>    
>>
>
>You are imagining a very low level environment. In GNAT (using GPS) if you
>click on an entity, you get immediately to its declaration, and of course
>such a tool would disambiguate a reference immediately. You are also
>talking about misuse of the feature if you are talking about hundreds of
>lines of text.
>  
>
So, you are saying that nobody should be able to understand a hardcopy
printout of code on it's own. They should be required to examine it
inside of a GUI infested enviornment?

Seems like it's just making it harder to work with the code, instead of
easier.

Also, the clickie thingie will only work if it can parse the code, but
if I'm trying to get someone elses code to run on my *other-brand*
machine, and I have syntax errors, the GUI tools will probably not
be able to get their info until the syntax errors are gone, but I can't
get rid of the syntax errors if I can't figure out what the code is
supposed to do, which requires the tools, which ...

I still think it would cause more maintainence problems than
any help it would be for someones tired fingers.

90% of the cost of a program is usually in it's maintenance.

>>If long names are causing you typing problems, then DON'T CREATE LONG
>>NAMES IN THE FIRST PLACE. The "standard" C and C++ libraries usually
>>use fairly short names for everything. Most of the long names I've seen are
>>those created specifically for the program in question.  If the long 
>>names are
>>a real problem for you, then why create them in the first place?
>>    
>>
>
>Well that's the strongest argument in *favor* of WITH so far :-)
>Keeping names short because they are too painful to use is a significant
>negative effect, since well chosen longish names can often make a big
>difference to readability of code.
>
>Now it is true that the C++ syntax style generally favors short names:
>
>  *p++
>
>is a much nicer notation than
>
>  Julian_Date_At_Maturity++
>
shouldnt that be ;-)

    with (*Julian_Date_At_Maturity)
    {
        ++;
    }

sorry, couldn't help myself.

>so you could argue that a feature that made it more convenient to use long
>names was inconsistent in style with C++ :-)
>  
>
So, you want to use long names, but you just don't want to use them?

There is a point at which a name becomes too long to be convienient,
and if it is too long to type when needed, then it is probably too long to
consistantly type correctly. At that point it's more of a burden then a
help.

I've also seen enough programs with long names containing misspelled
words in them. Knowingly typing the *wrong* name is a bit
disconcerting (and I'm a bad speller, so it needs to be really wrong
for me to notice)


  reply	other threads:[~2003-01-05  0:29 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-05  0:29 Robert Dewar
2003-01-05  0:37 ` Kevin Handy [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-01-06 13:07 Robert Dewar
2003-01-05 18:41 Robert Dewar
2003-01-05 13:03 Robert Dewar
2003-01-05 13:39 ` Toon Moene
2003-01-05 12:56 Robert Dewar
2003-01-05 18:22 ` Joseph S. Myers
2003-01-05 12:56 Robert Dewar
2003-01-06 12:18 ` Andrew Haley
2003-01-05 12:44 Robert Dewar
2003-01-05  3:16 Robert Dewar
2003-01-05  0:38 Robert Dewar
2003-01-04 23:27 Robert Dewar
2003-01-04 23:36 ` Lynn Winebarger
2003-01-05  2:55 ` Gianni Mariani
2003-01-04 22:13 Robert Dewar
2003-01-04 20:59 Robert Dewar
2003-01-04 22:36 ` Gianni Mariani
2003-01-04 20:09 Robert Dewar
2003-01-04 19:36 Robert Dewar
2003-01-04 19:59 ` Tolga Dalman
2003-01-04 19:13 Robert Dewar
2003-01-04 20:58 ` Gianni Mariani
2003-01-04 18:11 Robert Dewar
2003-01-04 18:47 ` Gianni Mariani
2003-01-04 17:52 Robert Dewar
2003-01-04 17:59 ` Gianni Mariani
2003-01-04 17:06 Robert Dewar
2003-01-04 17:22 ` Daniel Berlin
2003-01-05 11:33 ` Andrew Haley
2003-01-05 11:36   ` Toon Moene
2003-01-04 14:29 Robert Dewar
2003-01-04 15:00 ` Momchil Velikov
2003-01-04 15:24   ` Andrew Haley
2003-01-04 16:25     ` Neil Booth
2003-01-04 17:35     ` Gianni Mariani
2003-01-04 17:59       ` Tolga Dalman
2003-01-04 18:36         ` Gianni Mariani
2003-01-04 18:54           ` Tolga Dalman
2003-01-04 23:32         ` Kevin Handy
2002-12-29  8:32 Norman Jonas
2002-12-29 12:46 ` Russ Allbery
2002-12-29  6:49 Erik Schnetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3E1780BD.5040605@srv.net \
    --to=kth@srv.net \
    --cc=dewar@gnat.com \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).