Prev: Errors using shared_ptr<> and get_deleter in g++-4.1/4.3/4.4
Next: Iterating over a directory
From: Tony Delroy on 15 Apr 2010 19:53
On Apr 16, 7:33 am, Keith H Duggar <dug...(a)alum.mit.edu> wrote:
> On Apr 15, 5:09 am, Maciej Sobczak <see.my.homep...(a)gmail.com> wrote:
>
> > On 15 Kwi, 08:54, Pete Becker <p...(a)versatilecoding.com> wrote:
>
> > > > Why should I (or anybody else), as a library writer, care about
> > > > enforcing the verbosity of notation in the client code?
>
> > > Because I can. And besides, it's good for them. I know better than they
> > > do what their code should look like.
>
> > Unfortunately the coding standard in my company prefers terseness over
> > verbosity in our own code (we don't care about the internal
> > implementation of third-party libraries, but we like to influence our
> > own coders).
>
> Personally I try to lead herds to water without cattle prodding
> them into the deep end. If I recall correctly Scott Meyers said
> at a conference something to the effect of "As designers we
> should focus on making the right things easier to do." (That is
> not a direct quote, unfortunately I don't recall the exact words
> but I think the gist is correct.) I think that makes sense. Make
> what you think is the "One True Way" easy to do rather than
> make what you /think/ is "bad" hard/impossible to do.

And what could be more "helpful" at making the "One True Way" easy to
do than having the compiler remind you if you forget...? Anyway,
everything I've seen from Scott covers both leading and prodding: e.g.
http://programmer.97things.oreilly.com/wiki/index.php/Make_Interfaces_Easy_to_Use_Correctly_and_Hard_to_Use_Incorrectly

Cheers,
Tony


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Keith H Duggar on 16 Apr 2010 04:01
On Apr 16, 6:53 am, Tony Delroy <tony_in_da...(a)yahoo.co.uk> wrote:
> On Apr 16, 7:33 am, Keith H Duggar <dug...(a)alum.mit.edu> wrote:
>
> > On Apr 15, 5:09 am, Maciej Sobczak <see.my.homep...(a)gmail.com> wrote:
>
> > > On 15 Kwi, 08:54, Pete Becker <p...(a)versatilecoding.com> wrote:
>
> > > > > Why should I (or anybody else), as a library writer, care about
> > > > > enforcing the verbosity of notation in the client code?
>
> > > > Because I can. And besides, it's good for them. I know better than they
> > > > do what their code should look like.
>
> > > Unfortunately the coding standard in my company prefers terseness over
> > > verbosity in our own code (we don't care about the internal
> > > implementation of third-party libraries, but we like to influence our
> > > own coders).
>
> > Personally I try to lead herds to water without cattle prodding
> > them into the deep end. If I recall correctly Scott Meyers said
> > at a conference something to the effect of "As designers we
> > should focus on making the right things easier to do." (That is
> > not a direct quote, unfortunately I don't recall the exact words
> > but I think the gist is correct.) I think that makes sense. Make
> > what you think is the "One True Way" easy to do rather than
> > make what you /think/ is "bad" hard/impossible to do.
>
> And what could be more "helpful" at making the "One True Way" easy to
> do than having the compiler remind you if you forget...?

That is making something /hard to avoid/ rather than /easy to do/.
For example, it is /hard to avoid/ writing things such as

map<string,vector<string> >::const_iterator i = dict.find(key) ;

these days. In contrast C++0x will make it /easy to do/:

auto i = dict.find(key) ;

that is the difference.

> Anyway, everything I've seen from Scott covers both leading and
> prodding.

No doubt. I was just giving an anecdote espousing a, IMO, useful
philosophy.

KHD

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: forums_mp on 17 Apr 2010 07:06
On Apr 14, 3:50 am, Tony Delroy <tony_in_da...(a)yahoo.co.uk> wrote:

> * enforcing a reliable association of interface and "physical" files
> (as class content can't be declared in multiple files the way
> namespace content can).

I'm not following this statement. Consider

//file_b.h
# ifndef FILE_B_H
# define FILE_B_H

# include <iostream>

class lets_see_b {
public:
static void test() { std::cout << "b" << '\n'; }
static int const dummy = 15 ;
};

# endif

//file_a.h
# ifndef FILE_A_H
# define FILE_A_H

# include <iostream>

class lets_see_a {
public:
static void test() { std::cout << "a" << '\n'; }
static int const dummy = 5 ;
};


# endif

