From: Peter Olcott on
On 6/9/2010 2:06 PM, Kenneth 'Bessarion' Boyd wrote:
> On Jun 9, 12:06 pm, Peter Olcott<NoS...(a)OCR4Screen.com> wrote:
>
>> The problem might be that the enum is an int whereas what it must
>> initialize is a uint8_t.
>
> This is not a problem in this situation. The proposed enumeration for
> ActionCode has range 0-13, which *does* fit in a uint8_t; the real
> question is whether the target compiler requires a cast for the
> assignment.
>
>
>

That would probably get rid of the warning messages.

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

From: Peter Olcott on
On 6/9/2010 2:04 PM, Juan Pedro Bolivar Puente wrote:
> You can hide it as static private global. But yes, you need a .cpp for that.
OK, then this will not work for me.

>>> Consider the code bloat that you'd have if the compiler DID inline
>>> these and you had several calls!!
>> In my case it is probably a singleton, thus no possible code bloat.
>>
>
> I don't understand what you mean here. You have no instance of the
> Singleton design pattern in your code, if you meant that. And it would
> not affect this any way.
>
> The code bloat comes from the compiler duplicating function object code
> on every function call.

If a function is only called a single time, then this function is being
treated as a singleton. If it is being treated as a singleton, then
eliminating the function call overhead of this single invocation reduces
total memory requirements, thus the opposite of code bloat.

>> It also allows me to keep all of my code in headers.
>>
>
> And allows the compilation times to be huge and and the generated binary
> files to be huge too.

I don't see how it can increase the size of the generated file, and when
total compile time is trivial (on projects with few small files) the
increase in compile time is not noticeable. This practice would be
infeasible on large projects.

>
>>
>> I have been a "C" programmer since K&R was the de facto standard. I took
>> up C++ more than a decade ago.
>>
>
> How did you write the functions in C? As static functions implemented in
> the .h? Or did you use .cpp but just did no function call type checking
> at all?
>
>
No back then everything was in a single ".c" file. As I recall no
function prototypes were required, back then.

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

From: Peter Olcott on
On 6/9/2010 2:06 PM, Nick Hounsome wrote:
> On 9 June, 18:06, Peter Olcott<NoS...(a)OCR4Screen.com> wrote:
>> On 6/9/2010 8:25 AM, Nick Hounsome wrote:
>>
>>
>>
> That's not the point - If it's a static const 2d array then there is
> no dynamic memory used and no stack memory either. A win on time and
> (stack) space.
>
>>> c) Why do you want it in a header?
>>
>> Two files is redundant and messy. All of my code is in headers.
>
> Without going into details either thousands of C++ programmers are
> doing it wrong and you have had a blinding insight that nobody else
> has thought of before or just maybe they are right.

Or my way works better for small projects where the additional
compile-time is moot. I make essentially all of my choices based on
reasons rather than rules. For small projects where I am the sole
developer, this practice works better for me.

>
>>>>> 3) Eliminate all the global stuff - It's not comp.lang.c here.
>>
>>>> I don't know what you mean, everything is a member of a class.
>>
>>> all the const uint8_t have global scope
>>
>> OK what is the best way to do this?
>
> Move them into the class (as enums)

I might get a compile-time warning about assigning a (32-bit?) enum to
an 8-bit unsigned char.

>
>>>>> 4) Your class is logically stateless hence methods (as well as the
>>>>> state array) should be probably be static
>>
>>>> Maybe, what is the advantage?
>>
>>> a) you wouldn't keep creating your state table for every instance.
>>> b) It just seems more logical - When I see a class I start wondering
>>> what state it is holding and why. If you don't agree with this that's
>>> fine but then consider why we would have static members in C++ at all?
>>
>> Where is static member data stored?
>
> Same place global data is stored.
> And if it's a const 2d array it will just be memory mapped in from the
> exe - You can't do better than that.

Can I put this in a header file?

>>> The compiler is never REQUIRED to inline anything in fact the keyword
>>> "inline" will almost certainly go the way of "register" and be
>>> deprecated some time in the future.
>>
>> MS VS always inlines when you "suggest" it to.
>
> Are you sure?
> Have you dissassembled this?
Yes.
> That's another black mark for MS then.
Why? Getting more of exactly what you ask for is a good thing, as long
as you know what to ask for.

>>> Consider the code bloat that you'd have if the compiler DID inline
>>> these and you had several calls!!
In that case I might take out the inline, depending on benchmark results.

>>
>> In my case it is probably a singleton, thus no possible code bloat.
>
> Why would you bother posting if you don't want to write good reusable
> code???
> Some poor guy may oneday decide to use your class and unless he looks
> at the implementation he will not realize why his app is so big.

