(I feel funny throwing my 2c on these generic threads when I've contributed
zip, but John opened it up so...)
- Exceptions, a.k.a. the surest way to templates-everything (via
RAII-everything).
- State. When performance allows, avoid storing duplicate state in members;
instead have methods ask
On 12/09/2009 10:02 PM, John Plevyak wrote:
That would be great, particularly for a big change like this (of
course it would be nice
to have it automatic and continuous).
I'll build a tracking git branch and post a URL.
Ok, cool. So, I'll vote a +1 on having this in the 2.0 release, for
Regarding the m_ for member,
I agree that for private/protected variables an indicator is a good idea.
Regular members are always accessed by reference outside the object, so
it seems obvious that it is a member:
cache_read_vio->nbytes
is a member and it doesn't help (me) to have it be:
cach
On Thu, Dec 10, 2009 at 10:44 AM, Manjesh Nilange wrote:
>> MACROS
>> ClassNames
>> memberFunctions
>> members_variables
>
> How about having an 'm_' prefix to distinguish member variables from
> local variables? I know this is a couple of more characters to type, but
> I find it nicer to be able
> MACROS
> ClassNames
> memberFunctions
> members_variables
How about having an 'm_' prefix to distinguish member variables from
local variables? I know this is a couple of more characters to type, but
I find it nicer to be able to distinguish class member variables easily.
The rest of the list lo
I would like to open up discussion on the simple vs. complex C++/OO issue.
There is a continuum between basic K&R C and full-blown meta-template
programming,
virtual everything, multiple-inheritance, massively overloaded, super
Object-Oriented C++.
Somewhere there is a happy point where most
OK, I have a git repository with cache partition patch setup which is
up-to-day as of today.
If you are a git wiz you can always merge to keep up-to-day with any
last minute changes
right before a benchmark test.
git clone git://jplevyak.homeip.net/trafficserver
This has been tested and shou
I have been reading style guides online and there is a good deal of
disagreement regarding camel case.
Many people believe that it is harder to read readFromOpenFile as
compared to read_from_open_file
and I have to agree.
However it is also nice to be able to tell the difference between the
That's the exact reason why I say char *foo is the "right" way to do it. I
think a subject like this even brings a bigger picture topic to light in
that a coding standard might even want to avoid multiple declarations in the
same line/statement for that very reason. As I get "on" in years I tend
On 12/9/09 11:22 PM, Leif Hedstrom wrote:
>>> * From the example, it seems like '*' is associated with the variable
>>> and not the type, i.e., 'char *arg' and not 'char* arg'. Can we state
>>> this explicitly and also clarify whether this applies to references
>>> also?
>>>
>> I prefer char*
10 matches
Mail list logo
