>>Declaring the variable at first use instead of at the top of the function
>just makes for ugly, unreadable code.
>
>-Dan.
I couldn’t disagree more. Declaring the variable where it is used makes the code more modular and clean. Why have variables declared at the top if you don’t even know if they are needed in some code paths. Sure you can introduce new scope and declare them there but requiring there declaration first does not help readability in the least. I don’t get your argument.
I’m impressed. In an attempt to avoid arguing C vs C++ this thread has
managed to become about where your variables should go. I suggest cutting
this off right now and arguing something more important. To start us off,
here are some suggestions I have:
Top posting vs bottom posting
Kirk vs.Picard
Alliance vs Horde
American Idol Season 1 or Season 2?
Screw nttalk, maybe we need NTDEV…
-scott
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com
Tim,
> - Declaring variables anywhere in the scope, i.e. directly before use
(also in C99)
>To me, this is a big deal.
Don't know whether this was sarcasm, but to me it is a very cool feature.
You mean typeid(xxx).name()? I didn't think that was present in C99. I
have to admit I've never used it, because of the perceived performance
hit that RTTI implies.
No, I meant more that you could do (with "sample" substitutions) do:
if(ULONG x = MyFunc()) {} ...
Variadic macros are ONLY in C99. They are not part of standard C++ (yet).
True, but modern C++ compilers implement the C99 subset, as far as I am aware. No?!
Many people think that operator overloading is a DISADVANTAGE of C++.
It's clear that there are many places where it is useful (strings,
complex numbers, rational numbers), but they are just way too easy to
abuse...
Also true. You have to be strict in your own style, but then you can greatly enhance the readability and maintainability.
Classes are just structs with function pointers. I don't see why that
would be an issue.
Also true. Ctors for structs/classes are a nice feature, too. I just wanted to show that there are advantages beyond the use of classes.
// Oliver
May the source be with you, stranger
ICQ: #281645
URL: http://assarbad.info | http://windirstat.info | http://blog.assarbad.info
> Declaring the variable at first use instead of at the top of the function
just makes for ugly, unreadable code.
Dan, reading the comments of Matt before replying to you, I agree with him.
It makes it more modular! I've also seen people writing C code where the initialization of the variable was postponed and then the variable was used without being initialized. This was due to copying of code pieces from below to a location above (before the initialization == first use). In such a case declaring the variable before use would break the compile(! ... not just logic and therefore lead to a bug) since the variable wouldn't be declared in such a way that the whole scope is able to use it. This can be quite effective as an error-preventing style convention.
May the source be with you, stranger
ICQ: #281645
URL: http://assarbad.info | http://windirstat.info | http://blog.assarbad.info
Don,
Whether the things you list are good or bad are style
issues not arguments that can be made for the case of improving drivers.
If they prevent mistakes (and consequently bugs) I consider that not just style in the cosmetic sense, though.
We all have our own style, much of what you list I will not use. In
fact some of those items below are things I know of a number of very
heavy C++ shops which disallow their use.
Well, I know a lot of people who say they write C++, but if you look at there code it's just C++'s C-subset typed into a .cpp file, or even worse, some mix of classes with the disadvantages of C (by typing the C-code into member functions and declaring that a class).
Overall I agree, though. This *is* and *remains* largely a matter of taste. And I hope I haven't offended anyone with my arguments so far. I was merely trying to state facts that I've found to be valid for me.
May the source be with you, stranger
ICQ: #281645
URL: http://assarbad.info | http://windirstat.info | http://blog.assarbad.info
Scott,
I'm impressed. In an attempt to avoid arguing C vs C++ this thread has
managed to become about where your variables should go.
why the sarcasm? This is a proven way of avoiding errors in code and in case of the use of ctors it will even spare you the actual construction of the object, although it will admittedly not spare you the space on the function's stack frame.
Also I haven't avoided the discussion, but rather stated this particular feature as one of the (legit, as I find) reasons to use the C++ compile mode rather than C without even touching the topic of classes (up to that point).
I think it should be allowed to discuss the pros and cons (and also discuss them more than once during the lifetime of this list). I've seen all kinds of discussions cooking up every now and then - and repeatedly. Why is C vs. C++ such a touchy topic for many list members? And why is it "C *versus* C++" in the first place? As if there is only either one and a combination of both impossible. My SOURCES files gladly take a mixed list of .c and .cpp source files. Is my system messed up? 
So far I've only read arguments against the use of *classes* (stack use, wasting nonpaged pool memory etc), but I haven't really seen any argument that explains why *not* to use some of the other features that C++ offers. Surely you don't only use the subset of C that was available in the very first C versions. Even when using "plain C" you surely use what came about during the evolution of this language. Don't you?
- Top posting vs bottom posting
Appending the basic style guide (if there is any) to the "---\nNTDEV is sponsored by OSR" at the bottom may help to avoid further confusion as to what the preferences of OSR are in that case
... and could we add "quoting of the whole mail vs. quoting of relevant parts"?
May the source be with you, stranger
ICQ: #281645
URL: http://assarbad.info | http://windirstat.info | http://blog.assarbad.info
> why the sarcasm?
Spend more time in the Northeast 
Why is C vs. C++ such a touchy topic for many list members?
I’m sure it wasn’t the first time it came up.
…you surely use what came about during the evolution of this language.
Don’t you?
Of course. And of course I have preferences as to which features to use and
not use. I even have a preference as to where my variables should be
declared (at the beginning, where god intended them to be), but I feel
absolutely zero need to try to convert others seeing as how it *is* a
preference.
And I don’t think people would have a problem with a discussion regarding
the fitness of a particular language feature for a driver design. That would
probably be a useful discussion that we all might learn something new from.
However, these discussions are never that precise and helpful and typically
devolve rather quickly into bandwidth wasting discussions of coding style.
-scott
–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Oliver Schneider” wrote in message
news:xxxxx@ntdev…
> Scott,
>
>> I’m impressed. In an attempt to avoid arguing C vs C++ this thread has
>> managed to become about where your variables should go.
> why the sarcasm? This is a proven way of avoiding errors in code and in
> case of the use of ctors it will even spare you the actual construction of
> the object, although it will admittedly not spare you the space on the
> function’s stack frame.
>
> Also I haven’t avoided the discussion, but rather stated this particular
> feature as one of the (legit, as I find) reasons to use the C++ compile
> mode rather than C without even touching the topic of classes (up to that
> point).
>
> I think it should be allowed to discuss the pros and cons (and also
> discuss them more than once during the lifetime of this list). I’ve seen
> all kinds of discussions cooking up every now and then - and repeatedly.
> Why is C vs. C++ such a touchy topic for many list members? And why is it
> “C versus C++” in the first place? As if there is only either one and a
> combination of both impossible. My SOURCES files gladly take a mixed list
> of .c and .cpp source files. Is my system messed up?
>
> So far I’ve only read arguments against the use of classes (stack use,
> wasting nonpaged pool memory etc), but I haven’t really seen any argument
> that explains why not to use some of the other features that C++ offers.
> Surely you don’t only use the subset of C that was available in the very
> first C versions. Even when using “plain C” you surely use what came about
> during the evolution of this language. Don’t you?
>
>> 1) Top posting vs bottom posting
> Appending the basic style guide (if there is any) to the “—\nNTDEV is
> sponsored by OSR” at the bottom may help to avoid further confusion as to
> what the preferences of OSR are in that case 
… if feasible, that is.
>
> … and could we add “quoting of the whole mail vs. quoting of relevant
> parts”?
>
>
> // Oliver
> –
> ---------------------------------------------------
> May the source be with you, stranger
>
> ICQ: #281645
> URL: http://assarbad.info | http://windirstat.info |
> http://blog.assarbad.info
>
>
I post wherever my mail program is most comfortable posting, having learned
that trying to force such apps to do other than they want to naturally do is
just asking for a fight. Plus the lyris program seems to get odd sometimes.
So the now ubiquitous gmail is a top poster…
On Jan 25, 2008 4:09 PM, Oliver Schneider wrote:
>
> > 1) Top posting vs bottom posting
> Appending the basic style guide (if there is any) to the “—\nNTDEV is
> sponsored by OSR” at the bottom may help to avoid further confusion as to
> what the preferences of OSR are in that case … if feasible, that is.
>
> … and could we add “quoting of the whole mail vs. quoting of relevant
> parts”?
>
>
> // Oliver
>
But my sig gets to the bottom of the pile, making it sort of bracket
posting.
p.s. this may be the most profoundly offtopic hijacking this year!
–
Mark Roddy
Oliver Schneider wrote:
So far I've only read arguments against the use of *classes* (stack use, wasting nonpaged pool memory etc)
Since we're restarting this old flamewar anyway... :-).
I will argue that classes are the *very best reason* to use C++ in the
kernel. The modularization advantages of object oriented programming,
while theoretically possible to achieve with C using structs and careful
programming, are vastly easier with a language that was designed to
handle them.
Can you abuse C++? Easily. Don't abuse the language and it won't abuse
you. Inheritance, even multiple inheritance sometimes, is a useful tool
for maintainability and cross-platform portability. Done well, with
proper respect and restraint, it's like having your own specialized
platform-independent driver model to program to. I'd say 10% or fewer of
our files contain anything even *Windows* specific, much less
9x/NT/2k/XP/Vista specific.
We had a working port of our driver to KMDF in a day or two (admittedly,
a trivial port that just escaped out to manual IOCTL handling at
first... a real port took a while longer, but we could do it one step at
a time and have a working testable driver the whole way).
The supposed problem of non-paged pool usage got silly years ago. Anyone
still worrying about the non-paged pool usage of their kernel-mode
driver today is writing *way* too much code to put in the kernel. The
only people that maybe should worry about that are Microsoft, and even
there I'm dubious. Certainly any advantage I could gain in my drivers by
making some bits pageable would be relatively tiny... the vast majority
of it is device logic that needs to be able to run at DPC level anyway.
And never changing the code segment means you simply don't have to worry
about where the compiler puts default constructors, template
instantiations, etc.
Stack space with C++ is only a problem if you use C++ exceptions or
RTTI, really, and that would be truly foolish in the kernel for a vast
number of reasons, assuming they're not just foolish everywhere :-).
Indeed, I save stack space by judicious use of member variables far more
often than I lose it. Similarly, every virtual function you call saves a
ton of stack space over a similarly portable and modular C 2-level call
hierarchy with switches for different object types, and is a gazillion
times more maintainable. However, your mileage may vary if you're in a
really deep driver stack.
The other stuff is fluff. Declarations near use? Whatever. Keep your
functions small enough (as you should be doing anyway) and you won't
have problems with putting your declarations at the top. At best it's a
very slight readability advantage, undone entirely if you actually
overload operators (ugh... but in the old days syntactic sugar seemed
sweeter than it does now).
If you're making use of dynamic_casts, you're abusing the language (and
are probably hampered by not having RTTI available anyway). More fluff.
There might be a 1% exception to that declaration, but I'll stand behind
it in the kernel.
There is one big type-safeness advantage you get from C++ than C can't
(easily) reproduce: templatized collections. People argue that templates
aren't safe, but I've been using them for 10+ years in the kernel, and
never once had a problem related to them. In fact, they've only
prevented problems for me. Don't abuse templates and they won't abuse
you. And no metaprogramming in a kernel driver! :-).
Oh, that and RAII-style locks. *Damn* those are useful. They keep you
out of more trouble than almost anything else in C++. Never having to
worry about releasing a lock on some rare error case code-path lets me
sleep so much better at night. If you're just a little bit clever, you
can use them to enforce lock hierarchies as well.
Ray
(If you want to reply to me off list, please remove "spamblock." from my
email address)
> Classes are just structs with function pointers
Actually, the only difference between class and struct in C++ is that the former ones all members are private by default. In all other respects they are exactly the same thing. It just somehow happened that structures are usually declared only with data members, apparently, due to their C heritage. However, this is just a public perception, rather than language feature - if you want to declare a structure with virtual functions and multiple inheritance, the compiler is not going to stand in your way…
Anton Bassov
Ray, Mark, Scott,
(Ray wrote:)
Oh, that and RAII-style locks. *Damn* those are useful. They keep you
out of more trouble than almost anything else in C++.
... RAII, goes very well together with declaring a variable where it's needed (and not earlier)
Anyway, I could go on, but don't let people tell you that C++ contains
only marginal advantages, or redirect the conversation to fluff like
declaration placement... focusing on the fluff is just a way to derail
the conversation into a direction where C probably really is better.
I don't, but since it appeared/appears that the majority of the frequent posters on NTDEV were/are opposed to C++ classes in KM, I thought I should show that there is a lot more besides the obvious. The fact that the positioning of the variables has been ridiculed like this only leaves me puzzled. If I recall correctly I posted more than just this one point.
(Mark wrote:)
But my sig gets to the bottom of the pile, making it sort of bracket
posting.
p.s. this may be the most profoundly offtopic hijacking this year!
And it's only January ;o)
(Scott wrote:)
Spend more time in the Northeast
Northeast ... of? The dark winter in Iceland can be quite depressing, so I can also be sarcastic during this time
Of course. And of course I have preferences as to which features to use
and not use. I even have a preference as to where my variables should be
declared (at the beginning, where god intended them to be), but I feel
absolutely zero need to try to convert others seeing as how it *is* a
preference.
Nor do I. That's why I wrote that these are my *personal* favorites of the C++ features that I do not want to miss, even in KM. I thought I had made that part clear.
And I don't think people would have a problem with a discussion
regarding the fitness of a particular language feature for a driver
design. That would probably be a useful discussion that we all might
learn something new from.
In hindsight you are completely right. The question was too general to be discussed without the hot temper that usually goes with "C vs. C++" on NTDEV. But at least some opinions and points have been exchanged, so I suppose it was useful for some of us
Have a nice weekend everyone!
May the source be with you, stranger
ICQ: #281645
URL: http://assarbad.info | http://windirstat.info | http://blog.assarbad.info
> - Using references instead of pointers to give the compiler some clue as to
what
we mean (e.g. if NULL pointers would be invalid)
C++ references are just plain evil.
The whole idea of having 2 sets of the same features in a language, one being
fully implemented (pointers) and one being a pathetic klugde (references - they
are not objects, there are no arrays of references and they also have major
issues with autocast in the inheritance tree) - is bad.
From what I understand, the only real value of references is to implement
lvalue parameters and lvalue return values for things like operator++() or
operator. In any other context, using a pointer to implement lvalue
parameter is better.
Most C++ code (except operator and such) only benefits if you replace all
references with pointers.
In reality, the bug with passing a NULL pointer somewhere is the most uncommon
bug ever met
- if(type name = bla()) {} (I believe this was possible in C99 as well)
RTTI is trivially implementable by macros and inheritance, so, I do not think
there is any value of having it in language.
- Typecast operators
- Overloading of operators for <, > +, ++, --, ==, != (etc pp).
Also should be used with care, since they reduce the code readability. If you
have “a = b;”, it is a bit hard for a reader to scan all header files and find
that this is actually “a = b.operator A();”.
should be still a number of advantages even if we leave out “classes”.
Classes themselves are actually one of the best features of C++. The language
is mainly used for classes and templates, and not for references and operator
T.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> Can you abuse C++? Easily. Don’t abuse the language and it won’t abuse
you. Inheritance, even multiple inheritance sometimes, is a useful tool
for maintainability and cross-platform portability.
Correct. Now note lots of unexperienced C++ coders, who know the language
features (including the most recent ones of 2000ies), but have no intuitive
sense of how to do things easily.
What they do is overuse of all language features, with a (IMHO perverted) view
of “using the smart - and especially recent - features is The Good by itself,
and is much more imporant than code readability and simplicity”.
This leads to ~5 times more code to implement the same, and to wrong choice of
language features to implement the task (like trying to do polymorphic object
loading from a stream using references instead of pointers - switching to
pointers is 10 times easier then doing this with references which have issues
with autocast in the inheritance tree).
All of the above is not related to Windows kernel-mode development. It is a
general thing. And yes, this is the basis of all anti-C++ positions - by some
of us here, by Linus Torvalds etc.
If you’re making use of dynamic_casts, you’re abusing the language (and
are probably hampered by not having RTTI available anyway).
Correct. In early C++ days, Stroustrup (with Ellis) provided a perfectly valid
reason of why he does not want any RTTI features to be in the language: a)
they provocate non-polymorphic coding styles b) hardcoding the layout of the
“class object” to the compiler is evil.
There is one big type-safeness advantage you get from C++ than C can’t
(easily) reproduce: templatized collections.
Templates are good, one of the best features of C++, though metaprogramming has
hardly any value in it except being an ivory tower adornment
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> … RAII, goes very well together with declaring a variable where it’s needed
(and ?
not earlier)
For RAII code to be readable, your should declare only after {, so that {} will
be the locked code path. Otherwise, the code reader will be confused a lot on
what is the locked code path.
C++ classes in KM
Not classes, but other things in C++.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> > Classes are just structs with function pointers
Actually, the only difference between class and struct in C++ is that the
former
ones all members are private by default.
Correct, but class/struct in C++ is wider then struct in C - member functions,
language-supported vtables, inheritance, construction/deconstruction, ability
to customize passing by value and to overload the operators.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> Well, I know a lot of people who say they write C++, but if you look at there
code
it’s just C++'s C-subset typed into a .cpp file, or even worse, some mix of
classes
with the disadvantages of C (by typing the C-code into member functions and
declaring that a class).
This is probably the best way of C++ use.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
>…member functions, language-supported vtables, inheritance, construction/deconstruction,
ability to customize passing by value and to overload the operators.
So there is only one question left - do we really need all the above (and quite a few features beyond that) in the kernel mode???
Anton Bassov
I would completely agree with your assessment of “using the smart…,”
and add that the situation is a party compared to what people who
learned C# first do, like have fifteen different singlets in one
program, and look at you like you are some out of your mind dinosaur if
you don’t do the same.
Templates are good, one of the best features of C++, though
metaprogramming has
> hardly any value in it except being an ivory tower adornment
You’re being far, far too kind here. Metaprogramming is the one of the
silliest things I can think as far as programming goes, with the notable
exception of ‘Extreme Programming;’ however I would say templates are
easily C++'s best feature.
mm
Maxim S. Shatskih wrote:
> Can you abuse C++? Easily. Don’t abuse the language and it won’t abuse
> you. Inheritance, even multiple inheritance sometimes, is a useful tool
> for maintainability and cross-platform portability.Correct. Now note lots of unexperienced C++ coders, who know the language
features (including the most recent ones of 2000ies), but have no intuitive
sense of how to do things easily.What they do is overuse of all language features, with a (IMHO perverted) view
of “using the smart - and especially recent - features is The Good by itself,
and is much more imporant than code readability and simplicity”.This leads to ~5 times more code to implement the same, and to wrong choice of
language features to implement the task (like trying to do polymorphic object
loading from a stream using references instead of pointers - switching to
pointers is 10 times easier then doing this with references which have issues
with autocast in the inheritance tree).All of the above is not related to Windows kernel-mode development. It is a
general thing. And yes, this is the basis of all anti-C++ positions - by some
of us here, by Linus Torvalds etc.> If you’re making use of dynamic_casts, you’re abusing the language (and
> are probably hampered by not having RTTI available anyway).Correct. In early C++ days, Stroustrup (with Ellis) provided a perfectly valid
reason of why he does not want any RTTI features to be in the language: a)
they provocate non-polymorphic coding styles b) hardcoding the layout of the
“class object” to the compiler is evil.> There is one big type-safeness advantage you get from C++ than C can’t
> (easily) reproduce: templatized collections.Templates are good, one of the best features of C++, though metaprogramming has
hardly any value in it except being an ivory tower adornment
Anton, Maxim,
(Anton wrote:)
So there is only one question left - do we really need all the above (and
quite a few features beyond that) in the kernel mode???
wrong question, IMO. The question more is whether *you* or *me* or anyone else him/herself or in team needs these features or finds them useful. It seems that the opponents of C++ in KM are quicker to tell *everyone* how to do what (i.e. not use C++), than the proponents are
(Maxim wrote:)
For RAII code to be readable, your should declare only after {, so that
{} will be the locked code path. Otherwise, the code reader will be
confused a lot on what is the locked code path.
Sure.
Correct. Now note lots of unexperienced C++ coders, who know the language
features (including the most recent ones of 2000ies), but have no
intuitive sense of how to do things easily.
Then educate them, if it's in your company.
In reality, the bug with passing a NULL pointer somewhere is the most
uncommon bug ever met
So? Uncommon doesn't mean it can't happen. And making the programmer go through hoops to make it happen, will at least get the programmer thinking (hopefully!), since it should then dawn them that this was *not* intended.
No question, references are more restrictive than pointers, but *that's* the feature, otherwise it would be merely the clone of the functionality of pointers. References allow you to express requirements in code and the compiler will complain if the caller doesn't comply. I thought there was a broad consensus among programmers that forcing compiler errors, where the alternative would be runtime errors (which need handling and "~5 times more code to implement" ...) was a good thing. Seems I was wrong.
People use SAL to help PREfast understand the code. Use a few (or more) well-chosen C++ features and you'll help the *compiler* to understand your code (and intentions).
This leads to ~5 times more code to implement the same, and to wrong
choice of language features to implement the task (like trying to do
polymorphic object loading from a stream using references instead of
pointers - switching to pointers is 10 times easier then doing this with
references which have issues with autocast in the inheritance tree).
I had something else in mind, e.g. the typical:
if(void* x = malloc(12345))
{
if(void* y = malloc(23456))
{
// do some things ...
if(SomeWeirdError())
{
HandleError();
free(y);
free(x);
return -1;
}
// do some other things here
free(y);
}
free(x);
}
You can make the code more modular and readable by using RAII here with the feature that classes on stack are destroyed when going out of scope *alone*. And if the original code with malloc/free (which is the kind of C I usally encounter in .cpp files of the aforementioned kind of people) "is probably the best way of C++ use", well then I am out of the discussion. It doesn't make sense to argue further then, because we have fundamentally different opinions on how to use/write C++. As was stated before by others, if you don't abuse C++, it won't abuse you!
May the source be with you, stranger
ICQ: #281645
URL: http://assarbad.info | http://windirstat.info | http://blog.assarbad.info
I use C++ in a pretty full sense in the kernel every day, and I
completely agree with your fundamental point - don’t abuse it and it
won’t abuse you - as well as that the opponents are certainly more
vociferous and, in my opinion, tend to be given to worst case scenarios
that may or may not exist, and in some cases just hysteria, but I can’t
say that I agree with you in some places here. Fundamentally, I am much
more interested in helping people understand the intent of source code
than the compiler; the compiler is on it’s own. In my opinion, I think
Maxim’s point here is that the NULL error is damn rare, and that some of
the issues with the semantics of references are more common, which I
would agree with, if that is in fact what he is saying. I don’t use
references much myself, except in the case of overloaded operators,
which I don’t use much either and are for all practical purposes
unusable with out them, because they do not declare the intent or lack
there of to modify an argument, whereas a pointer states that this is
the working assumption, one which is not going to be true a lot of the
time, but I prefer that problem than the one with references. It’s not
like either is a big deal, but over time, ‘->’ has been etched in to my
brain right next to ‘modify.’
I think this basic argument applies to a number of ‘C++’ features that
for probably ten years we were assured not only that they were the
‘better’ ways to do things, but, in fact, they were they only possible
way to accomplish things when scale was considered. This, of course,
was preposterous, and even a cursory look at the fates of early large
C++ projects that happened outside of Murray Hill will show a trail with
some huge, abject disasters from companies like Mentor Graphics. I
think some of the rigidity around this issue now is partially a reaction
to the past, when C++ was going to cure cancer, and it turned out that,
unless you happen to be Bjarne (not even going to give spelling his last
name a go) or Andrew Koenig, et. al., C++ is a lot harder to do well,
and a disaster waiting to happen for those who don’t treat it well, with
the irony of this being, it’s the same reaction to both sides of the
same coin. Also, some of the ‘better ways’ are very dubious when
considered from either a risk or reward point of view. For example,
using cout over printf(). Sure it’s safer, but it’s tedious as hell to
write, massacres your source code because it takes a huge amount of
space (relatively), especially when no one really cares about it or the
printf it replaced, and I’ve yet to see the program that was brought to
it’s knees because of an invalid format spec, written by anyone who has
ever gotten anything worth discussing or using out the door. Aside from
the fact that even in error, a bad printf() statement is still
essentially a debug trace that tells you where to look, if printf() is a
deal breaker for you, your fate was decided a long time ago.
As an aside, SAL is a crime against source code the world over.
Readability of source code always comes before tools in my book. Much
like the compiler, they too are own their own with me. I really like
the capabilities of PREfast, and I think that both sides of the debate
are very reasonable, but, for me, until it starts finding bugs that I
can’t find in other ways in a reasonable time frame, I’m not throwing my
code and really my obsessive habits under the bus. I like tools that do
what I want, not the other way around.
Cheers,
mm
Oliver Schneider wrote:
Anton, Maxim,
(Anton wrote:)
> So there is only one question left - do we really need all the above (and
> quite a few features beyond that) in the kernel mode???
wrong question, IMO. The question more is whether *you* or *me* or anyone else him/herself or in team needs these features or finds them useful. It seems that the opponents of C++ in KM are quicker to tell *everyone* how to do what (i.e. not use C++), than the proponents are(Maxim wrote:)
> For RAII code to be readable, your should declare only after {, so that
> {} will be the locked code path. Otherwise, the code reader will be
> confused a lot on what is the locked code path.
Sure.> Correct. Now note lots of unexperienced C++ coders, who know the language
> features (including the most recent ones of 2000ies), but have no
> intuitive sense of how to do things easily.
Then educate them, if it’s in your company.> In reality, the bug with passing a NULL pointer somewhere is the most
> uncommon bug ever met
So? Uncommon doesn’t mean it can’t happen. And making the programmer go through hoops to make it happen, will at least get the programmer thinking (hopefully!), since it should then dawn them that this was *not* intended.No question, references are more restrictive than pointers, but *that’s* the feature, otherwise it would be merely the clone of the functionality of pointers. References allow you to express requirements in code and the compiler will complain if the caller doesn’t comply. I thought there was a broad consensus among programmers that forcing compiler errors, where the alternative would be runtime errors (which need handling and “~5 times more code to implement”
People use SAL to help PREfast understand the code. Use a few (or more) well-chosen C++ features and you’ll help the *compiler* to understand your code (and intentions).
> This leads to ~5 times more code to implement the same, and to wrong
> choice of language features to implement the task (like trying to do
> polymorphic object loading from a stream using references instead of
> pointers - switching to pointers is 10 times easier then doing this with
> references which have issues with autocast in the inheritance tree).
I had something else in mind, e.g. the typical:if(void* x = malloc(12345))
{
if(void* y = malloc(23456))
{
// do some things …
if(SomeWeirdError())
{
HandleError();
free(y);
free(x);
return -1;
}
// do some other things here
free(y);
}
free(x);
}You can make the code more modular and readable by using RAII here with the feature that classes on stack are destroyed when going out of scope *alone*. And if the original code with malloc/free (which is the kind of C I usally encounter in .cpp files of the aforementioned kind of people) “is probably the best way of C++ use”, well then I am out of the discussion. It doesn’t make sense to argue further then, because we have fundamentally different opinions on how to use/write C++. As was stated before by others, if you don’t abuse C++, it won’t abuse you!
// Oliver