//main.cpp
# include <iostream>
# include "file_a.h"
# include "file_b.h"

int main()
{
lets_see_a::test() ;
lets_see_b::test() ;
std::cin.get();

}

I've got test defined in multiple files and all's well. Am I
interpreting the authors comments wrong?

That aside:

The OPs thread reminds me of an ongoing conversation at my outfit
surrounding global constants. The coding standards advocates this
form:

#ifndef CONSTANTS_H
#define CONSTANTS_H
//constants.h
class constants {
public:
static int const MAGIC1 = 4;
static double const MAGIC2;
};
// constants.cpp
double const constants::MAGIC2 = 4.5;

Some now argue against the merits of a class when I could use a
namespace. i.e:

#ifndef CONSTANTS_H
#define CONSTANTS_H
//constants.h
namesace constants {
int const MAGIC1 = 4;
double const MAGIC2 = 4.5 ;
}
#endif

So the opposing side ask. "Why not a namepace"

Here's a summary of the differences as I understand them from the
'class' camp:

constants::MAGIC1 doesn't actually use any memory at compile time even
if use as long as only its value is use and you don't try to take a
pointer or a reference. If you do you will have to define it in
namespace scope like MAGIC2.

Items in namespaces are subject to ADL (Argument Dependent Lookup)
whereas members of classes are not. In other words, if you have a
function defined in the same namespace you can invoke it with the
constants defined in the namespace without needing to fully qualify
the function name or import the name space.

Classes offer enforced scoping, meaning you can'rimported into the
current namespace, you have to use full name qualification.

Classes have stricter rules about initialisation (only integrals can
be initialised in the class) meaning you have to have both a header
and a translation unit, with namespaces you can leave all your static
consts in the header.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Tony Delroy on 18 Apr 2010 13:48
On Apr 18, 7:06 am, forums...(a)hotmail.com wrote:
> On Apr 14, 3:50 am, Tony Delroy <tony_in_da...(a)yahoo.co.uk> wrote:
> > * enforcing a reliable association of interface and "physical" files
> > (as class content can't be declared in multiple files the way
> > namespace content can).
>
> I'm not following this statement. Consider
>
> //file_b.h
> # ifndef FILE_B_H
> # define FILE_B_H
>
> # include <iostream>
>
> class lets_see_b {
> public:
> static void test() { std::cout << "b" << '\n'; }
> static int const dummy = 15 ;
> };
>
> # endif
>
> //file_a.h
> # ifndef FILE_A_H
> # define FILE_A_H
>
> # include <iostream>
>
> class lets_see_a {
> public:
> static void test() { std::cout << "a" << '\n'; }
> static int const dummy = 5 ;
> };
>
> # endif
>
> //main.cpp
> # include <iostream>
> # include "file_a.h"
> # include "file_b.h"
>
> int main()
> {
> lets_see_a::test() ;
> lets_see_b::test() ;
> std::cin.get();
> }
>
> I've got test defined in multiple files and all's well. Am I
> interpreting the authors comments wrong?

Well, yes, but maybe I didn't explain it well. In the example above,
say you track down the class "lets_see_a" (which you can clearly see
hosts the first test() called by main()), all the interface will be
inside the single class declaration. Namespaces aren't restrictive
like that... there can be multiple headers, with content for a
namespace strewn about them. That's actually an extremely good thing
(if used in a controlled fashion), as a logical interface should be
able to evolve past the point of fitting well into a single header,
but some people argue for putting everything in one predictable place.

Cheers,
Tony


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: emitrax on 18 Apr 2010 21:02
On 14 Apr, 20:18, Ulrich Eckhardt <eckha...(a)satorlaser.com> wrote:
> emitrax wrote:
> > On 14 Apr, 02:43, Maciej Sobczak <see.my.homep...(a)gmail.com> wrote:
>
> [ about classes with only static functions ]
>
> >> Yes, that's strange. A "namespace extension", perhaps?
>
> >> Are there any objects created of these types?
>
> > No. Those classes are stated to be non-instantiable.
>
> "stated" in documentation or in code? If the author doesn't even know how to
> make a class non-instantiable, they probably didn't know too much about
> C++, so you can rule out a proper design decision.
>

Documentation (only).

I really really want(ed) to give him the benefits of the doubt.

S.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

First  |  Prev  | 
Pages: 1 2 3 4 5 6
Prev: Errors using shared_ptr<> and get_deleter in g++-4.1/4.3/4.4
Next: Iterating over a directory