Yes that is a good point.
>
>>> Separate header/source files are a huge aid to C++ allowing you to
>>> separate interface from implementation. This makes compilation faster
>>> and allows binary updates of dynamic libraries without recompilation.
>>
>> I just can't get over how messy this redundancy is, especially for tiny
>> little classes.
>
> What redundancy?
> The only thing duplicated is the method signatures.
>
>>> In practice what most compilers will do with this example is that they
>>> will not inline it but they will create a copy of the used method in
>>> every compilation unit that uses it. At best you make a lot of extra
>>> work for the linker.
>>
>> It also allows me to keep all of my code in headers.
>
> Putting aside right or wrong, At code review you would be told to go
> back and change it in every company I have ever worked for.

I would do it the conventional way to start with in that case.

>
>>> Your comments here make me think that you're probably a C# or Java
>>> programmer. Files have a very different role in C++ and until you
>>> understand the term "compilation unit" you are not really getting it.
>>
>> I have been a "C" programmer since K&R was the de facto standard. I took
>> up C++ more than a decade ago.
>
> Do you put everything in headers in C?

K&R did not require function prototypes, thus I did not need my own
header files.

>
>>>>> 6) Use vector::reserve so that push_back wont do multiple
>>>>> reallocations/copies
>>
>>>> Yes. I had initially allocated the worst case memory, then I thought
>>>> that this wasted memory. When I benchmarked it on 100 instances of the
>>>> entire Unicode set, it only took about 30% more time, but, 50% less
>>>> memory. It might be a good idea to at least reserve() the best case
>>>> memory requirement.
>>
>>>>> 7) Template the methods and use iterators rather than collections -
>>>>> it's more flexible (you can keep the current signatures as overloads)
>>>>> 8) Why are you using uint8_t as a State instead of an enum???????
>>>>> NextState = 0 !!!???? Same goes for ActionCode.
>>
>>>> Yes this is the best suggestion.
>>
>> The problem might be that the enum is an int whereas what it must
>> initialize is a uint8_t.
>
> Why?


Probably only the dozens of compiler warning messages.
>
>


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

From: Dilip on
On Jun 9, 12:06 pm, Peter Olcott <NoS...(a)OCR4Screen.com> wrote:
> On 6/9/2010 8:25 AM, Nick Hounsome wrote:
> >>> 5) It is highly unlikely that these methods would be inlined by the
> >>> compiler (inline is a hint not an order) and if they were it could be
> >>> a space wasting disaster. Make them non-inline - The call overhead
> >>> will be dwarfed by the processing in almost all cases.
>
> >> The compiler requires inlining if the methods are included in the
> >> header. I hate creating the typically required pair of files it seems so
> >> redundant.
>
> > The compiler is never REQUIRED to inline anything in fact the keyword
> > "inline" will almost certainly go the way of "register" and be
> > deprecated some time in the future.
>
> MS VS always inlines when you "suggest" it to.

Could you please read the documentation before making dubious
statements like this? I looked up the reference for you on MSDN.
Please read this link:
http://msdn.microsoft.com/en-us/library/z8y1yy88.aspx
(This document is specific to the VC++ compiler that ships with VS
2010 but every other compiler version I checked carries the same
verbiage)

The relevant statement is:
"The compiler treats the inline expansion options and keywords as
suggestions. There is no guarantee that functions will be inlined. You
cannot force the compiler to inline a particular function, even with
the __forceinline keyword. "


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

From: Kenneth 'Bessarion' Boyd on
On Jun 10, 3:29 pm, "Alf P. Steinbach" <al...(a)start.no> wrote:

> Happily, no, you don't need a separately compiled file for the definition. As
> Leigh Johnston remarked else-thread you can have it as a static member of a
> templated base class. I used to call that "the templated constant idiom", but
> since it's so very much less than well-known (I and now Leigh seem to be the
> only persons who point out the possibility where it's relevant) it hardly
> deserves to be called an idiom, so I don't know what to call it...

We'll make it an idiom yet!

To quote myself:
====
5) The bootstrapping of State is a speed/maintainability trade off.
Speed would expect this to be a static const uint8_t State[9][256],
but
* avoiding linking errors from initializing this requires either
templating, or a *.cpp file to hold the initialization. Assuming
header-only implementation leaves templating.
====

Templating reference tables was a godsend when I was trying to work on
a header-only thermodynamics library. (Trading time for avoiding an
upfront cost of a few thousand U.S.$ apiece for three different
databases with incompatible interfaces).


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