When to use a namespace

[ma740988]

Consider

// file fft_data.h
class FFT_DATA
{
public:

static const unsigned int Data_Words = 10;
struct Data_Block_Type
{
unsigned short word[ Data_Words ];
unsigned short checksum;
bool valid;
};
// 4 more structs and thats it for fft_data
};

later

# include "fft_data.h"
class FP_SP_INTERFACE
{
public:

FFT_DATA:ata_Block_Type Do_A_Special_Thing();
};

Would a namespace be more appropriate here? If the answer depends,
then I'm confused on what.
It also appears 'odd' to me to have a class comprised SOLEY of
composite types and member data.


Thanks for your time.

 

[Victor Bazarov]

Consider

// file fft_data.h
class FFT_DATA
{
public:

static const unsigned int Data_Words = 10;
struct Data_Block_Type
{
unsigned short word[ Data_Words ];
unsigned short checksum;
bool valid;
};
// 4 more structs and thats it for fft_data

Doesn't seem to have any *data*, does it?

};

later

# include "fft_data.h"
class FP_SP_INTERFACE
{
public:

FFT_DATA:ata_Block_Type Do_A_Special_Thing();

Shouldn't that be 'static' or does it use some data members that you
decided to omit?

};

Would a namespace be more appropriate here? If the answer depends,
then I'm confused on what.

More appropriate for what? You can't create instances of namespaces.
You didn't explain at all whether you want to do that. You can't
inherit from a namespace either.

It also appears 'odd' to me to have a class comprised SOLEY of
composite types and member data.

What member data? Did you mean to say "static data"?

And, yes, if a struct has data and no member functions, it's OK.

Victor

 

[David Hilsee]

Consider

// file fft_data.h
class FFT_DATA
{
public:

static const unsigned int Data_Words = 10;
struct Data_Block_Type
{
unsigned short word[ Data_Words ];
unsigned short checksum;
bool valid;
};
// 4 more structs and thats it for fft_data
};

later

# include "fft_data.h"
class FP_SP_INTERFACE
{
public:

FFT_DATA:ata_Block_Type Do_A_Special_Thing();
};

Would a namespace be more appropriate here? If the answer depends,
then I'm confused on what.
It also appears 'odd' to me to have a class comprised SOLEY of
composite types and member data.

If you'd never create an instance of FFT_DATA and everything contained
inside of it is "open to the public", then it should probably be a namespace
instead of a class. However, in practice, there isn't much harm done in
leaving it as a struct. Sometimes you do need a struct instead of a
namespace. For instance, class templates sometimes delegate some work to
static members of a configurable type, and in that case, you can't use a
namespace.

 

[ma740988]

ma740988 wrote: [snip]

};

later

# include "fft_data.h"
class FP_SP_INTERFACE
{
public:

FFT_DATA:ata_Block_Type Do_A_Special_Thing();

Shouldn't that be 'static' or does it use some data members that you
decided to omit?

I didn't omit any member data and I'm not sure of what leads you to
believe that the returned type should be static.

More appropriate for what? You can't create instances of namespaces.
You didn't explain at all whether you want to do that. You can't
inherit from a namespace either.


What member data? Did you mean to say "static data"?

I suspect I erred in referring to Data_Words as 'member data' since
you seem to ramble on, on a continuum about data.

I chose the wrong class to use as my example since it only contained '
static data'.

And, yes, if a struct has data and no member functions, it's OK.

I suspect the same can be said for the 'class' - per my initial
example - since struct/class are somewhat interchangable.

 

[Victor Bazarov]

ma740988 wrote:
[snip]

};

later

# include "fft_data.h"
class FP_SP_INTERFACE
{
public:

FFT_DATA:ata_Block_Type Do_A_Special_Thing();

Shouldn't that be 'static' or does it use some data members that you
decided to omit?

I didn't omit any member data and I'm not sure of what leads you to
believe that the returned type should be static.

I am not sure what leads you to believe that specifying a member function
'static' has anything to do with its return type. Could it be you have
no idea what 'static' does to a member function?

I suspect I erred in referring to Data_Words as 'member data' since
you seem to ramble on, on a continuum about data.

I am not sure I understand the sentence above. Do you by any chance
understand the importance of "member data"? Why do we have member data
in classes at all? Do you know the difference between static and non-
static data members? If you answered "no" to any of these questions,
take a course on C++, or at least get back to your favourite C++ book.

[..]

 

[ma740988]

Victor Bazarov <[email protected]> wrote in message news:<[email protected]>...

[...]

I am not sure what leads you to believe that specifying a member function
'static' has anything to do with its return type. Could it be you have
no idea what 'static' does to a member function?

This has absolutely nothing with my understanding of static member
function but more importantly what YOU initially wrote. i.e...

[V Bazarov][/V Bazarov]

Perhaps I should have asked for clarification. i.e. Shouldn't 'that'?
'that' what?

My interpretation per your question was as follows:

class FFT_DATA
{
public:
static Data_Block_Type // Note: I added 'static' to Data_Block_Type
{
};
};

// later
class FP_SP_INTERFACE
{
public:
FFT_DATA:ata_Block Do_A_Special_Thing();
};

Alternatively, your questions could have been interpreted as:
static FFT_DATA:ata_Block_Type Do_A_Special_Thing();
Do_A_Special_Thing should be a static member function. IOW add static
in front of the return type. I chose the former interpretation.

[...]

I am not sure I understand the sentence above. Do you by any chance
understand the importance of "member data"? Why do we have member data
in classes at all? Do you know the difference between static and non-
static data members? If you answered "no" to any of these questions,
take a course on C++, or at least get back to your favourite C++ book.

Let me re-iterate again. This has absolutely NOTHING to do with my
understanding of the importance of member data among other things.

You rambled on about 'data' in your initial post. Of interest, lets
re-visit two of your initial questions.

1) Doesn't seem to have any *data*, does it?
2) What member data? Did you mean to say "static data"?


