Better way to program this?

[werasm]

But other than that, what should one use for the type?
Would any of "digit", "Digit", "DigiT", "digiT" be
acceptable, then? And should ALL macros be named
with CAPITALS, then?

I presume by the type you mean the class (or is
DIGIT in actual fact a template argument). It
did not seem like a template argument to me.

e.g:

Your function did not look like this:

template <class DigitT>
void SomeObject( /*...*/ )
{
std::vector<DigitT> blah;
}

As I understood it DIGIT was a class. If that is the
case (it being a class), refer to James's detailed
(and sound) reply. If it was indeed a template argument
like DigitT here above, I personally would have called it
DigitT (or Digit_T). All caps are reserved for macros. A
capital here and there does no harm, as long as the identifier
does not only consist of capitals (just in case you misunderstood).

$50 for that book?! I need a good source of money... Heh,
which is why I'm trying to make these programs.

Good book - worth the money (IMHO).

I suppose so. It does sound like it would make it easier,
as then you can change how you do those often-used functions
without changing everything that uses them.

That is more or less my rationale too. If you have an
implementation where you've used transform, please post it
(under the previous topic) for interest sake (or mail me).

Regards,

Werner

 

[red floyd]

All caps are reserved for macros. A
capital here and there does no harm, as long as the identifier
does not only consist of capitals (just in case you misunderstood).

No, there is no such restriction. An argument can be made that all caps
*SHOULD BE* reserved for macros (an argument that I agree with), but
there is no such restriction defined in the language.

 

[werasm]

No, there is no such restriction. An argument can be made that all caps
*SHOULD BE* reserved for macros (an argument that I agree with), but
there is no such restriction defined in the language.

The point was from the start that it is generally accepted as
convention. Because of this, not adhering to this convention
makes you run the risk. All said, lowercase macros also exists,
but it is quite rare (min being one irritating one). I recently
came across a macro named "index" in a library that gave me some
problems. The argument is therefore indeed "SHOULD BE".

Regards,

Werner

 

[mike3]

The point was from the start that it is generally accepted as
convention. Because of this, not adhering to this convention
makes you run the risk. All said, lowercase macros also exists,
but it is quite rare (min being one irritating one). I recently
came across a macro named "index" in a library that gave me some
problems. The argument is therefore indeed "SHOULD BE".

Regards,

Werner

And that's why I want to know what all these conventions are.
What therefore should be used instead of all caps?

 

[Victor Bazarov]

And that's why I want to know what all these conventions are.
What therefore should be used instead of all caps?

There are several. All-lowercase is one (the Standard Library has
that one). All-lowercase with spaces separating words (also part
of the Standard Library convention). TitleCase is another. Then
you get your Title_Case (words separated by an underscore), which
I personally don't like. Then there is one with the name followed
by '_t' for all types (Standard library does not really follow it,
only for primitive types, like size_t, wchar_t, ptrdiff_t, etc.)

Essentially you need to pick one and follow it religiously. Then
it's very easy for somebody else to understand and use it.

V

 

[Ben Pfaff]

There are several. All-lowercase is one (the Standard Library has
that one). All-lowercase with spaces separating words (also part
of the Standard Library convention). TitleCase is another. Then
you get your Title_Case (words separated by an underscore), which
I personally don't like. Then there is one with the name followed
by '_t' for all types (Standard library does not really follow it,
only for primitive types, like size_t, wchar_t, ptrdiff_t, etc.)

If you ever might find yourself working in a POSIX environment,
using a _t suffix for all your types is a bad idea, because POSIX
explicitly reserves all names that end in _t if any POSIX header
(including any C header) is included.

 

[Victor Bazarov]

If you ever might find yourself working in a POSIX environment,
using a _t suffix for all your types is a bad idea, because POSIX
explicitly reserves all names that end in _t if any POSIX header
(including any C header) is included.

I don't doubt there are other environments where some limitations or
conventions are imposed. You either live with them or violate them
hoping nothing bad's gonna happen.

For example, in MFC while there aren't any reserved names (not
officially, anyway), all classes begin with a C and have TitleCase.
Similarly, in OWL they begin with a T.

I am yet to see a compiler that would actually enforce the reserved
name rule. AFAIK, the Standard does not say that the use of any
reserved name makes your code ill-formed.

V

 

[mike3]

There are several. All-lowercase is one (the Standard Library has
that one). All-lowercase with spaces separating words (also part
of the Standard Library convention). TitleCase is another. Then
you get your Title_Case (words separated by an underscore), which
I personally don't like. Then there is one with the name followed
by '_t' for all types (Standard library does not really follow it,
only for primitive types, like size_t, wchar_t, ptrdiff_t, etc.)

Essentially you need to pick one and follow it religiously. Then
it's very easy for somebody else to understand and use it.

Alright. Thanks for the answer.

 

[James Kanze]

[...]

Then there is one with the name followed
by '_t' for all types (Standard library does not really follow it,
only for primitive types, like size_t, wchar_t, ptrdiff_t, etc.)

The C standard uses _t for typedef's. The C++ uses it for
compatibility with C (even in the case of wchar_t, which isn't a
typedef in C++).

Because the only way in C to get a user symbol which is the name
of a type is with a typedef, some people interpret the _t in C
as the convention for a user defined type.