Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > New to C++

Reply
Thread Tools

New to C++

 
 
Balog Pal
Guest
Posts: n/a
 
      01-02-2013
On 1/1/2013 1:13 PM, Öö Tiib wrote:
> On Monday, 31 December 2012 16:28:57 UTC+2, Tobias Müller wrote:
>> The whole point of namespaces actually is, that you don't _have_ to use it
>> unless you have a name clash. And if you have one, you can fix it on the
>> client side.

>
> But do not you feel that something has been 'broken' if it needs 'fixing'?


No. That argument implies extreme generalisation. As if we should walk
with open umbrellas all the time. Instead of picking them only when the
forecast suggests and open them only in the street when it actually rains.

Using prefixes is excess noise that hurts reading and writing. It is an
ongoing cost you pay. I don't mind paying when it is needed, but not out
of some general fear or out of ignorance.

> 'using namespace' on the other hand is lazy shortcut that imports whole
> namespace, documents nothing and unless it causes clashes immediately it
> works like time bomb that one needs to fix in the future.


I agree that using directive damn powerful and it must come with the
question 'you surely know all the names dragged in or have other means
to be sure the effect will be benign.'

But the answer to the latter is pretty often an positive yes. Maintained
by a simple set of guidelines.

IMO the simple name hiding rules of C++ work pretty fine for most cases,
and situations where you actually need a qualification are rare. (so
they also serve as attention drawing, that non-default thing happens!)

> No. That is the other edge way how to go too far with namespaces by
> by splitting it into small namespaces with long names. C++ has
> fortunately a cure to it:
>
> namespace region = thatdomain::thatsubdomain::thatsubdubdomain;


That is cure only for forced 3rd party stuff, if needed for homegrown,
I'd consider different ones.

I recall CORBA used to generate such nested madness. While healthy
librarues stick with a single public namespace name, and even provide
some #define to turn that off.




 
Reply With Quote
 
 
 
 
Balog Pal
Guest
Posts: n/a
 
      01-02-2013
On 1/1/2013 10:33 PM, Öö Tiib wrote:
> There we differ. There are too lot of convenient short names in namespace std
> to demand that these names are sacred and should never be used otherwise.
> Why authors of C++ did put them into that namespace? I think because they
> saw as well that these names can mean entirely other things in some other
> context.


There wasn't any considerable alternatives. The standard came pretty
late to C++, and any existing code was not to be broken.

Since then quite passed, and new code written, that is aware of
existence of std:: IMO has not much excuse to just ignore names.

Wasn't it your example with the non-standard ref class? That approach is
only good to create trouble.

 
Reply With Quote
 
 
 
 
Balog Pal
Guest
Posts: n/a
 
      01-02-2013
On 1/1/2013 10:33 PM, Öö Tiib wrote:
> It is possible that you for example use some naming convention that prevents
> clashes, for example you use capitalized names. Then you have 'Game::Map'
> and it can no way clash with 'std::map'.


Actually that is what most, if not all places I saw do. All lowercase
names are used only in locations not clashing with all-lower libraries.
(or the all-lower names use special form/prefix)

That was the case well before the C++ standard was created, due to the C
library and its followers.


 
Reply With Quote
 
Öö Tiib
Guest
Posts: n/a
 
      01-02-2013
On Wednesday, 2 January 2013 01:17:37 UTC+2, Tobias Müller wrote:
> Öö Tiib <(E-Mail Removed)> wrote:
> > These are all features that compile to valid code in C++ language.
> > However ... the behavior may be confusing and error prone so ... lot of
> > people have abandoned those.
> >
> > People who avoid that 'using namespace' do it for similar reasons. It makes
> > code fragile.

>
> But all those other features are either dangerous at runtime or make the
> (existing) code difficult to understand. 'using namespace' is neither
> dangerous, nor confusing for reading existing code. It may require changes
> in the future, when name clashes are introduced, but I find that
> acceptable.


When I look someone's code with what I am not too familiar with then it can
be indeed harder to get for me what that fill(), reverse(), rotate() or generate()
there does. When it is qualified std::fill(), std::reverse(), std::rotate()or
std::generate() then the code is simpler to understand for me, even with no
compiler errors.

It may be totally irrelevant for you if you and your team uses capitalized
function and member function names so fill() means std::fill() and some
non-standard fill in same scope is spelled 'Fill()'.

On that case I also see why you consider 'using namespace std;' less harmful
than 'using namespace ThatOther;'. The names from ThatOther namespace
may cause more headache for you than the ones from std.

....
> My point is, that the feature is not dangerous per se.


Not dangerous like throwing from destructor. Hopefully you see too that
(depending on naming conventions used) the outcome may become
confusing.
 
Reply With Quote
 
