[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c++

Constants and namespaces

Rune Allnor

9/10/2008 12:32:00 PM

Hi folks.

I naively tried to define some useful constants inside a namespace:

namespace me{
#define PI = 3.14;
};

It works when I refer to the constant from within that namespace,
but from the outside I get compiler errors:

float a= me::PI * 28;

One obvious solution is to define the constant in the global
namespace, but I would prefer not to. So I tried a simple
static variable:

namespace me{
template<class T>
static const T Pi = 3.14;
};

but that, too, gives a compiler error.

So how does one solve this simple task?

Rune
11 Answers

Fred Zwarts

9/10/2008 12:44:00 PM

0


"Rune Allnor" <allnor@tele.ntnu.no> wrote in message news:dfc267f9-afd1-4f2b-99dd-df57793c0a46@79g2000hsk.googlegroups.com...
> Hi folks.
>
> I naively tried to define some useful constants inside a namespace:
>
> namespace me{
> #define PI = 3.14;
> };

You do not define a constant. You define a macro (which is not bound to the namespace scope).
The macro PI has the value "= 3.14;".
Why don't you define a constant in the normal way:

const float Pi = 3.14;

> It works when I refer to the constant from within that namespace,

I don't think so. Can you give an example where it works correctly?
The perprocessor will change e.g.

MyFloat = PI;

to

MYFloat = = 3.14;;

which may be legal C++ code, but probably not what you want.

> but from the outside I get compiler errors:
>
> float a= me::PI * 28;

The preprocessor changes this to

float a=me::= 3.14; * 28;

which correctly triggers an error message.

>
> One obvious solution is to define the constant in the global
> namespace, but I would prefer not to. So I tried a simple
> static variable:
>
> namespace me{
> template<class T>
> static const T Pi = 3.14;
> };
>
> but that, too, gives a compiler error.
>
> So how does one solve this simple task?
>
> Rune

Fred Zwarts

9/10/2008 12:49:00 PM

0

"Fred Zwarts" <F.Zwarts@KVI.nl> wrote in message news:ga8fe1$5t9$1@aioe.org...

Clicked the Send button too fast.

> The perprocessor will change e.g.
>
> MyFloat = PI;
>
> to
>
> MYFloat = = 3.14;;
>
> which may be legal C++ code, but probably not what you want.


should be:

The preprocessor will change e.g.

MyFloat=PI;

to

MYFloat== 3.14;;

which may be legal C++ code, but probably not what you want.



???

9/10/2008 1:04:00 PM

0

Rune Allnor ??:
> Hi folks.
>
> I naively tried to define some useful constants inside a namespace:
>
> namespace me{
> #define PI = 3.14;
> };
>
> It works when I refer to the constant from within that namespace,
> but from the outside I get compiler errors:
>
> float a= me::PI * 28;
>
> One obvious solution is to define the constant in the global
> namespace, but I would prefer not to. So I tried a simple
> static variable:
>
> namespace me{
> template<class T>
> static const T Pi = 3.14;
> };
>
> but that, too, gives a compiler error.
>
> So how does one solve this simple task?
>
> Rune

i guess you dont know clearly what the preprocessor do and what the compiler do.

the "#define" ,"#if", etc. commands are preprocessor commands,which are used by the preprocessor, not the compiler.
so the #define command dont have a scope,whether a namespace or class or something,the preprocessor just replace it.

to limit the scope of one const,you should use the compiler keyword "const",if this does not work for your compiler,
one alternative is to use "enum const". for instance,the code should be like this:

namespace me
{
const double PI = 3.14;
};

double a = me::PI * 28.

hope this could help.

James Kanze

9/10/2008 4:22:00 PM

0

On Sep 10, 2:43 pm, "Fred Zwarts" <F.Zwa...@KVI.nl> wrote:
> "Rune Allnor" <all...@tele.ntnu.no> wrote in
> messagenews:dfc267f9-afd1-4f2b-99dd-df57793c0a46@79g2000hsk.googlegroups.com...

> > I naively tried to define some useful constants inside a namespace:

> > namespace me{
> > #define PI = 3.14;
> > };

> You do not define a constant. You define a macro (which is not
> bound to the namespace scope). The macro PI has the value "=
> 3.14;". Why don't you define a constant in the normal way:

> const float Pi = 3.14;

Just a nit, but the "normal" way today is:

float const pi = 3.14 ;

(except that for a constant named pi, I'd expect something more
like 3.14159265358979323846:-).

Some programmers (myself included) even like to add the keyword
static, to make it clear that the linkage is internal.

> > It works when I refer to the constant from within that namespace,

> I don't think so. Can you give an example where it works
> correctly? The perprocessor will change e.g.

> MyFloat = PI;

> to

> MYFloat = = 3.14;;

> which may be legal C++ code, but probably not what you want.

It's not legal C++. There's no way that the compiler can
convert "MyFloat = PI" into legal C++, given the definition,
because there will always be two successive = tokens, and there
is no production in the grammar which allows two successive =
tokens.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

James Kanze

9/10/2008 4:24:00 PM

0

On Sep 10, 2:49 pm, "Fred Zwarts" <F.Zwa...@KVI.nl> wrote:
> "Fred Zwarts" <F.Zwa...@KVI.nl> wrote in messagenews:ga8fe1$5t9$1@aioe.org...

> Clicked the Send button too fast.

> > The perprocessor will change e.g.

> > MyFloat = PI;

> > to

> > MYFloat = = 3.14;;

> > which may be legal C++ code, but probably not what you want.

> should be:

> The preprocessor will change e.g.

> MyFloat=PI;

> to

> MYFloat== 3.14;;

> which may be legal C++ code, but probably not what you want.

Still not legal. Since tokenization takes place before macro
expansion, you still get two successive = tokens.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Erik Wikström

9/10/2008 5:02:00 PM

0

On 2008-09-10 18:22, James Kanze wrote:
> On Sep 10, 2:43 pm, "Fred Zwarts" <F.Zwa...@KVI.nl> wrote:
>> "Rune Allnor" <all...@tele.ntnu.no> wrote in
>> messagenews:dfc267f9-afd1-4f2b-99dd-df57793c0a46@79g2000hsk.googlegroups.com...
>
>> > I naively tried to define some useful constants inside a namespace:
>
>> > namespace me{
>> > #define PI = 3.14;
>> > };
>
>> You do not define a constant. You define a macro (which is not
>> bound to the namespace scope). The macro PI has the value "=
>> 3.14;". Why don't you define a constant in the normal way:
>
>> const float Pi = 3.14;
>
> Just a nit, but the "normal" way today is:
>
> float const pi = 3.14 ;

I suppose it depends on the environment you work in, but I would instead
have #included <math.h> (or <cmath>) and used M_PI. Of course, if you do
not have a POSIX compliant environment you might have to make your own.

--
Erik Wikström

ldnayman

2/7/2011 6:11:00 PM

0

On Feb 7, 12:52 pm, PinAffliction <s.to...@comcast.net> wrote:
> Plenty of good opinions on game play already, so I will not add to
> that other than say I own and will be keeping both.
> Since you've played both you can make your own decisions based on game
> play.
> So, I'd suggest getting the SM NIB while you can, it will always hold
> value pretty well and will be much harder to get as time goes on
> compared to STTNG. There's a ton of STTNG pins around and the price is
> pretty stable in the mid $2k range for a good one.

This argument doesn't make sense to me.

The value of a nice STTNG will go up, while the value of a NIB/HUO
Spiderman will go down. HUO Spiderman games are very common. Better
advice is buy the STTNG now, and wait to buy a Spiderman, as the value
will drop.

PinAffliction

2/7/2011 6:14:00 PM

0

Yes, but he was asking for advice on a NIB SM or a STTNG, so that is
the question I responded to :)