In my initial post I used the term 'member data' - on a 'broader
scale' - in an attempt to understand the impetus behind (more of a
design question) having a CLASS with just member data (static and non
static) and composite types? IOW. Why not a namespace.
Unfortunately FFT_DATA contained no 'non static member data' and I
erred in referring to Data_Words as member data as opposed to static
member data.

Perhaps FFT_DATA would have been more appropriate for you if I had.

class FFT_DATA
{
public:
int Idx; // member data
static int Jdx; // static member data
};


In the end I don't need your recommendations with regard to a course
or resorting to my favorite book on C++. At the graduate level, my
program of study may not entail C++, but after an undergraduate course
and reading texts, I'm comfortable enough with various aspects of the
language. I might not be able to quote the standard and am clueless
when it comes to libraries such as 'boost' (rumor has it, boost might
be included with the next 'revision') but I feel - linguistics aside
- it's important for me - at this point to know/use the right 'tools'
(especially those algorithms) for the job.

Indeed, finding and using the right tools for the job is oft easier
said that done, especially when working in 'teams': Just ask 'John
Doe' :
1) Why he used an array as opposed to std::vect
2) Why muck with char* when you have std::string.

Occassionally this turns into an arm wrestling match with plenty of
verbiage about 'what's better' etc. etc.

By the way. David Hilsee provided a detailed explanation which
answered my question. That said, we could move on.

Thanks for you time.

[..]

 

[Dave Rahardja]

Consider

// file fft_data.h
class FFT_DATA
{
public:

static const unsigned int Data_Words = 10;
struct Data_Block_Type
{
unsigned short word[ Data_Words ];
unsigned short checksum;
bool valid;
};
// 4 more structs and thats it for fft_data
};

later

# include "fft_data.h"
class FP_SP_INTERFACE
{
public:

FFT_DATA:ata_Block_Type Do_A_Special_Thing();
};

Would a namespace be more appropriate here? If the answer depends,
then I'm confused on what.
It also appears 'odd' to me to have a class comprised SOLEY of
composite types and member data.

If you'd never create an instance of FFT_DATA and everything contained
inside of it is "open to the public", then it should probably be a namespace
instead of a class. However, in practice, there isn't much harm done in
leaving it as a struct. Sometimes you do need a struct instead of a
namespace. For instance, class templates sometimes delegate some work to
static members of a configurable type, and in that case, you can't use a
namespace.

To me, a namespace should be used if the visibility of some entities
need to be confined to a group of classes, or a group of functions. In
the example above, the structs could have just as well been defined in
class FP_SP_INTERFACE, couldn't they?

If there were several classes that would like to share the definition of
the structs, as well as the static variable, then yes, they should all
go into a namespace.

 

[David Hilsee]

Consider

// file fft_data.h
class FFT_DATA
{
public:

static const unsigned int Data_Words = 10;
struct Data_Block_Type
{
unsigned short word[ Data_Words ];
unsigned short checksum;
bool valid;
};
// 4 more structs and thats it for fft_data
};

later

# include "fft_data.h"
class FP_SP_INTERFACE
{
public:

FFT_DATA:ata_Block_Type Do_A_Special_Thing();
};

Would a namespace be more appropriate here? If the answer depends,
then I'm confused on what.
It also appears 'odd' to me to have a class comprised SOLEY of
composite types and member data.

If you'd never create an instance of FFT_DATA and everything contained
inside of it is "open to the public", then it should probably be a namespace
instead of a class. However, in practice, there isn't much harm done in
leaving it as a struct. Sometimes you do need a struct instead of a
namespace. For instance, class templates sometimes delegate some work to
static members of a configurable type, and in that case, you can't use a
namespace.

To me, a namespace should be used if the visibility of some entities
need to be confined to a group of classes, or a group of functions. In
the example above, the structs could have just as well been defined in
class FP_SP_INTERFACE, couldn't they?

If there were several classes that would like to share the definition of
the structs, as well as the static variable, then yes, they should all
go into a namespace.

I don't think I understand your comment about visibility. To me, a
namespace is usually not used to confine visibility. Namespaces are
generally used as a logical grouping of functionality. Namespaces are "wide
open" when it comes to visibility. That is why I added that bit about
everything being "open to the public."

I agree that the structs could have been declared inside FP_SP_INTERFACE,
but I thought that ma740988 was asking if FFT_DATA should be a namespace
instead of a class. From the little bit of code that was provided, it
seemed to me that FFT_DATA was not being used to define a type of which
instances would be used. Instead, it was being used to group some common
functionality. For that usage, it sounded like a namespace was more
appropriate. Did I misunderstand you?

 

[Nicolas Pavlidis]

[...]

I don't think I understand your comment about visibility. To me, a
namespace is usually not used to confine visibility. Namespaces are
generally used as a logical grouping of functionality. Namespaces are "wide
open" when it comes to visibility. That is why I added that bit about
everything being "open to the public."

The general prupose of namespaces is to avoid nameclashes. The
properties of structuring code is a kind "side effect"

Kind regards,
Nicolas