Dombo
Guest
Posts: n/a
 
      01-02-2013
Op 02-Jan-13 3:05, Balog Pal wrote:
> On 1/1/2013 6:35 PM, Jorgen Grahn wrote:
>>> Can't tell without context. The first rule of overload sets is that all
>>> members have the same semantics. I mean SAME .

>>
>> That's a rule I was unaware of. I happily break it, all the time.

>
> Guess then the other people working on the same code are not so happy
> . Believe me, it's pretty important one both for functions and
> operators. (The usual flamewars about evilness of operator overloading
> ar normally based on examples where this rule is broken.)


Rule#1: If the code was hard to write it should be hard to understand.

 
Reply With Quote
 
Öö Tiib
Guest
Posts: n/a
 
      01-02-2013
On Wednesday, 2 January 2013 05:28:24 UTC+2, Balog Pal wrote:
> On 1/1/2013 1:13 PM, Öö Tiib wrote:
> > On Monday, 31 December 2012 16:28:57 UTC+2, Tobias Müller wrote:
> >> The whole point of namespaces actually is, that you don't _have_ to use it
> >> unless you have a name clash. And if you have one, you can fix it on the
> >> client side.

> >
> > But do not you feel that something has been 'broken' if it needs 'fixing'?

>
> No. That argument implies extreme generalisation. As if we should walk
> with open umbrellas all the time. Instead of picking them only when the
> forecast suggests and open them only in the street when it actually rains..


Yes ... however I feel it other way around that using directive opens up
such (big and on lot of circumstances tedious) umbrella that saves one from
qualifying lot of names that he even does not plan to use. Using
declaration you mentioned in other answer feels lot more like correct tool.

> Using prefixes is excess noise that hurts reading and writing. It is an
> ongoing cost you pay. I don't mind paying when it is needed, but not out
> of some general fear or out of ignorance.


I actually use qualified names only in few places where i import those
into context and often rename them. So if coding standard say the
types have to be capitalized then something like:

surrounding_context // namespace, class, function
{
typedef unsigned int Code;
typedef std:air<Code, std::string> CodeName;
typedef std::vector<CodeName> CodeNames;
// ...
// rest of the code does not need to mention
// vector or pair at all, it deals with CodeNames
// of the context.
}

See, only 3 times typed 'std::' so 'using namespace std;' would save nothing
and can be itself considered excess noise and bloat.

> > 'using namespace' on the other hand is lazy shortcut that imports whole
> > namespace, documents nothing and unless it causes clashes immediately it
> > works like time bomb that one needs to fix in the future.

>
> I agree that using directive damn powerful and it must come with the
> question 'you surely know all the names dragged in or have other means
> to be sure the effect will be benign.'
>
> But the answer to the latter is pretty often an positive yes. Maintained
> by a simple set of guidelines.


The sub-thread here was more about 'using namespace std' and it is quite
frequent that I do not even remember if some fold_case() was in std or boost
or in both or in neither. When I don't know it then majority of my coworkers
don't and so the positive "yes" is somewhat questionable about std.

> IMO the simple name hiding rules of C++ work pretty fine for most cases,
> and situations where you actually need a qualification are rare. (so
> they also serve as attention drawing, that non-default thing happens!)


What is simple for us is not so simple for novice. Sometimes they are quite
deeply confused that using same name in inner scope (say derived class)
just hides name in outer scope (say base class) and no diagnostics nor
clashes. So it makes sense to avoid hiding names even if the rules are
clear and simple.

> > No. That is the other edge way how to go too far with namespaces by
> > by splitting it into small namespaces with long names. C++ has
> > fortunately a cure to it:
> >
> > namespace region = thatdomain::thatsubdomain::thatsubdubdomain;

>
> That is cure only for forced 3rd party stuff, if needed for homegrown,
> I'd consider different ones.


Sure, I would also just call such homegrown tree of namespaces as
"over-engineered" in review and suggest to flatten it down.

> I recall CORBA used to generate such nested madness. While healthy
> librarues stick with a single public namespace name, and even provide
> some #define to turn that off.


Yes, the open source works often started because someone tried to do
something great in different (hopefully better) way. Sometimes the results
did prove that the way was not that good. So those works still serve as
very good examples of ways that are worth to avoid.

The niche of CORBA is unfortunately still not filled with something as
useful, so people sometimes have to use it for real.
 
Reply With Quote
 
Balog Pal
Guest
Posts: n/a
 
      01-02-2013
On 1/2/2013 11:29 AM, Öö Tiib wrote:
>> But the answer to the latter is pretty often an positive yes. Maintained
>> by a simple set of guidelines.

>
> The sub-thread here was more about 'using namespace std' and it is quite
> frequent that I do not even remember if some fold_case() was in std or boost
> or in both or in neither. When I don't know it then majority of my coworkers
> don't and so the positive "yes" is somewhat questionable about std.