Scott
On Feb 7, 12:10 pm, ldnayman <ldnay...@aol.com> wrote:
> On Feb 7, 12:52 pm, PinAffliction <s.to...@comcast.net> wrote:
>
> > Plenty of good opinions on game play already, so I will not add to
> > that other than say I own and will be keeping both.
> > Since you've played both you can make your own decisions based on game
> > play.
> > So, I'd suggest getting the SM NIB while you can, it will always hold
> > value pretty well and will be much harder to get as time goes on
> > compared to STTNG. There's a ton of STTNG pins around and the price is
> > pretty stable in the mid $2k range for a good one.
>
> This argument doesn't make sense to me.
>
> The value of a nice STTNG will go up, while the value of a NIB/HUO
> Spiderman will go down. HUO Spiderman games are very common. Better
> advice is buy the STTNG now, and wait to buy a Spiderman, as the value
> will drop.

taylor34

2/7/2011 6:21:00 PM

0

On Feb 7, 12:10 pm, ldnayman <ldnay...@aol.com> wrote:
> On Feb 7, 12:52 pm, PinAffliction <s.to...@comcast.net> wrote:
>
> > Plenty of good opinions on game play already, so I will not add to
> > that other than say I own and will be keeping both.
> > Since you've played both you can make your own decisions based on game
> > play.
> > So, I'd suggest getting the SM NIB while you can, it will always hold
> > value pretty well and will be much harder to get as time goes on
> > compared to STTNG. There's a ton of STTNG pins around and the price is
> > pretty stable in the mid $2k range for a good one.
>
> This argument doesn't make sense to me.
>
> The value of a nice STTNG will go up, while the value of a NIB/HUO
> Spiderman will go down. HUO Spiderman games are very common. Better
> advice is buy the STTNG now, and wait to buy a Spiderman, as the value
> will drop.

I don't think HUO Spiderman's are going down in price anytime soon,
they've been going up since that 2.00 software release. It went from
a $3200 to $3400 HUO game to a $3800 to $4k game after that. St:tng
really hasn't gone up much in the past 5 years, lots of other games
have gone up a lot but St:tng has stayed relatively stable for some
reason. I think it's because of the theme, because gameplay wise I
think it's the best Williams I've played. Game value to fun factor
never really make much sense in the pinball world though, lol.

seymour-shabow

2/7/2011 6:37:00 PM

0

taylor34 wrote:
> On Feb 7, 12:10 pm, ldnayman <ldnay...@aol.com> wrote:
>> On Feb 7, 12:52 pm, PinAffliction <s.to...@comcast.net> wrote:
>>
>>> Plenty of good opinions on game play already, so I will not add to
>>> that other than say I own and will be keeping both.
>>> Since you've played both you can make your own decisions based on game
>>> play.
>>> So, I'd suggest getting the SM NIB while you can, it will always hold
>>> value pretty well and will be much harder to get as time goes on
>>> compared to STTNG. There's a ton of STTNG pins around and the price is
>>> pretty stable in the mid $2k range for a good one.
>> This argument doesn't make sense to me.
>>
>> The value of a nice STTNG will go up, while the value of a NIB/HUO
>> Spiderman will go down. HUO Spiderman games are very common. Better
>> advice is buy the STTNG now, and wait to buy a Spiderman, as the value
>> will drop.
>
> I don't think HUO Spiderman's are going down in price anytime soon,
> they've been going up since that 2.00 software release. It went from
> a $3200 to $3400 HUO game to a $3800 to $4k game after that. St:tng
> really hasn't gone up much in the past 5 years, lots of other games
> have gone up a lot but St:tng has stayed relatively stable for some
> reason. I think it's because of the theme, because gameplay wise I
> think it's the best Williams I've played. Game value to fun factor
> never really make much sense in the pinball world though, lol.
>

I think it's because people think it's too hard. It punishes you
severely if you don't make your shots. If you look at a common trend
with the high value games.... Say, MM, CC, and MB; even AFM - they're
newbie friendly. You don't make a ramp, it doesn't drain.

Not STTNG...... lots of possibilities to drain from a poor shot. Weak
delta shot=possible drain down the right side. The right side, in general.

-scott CARGPB#29