Here I meant guidelines we discussed on other branch, like not having
all-lowercase names at the namespace level. So the possible hiding is
limited to local names, and can be handled easily.

>> IMO the simple name hiding rules of C++ work pretty fine for most cases,
>> and situations where you actually need a qualification are rare. (so
>> they also serve as attention drawing, that non-default thing happens!)

>
> What is simple for us is not so simple for novice. Sometimes they are quite
> deeply confused that using same name in inner scope (say derived class)
> just hides name in outer scope (say base class) and no diagnostics nor
> clashes. So it makes sense to avoid hiding names even if the rules are
> clear and simple.


With this I strongly disagree. The hiding rule is overly simple as it
stands (the new introduced name hides all instances of the same name). I
recall myself debating it and push for more refined versions, but since
was convinced that this simplicity serves better.

Yes, it has cases where confusing novices, but the mitigation is not
avoiding the problem, but pushing to educate those novices until they
get it. By now we have a good collection of the top accidents, so it can
be presented as 'gotcha'.

And if someone can't get as much as hiding, I would not grant him code
check-in rights.


 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      01-06-2013
On Wed, 2013-01-02, Balog Pal wrote:
> On 1/1/2013 6:35 PM, Jorgen Grahn wrote:
>>> Can't tell without context. The first rule of overload sets is that all
>>> members have the same semantics. I mean SAME .

>>
>> That's a rule I was unaware of. I happily break it, all the time.

>
> Guess then the other people working on the same code are not so happy
> . Believe me, it's pretty important one both for functions and
> operators.


I guess what I'm saying is I don't believe you. I never heard of such
a rule; do you have a reference?

To elaborate a bit: if we're talking free functions (and I believe we
were) my naming is designed to make the calling code easy to read.
For example, one common form is verb(object).

If a verb can have different meanings in different context (and that's
true for a lot of verbs!) that doesn't stop me from using it.
In my book, smoke(Cigarette) and smoke(Pork) doesn't have to have
any semantics in common.

Of course, if I can lean on an existing convention, I do. It's one
of the forgotten benefits of the standard library -- it's full of
conventions you can reuse.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      01-06-2013
Jorgen Grahn wrote:
> On Wed, 2013-01-02, Balog Pal wrote:
>> On 1/1/2013 6:35 PM, Jorgen Grahn wrote:
>>>> Can't tell without context. The first rule of overload sets is that all
>>>> members have the same semantics. I mean SAME .
>>>
>>> That's a rule I was unaware of. I happily break it, all the time.

>>
>> Guess then the other people working on the same code are not so happy
>> . Believe me, it's pretty important one both for functions and
>> operators.

>
> I guess what I'm saying is I don't believe you. I never heard of such
> a rule; do you have a reference?


It strikes me as a common sense rule to avoid confusing callers.

> To elaborate a bit: if we're talking free functions (and I believe we
> were) my naming is designed to make the calling code easy to read.
> For example, one common form is verb(object).
>
> If a verb can have different meanings in different context (and that's
> true for a lot of verbs!) that doesn't stop me from using it.
> In my book, smoke(Cigarette) and smoke(Pork) doesn't have to have
> any semantics in common.
>
> Of course, if I can lean on an existing convention, I do. It's one
> of the forgotten benefits of the standard library -- it's full of
> conventions you can reuse.


One of which is all overloads have the same semantics. Can cite a
counterexample?


--
Ian Collins
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      01-06-2013
Paavo Helde wrote:
> Ian Collins <(E-Mail Removed)> wrote in
> news:(E-Mail Removed):
>
>> Jorgen Grahn wrote:
>>> Of course, if I can lean on an existing convention, I do. It's one
>>> of the forgotten benefits of the standard library -- it's full of
>>> conventions you can reuse.

>>
>> One of which is all overloads have the same semantics. Can cite a
>> counterexample?

>
> Not exactly overload, but close: std::numeric_limits<T>::min() gives the
> smallest expressible number for type T - except if T happens to be double
> or float, in which case min() returns something totally different. Bitten
> several times by this.


Me too! That is probably a good example of why the convention should be
adhered to.

--
Ian Collins
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Javascript new-new-new-new-newbee weblinkunlimited@gmail.com Javascript 2 03-11-2008 01:15 AM
New computer, New OS, New Wireless Problem :-\ =?Utf-8?B?RGFu?= Wireless Networking 3 07-31-2005 02:11 PM
[Firefox] Use New Tab instead of New Window? paul j Firefox 7 04-07-2005 09:40 PM
Why can not register a new .net passport or a new hotmail account Alick Lv MCSD 1 01-04-2004 06:12 PM



Advertisments