soft and program: 25 new messages in 11 topics

comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en

comp.lang.c++@googlegroups.com

Today's topics:

==============================================================================
TOPIC: memory leak in constructor and during object creation
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/907915dd5a5d7664?hl=en
==============================================================================

== 1 of 3 ==
Date: Mon, Sep 29 2008 12:06 am
From: Old Wolf

On Sep 29, 7:33 pm, raj s <yesr...@gmail.com> wrote:
> Will the below code cause memory leak in c++
>
> class base{
> int a;
> int *pint;
> someclass objsomeclass;
> someclass* psomeclass;
> base(){
> objsomeclass = someclass();
> psomeclass = new someclass();
> pint = new int();
> throw "constructor failed";
> a = 43;
> }}

Should be a semicolon after this. Now, as
you suspect, if you create a 'base' then
you get a memory leak because the memory
allocated by "new someclass()" and "new int()"
is never freed.

The best solution is to design your class
to not 'new' things. I guess you are coming
from Java or something like that by your code
stype. In C++ you rarely need to have classes
that 'new' their members. For example, in
the above code, there is no need to 'new' an int.

Failing that, you will have to use
'smart pointers' instead of raw pointers.
For example, if instead of:
someclass *psomeclass;
you could have:
auto_ptr<someclass> psomeclass;

Note that you can initialize things in
the constructor initializer list:
base(): psomeclass( new someclass ) {.....}

Some comments on the rest of your code:
>
> main(){
> base temp();

This doesn't declare any objects, it declares
a function. I think you meant:
base temp;

You seem to have a fascination with useless
parentheses :)

== 2 of 3 ==
Date: Mon, Sep 29 2008 12:53 am
From: "Fred Zwarts"

"raj s" <yesraaj@gmail.com> wrote in message news:a0806fca-5003-4aae-a66d-0d6505aee2e7@8g2000hse.googlegroups.com...
> Will the below code cause memory leak in c++
>
> class base{
> int a;
> int *pint;
> someclass objsomeclass;
> someclass* psomeclass;
> base(){
> objsomeclass = someclass();
> psomeclass = new someclass();
> pint = new int();
> throw "constructor failed";
> a = 43;
> }
> }
> main(){
> base temp();
> }
>
> in the above code constructor fails.Which objects will be leaked and
> how to avoid memory leak and even if destructor is called for
> automatic object is temp and temp pointer will leak the memory?
>
> main(){
> base *temp = base();
> }
>
> what about in the above code and how to avoid memory leak when
> constructor fails

If you really must use new and if you cannot use a smart pointer type,
than you should handle the exception yourself. E.g.:

base()
: pint (0), psomeclass (0)
{
try {
objsomeclass = someclass();
psomeclass = new someclass();
pint = new int();
throw "constructor failed";
a = 43;
} catch (...) {
delete pint;
delete psomeclass;
throw;
}
}

== 3 of 3 ==
Date: Mon, Sep 29 2008 12:53 am
From: Marcel Müller

raj s schrieb:
> Will the below code cause memory leak in c++

Yes. All pointer objects will never be destroyed, since your programm
does not provide a delete statement.

> class base{
> int a;
> int *pint;
> someclass objsomeclass;
> someclass* psomeclass;
> base(){
> objsomeclass = someclass();
> psomeclass = new someclass();
> pint = new int();
> throw "constructor failed";
> a = 43;
> }
> }
> main(){
> base temp();
> }

> in the above code constructor fails.Which objects will be leaked and
> how to avoid memory leak

Use smart pointers.

> and even if destructor is called for
> automatic object is temp and temp pointer will leak the memory?

The destructor will not be called if the constructor fails. But the
destructor for a successfully constructed base members is called -
normally. In your case, you do not catch your exception. That usually
causes a call to abort(), which will end your programm immediately
without any cleanup. From that point it is up to the operating system to
do the cleanup.

> main(){
> base *temp = base();
> }
>
> what about in the above code and how to avoid memory leak when
> constructor fails

The memory of base is normally freed in this case, since no object is
successfully constructed. But again, you must catch your exception to
prevent your programm from an immediate abort.

Marcel

==============================================================================
TOPIC: const conersions
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/b76f47ac997c730f?hl=en
==============================================================================

== 1 of 3 ==
Date: Mon, Sep 29 2008 1:12 am
From: James Kanze

On Sep 28, 1:21 pm, Rahul <rahulsha...@lucent.com> wrote:

> Why does the following gives a compilation error

> int const * * p1= 0;
> int * * p2 = 0;
> p1 = p2;

Because it's illegal. It breaks const-ness without a cast.

> p1 has more const restriction than p2 so increasing const'ness
> should always be allowed, there's no harm which p1 could do to
> the value pointed to by p2. So why is this an error.

int const i = 42 ;
int * pi ;
int ** p1 = &pi ;
int const** p2 = p1 ;
*p2 = &i ;
*pi = 0 ;

What does pi point to? The converions of &pi to an int const**
allows making it point to a const object, without a const_cast.
In other words, it breaks const.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

== 2 of 3 ==
Date: Sun, Sep 28 2008 11:36 am
From: Juha Nieminen

joseph cook wrote:
> On Sep 28, 7:21 am, Rahul <rahulsha...@lucent.com> wrote:
>> Hi,
>> Why does the following gives a compilation error
>>
>> int const * * p1= 0;
>> int * * p2 = 0;
>> p1 = p2;
>>
>> p1 has more const restriction than p2 so increasing const'ness should
>> always be allowed, there's no harm which p1 could do to the value
>> pointed to by p2. So why is this an error.
>>
>> Regards
>
> You aren't really increasing or decreasing "const'ness". p1 is a
> pointer to type A, and p2 is a pointer to type B. (Where A is a
> pointer to a const int, and B is a pointer to int).

Why can't you assign a "pointer to int" to a "pointer to const int"?
It doesn't sound like this assignment would lose any qualifiers.

== 3 of 3 ==
Date: Mon, Sep 29 2008 6:42 am
From: James Kanze

On Sep 28, 8:36 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> joseph cook wrote:
> > On Sep 28, 7:21 am, Rahul <rahulsha...@lucent.com> wrote:

> >> Why does the following gives a compilation error

> >> int const * * p1= 0;
> >> int * * p2 = 0;
> >> p1 = p2;

> >> p1 has more const restriction than p2 so increasing
> >> const'ness should always be allowed, there's no harm which
> >> p1 could do to the value pointed to by p2. So why is this
> >> an error.

> > You aren't really increasing or decreasing "const'ness".
> > p1 is a pointer to type A, and p2 is a pointer to type B.
> > (Where A is a pointer to a const int, and B is a pointer to
> > int).

> Why can't you assign a "pointer to int" to a "pointer to const
> int"? It doesn't sound like this assignment would lose any
> qualifiers.

You can, but that's not what he's attempting to do. What he's
trying to do breaks const-ness; see my other posting.

==============================================================================
TOPIC: Please solve this question
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/92c3a70cd5972302?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Sep 29 2008 1:21 am
From: James Kanze

On Sep 29, 4:15 am, Jeff Schwab <j...@schwabcenter.com> wrote:
> reepakmajhi....@gmail.com wrote:
> > Write a c++ program to display the following?

> > # # # # #

> > K V Jharsuguda

> > # # # # #

> #include <algorithm>
> #include <iostream>
> #include <iterator>
> #include <sstream>

> int main() {
>
> std::istringstream input_stream(
> "23 20 20 20 20 20 20 20 20 20 20 20 23 20 20 20"
> "20 20 20 20 20 20 20 20 20 23 20 20 20 20 20 20"
> "20 20 20 20 20 23 20 20 20 20 20 20 20 20 20 20"
> "20 23 0a 0a 20 20 20 20 20 20 20 20 20 20 4b 20"
> "56 20 4a 68 61 72 73 75 67 75 64 61 0a 0a 23 20"
> "20 20 20 20 20 20 20 20 20 23 20 20 20 20 20 20"
> "20 20 20 20 20 20 23 20 20 20 20 20 20 20 20 20"
> "20 20 23 20 20 20 20 20 20 20 20 20 20 20 23 0a" );

> input_stream.flags(std::ios::hex | std::ios::skipws);

> copy(
> std::istream_iterator<unsigned>( input_stream ),
> std::istream_iterator<unsigned>( ),
> std::ostream_iterator<char>( std::cout ));

> return 0;
> }

Did you actually try it? All you're doing is outputting your
string literal.

The obvious answer is something like:
std::cout
<< "# # # # #\n"
" K V Jharsuguda\n"
"# # # # #"
<< std::endl ;
But the answer is so obvious I suspect that tbe original poster
has some other additional requirements which he's chosen to hide
from us.

== 2 of 2 ==
Date: Sun, Sep 28 2008 11:38 am
From: Juha Nieminen

reepakmajhi.com@gmail.com wrote:
> Write a c++ program to display the following?
>
> # # # # #
>
> K V Jharsuguda
>
> # # # # #

int main()
{
const char* str =
"# # # # #\n"
"\n"
" K V Jharsuguda\n"
"\n"
"# # # # #\n";

std::cout << str;
}

==============================================================================
TOPIC: static/nonstatic data member declaration/definition
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/43a61151cda6482c?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Sep 29 2008 1:23 am
From: James Kanze

On Sep 29, 4:40 am, Jeffrey <jkar...@gmail.com> wrote:
> My understanding is that if you write

> class X {
> int y;
> static int z;
> };

> then you've defined (and declared) X and y, but you have only
> declared (and not defined) z. If you'd like to actually
> define z, you also need to add

> int X::z;

> Can anybody tell me the reason that the language was designed
> to be like this? It seems it would be simpler if z were
> defined in the same way as y, so presumably there's some good
> reason.

Mainly historical reasons, I suspect, but of course, if there is
an initializer (as there usually should be), you usually don't
want it in a header.

==============================================================================
TOPIC: comp.lang.c++ / C++ user community
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/505c05e0a15936dc?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Sep 29 2008 2:10 am
From: Zeppe

James Kanze wrote:
> On Sep 26, 10:37 am, Zeppe
> <ze...@remove.all.this.long.comment.yahoo.it> wrote:
>> tony_in_da...@yahoo.co.uk wrote:
>>> - Someone could post on here "how do I stream the symbolic
>>> identifier associated with an enum?" and 20 people would
>>> leap on it merrily saying "you can't", or proposing arcane,
>>> inconvenient hacks. Then go on to discuss whether a
>>> semicolon or a comma is more appropriate at some point in a
>>> footnote in the Standard.
>
>> Probably it's because you can't.
>
> You can't is pretty strong language. The standard doesn't
> forbid extensions, so you could always write your own C++
> compiler, with some sort of support for this as an extension.
> (Let us know when you're finished.) Short of that, of course...

Unfortunately in this case the effect is to have code that depends on a
specific compiler or utility, that is not guarantee to be portable and
makes the generation of code and the compliance to the good-practice of
"one-click build" rather complex. I'd prefer to avoid, sincerely.

My solution is, if you don't have thousands of enum to print, just to
provide for each enum two helper functions operator<< and operator>>,
that can be called explicitely or implicitely via a template

template <typename T>
std::string toString(const T& t)
{
std::ostringstream oss;
oss << t;
return oss.str();
}

and

template <typename T>
T stringTo(const std::string& s)
{
T t; // requires default empty constructor
std::isstringstream iss(s);
iss >> t;
return t;
}

The resulting code is very easy to read and not too slow to produce
(even though, I agree, much of it could be avoided).

Best wishes,

Zeppe

== 2 of 2 ==
Date: Mon, Sep 29 2008 6:40 am
From: James Kanze

On Sep 29, 11:10 am, Zeppe
<ze...@remove.all.this.long.comment.yahoo.it> wrote:
> James Kanze wrote:
> > On Sep 26, 10:37 am, Zeppe
> > <ze...@remove.all.this.long.comment.yahoo.it> wrote:
> >> tony_in_da...@yahoo.co.uk wrote:
> >>> - Someone could post on here "how do I stream the symbolic
> >>> identifier associated with an enum?" and 20 people would
> >>> leap on it merrily saying "you can't", or proposing arcane,
> >>> inconvenient hacks. Then go on to discuss whether a
> >>> semicolon or a comma is more appropriate at some point in a
> >>> footnote in the Standard.

> >> Probably it's because you can't.

> > You can't is pretty strong language. The standard doesn't
> > forbid extensions, so you could always write your own C++
> > compiler, with some sort of support for this as an extension.
> > (Let us know when you're finished.) Short of that, of course...

> Unfortunately in this case the effect is to have code that
> depends on a specific compiler or utility, that is not
> guarantee to be portable and makes the generation of code and
> the compliance to the good-practice of "one-click build"
> rather complex. I'd prefer to avoid, sincerely.

My suggestion was meant more or less humoristically. If you're
capable of writing a complete C++ compiler in a reasonable time
for most projects, you don't need any suggestions from me.
Implementing things like templates just so you can output a
couple of enum values is not really the most efficient use of
your time.

> My solution is, if you don't have thousands of enum to print,
> just to provide for each enum two helper functions operator<<
> and operator>>, that can be called explicitely or implicitely
> via a template

> template <typename T>
> std::string toString(const T& t)
> {
> std::ostringstream oss;
> oss << t;
> return oss.str();
> }

> and

> template <typename T>
> T stringTo(const std::string& s)
> {
> T t; // requires default empty constructor
> std::isstringstream iss(s);
> iss >> t;
> return t;
> }

> The resulting code is very easy to read and not too slow to produce
> (even though, I agree, much of it could be avoided).

Well, I do practically the opposite: I provide toString and
fromString functions. Generated automatically, of course; no
point it writing this all out by hand yourself.

==============================================================================
TOPIC: C++ inventor Bjarne Stroustrup answers the Multicore Proust
Questionnaire
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/58c6635e208a36bf?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Sep 29 2008 3:06 am
From: "Chris M. Thomasson"

"Szabolcs Ferenczi" <szabolcs.ferenczi@gmail.com> wrote in message
news:0154714b-388b-4c47-88e0-c3a1142f2bca@t54g2000hsg.googlegroups.com...
On Sep 28, 7:00 pm, "Daniel T." <danie...@earthlink.net> wrote:

> > [...]
> > Agreed. I have played around with Occam's expression of Communicating
> > Sequential Processes (CSP). I would like to see CSP explored further in
> > C++.
> >
> > What I have found so far
> > ishttp://www.twistedsquare.com/cppcspv1/docs/index.html

> Well, CSP is a very nice language concept and OCCAM is an interesting
> instance of it.

[...]

> It is worth mentioning that at the time CSP was published, there
> appeared another elegant language concept: Distributed Processes (DP).
> This is something that can be mapped very naturally to objects and
> gives you high level of potential parallelism. In DP an object starts
> its own thread which operates on its own data space and other objects
> can call its methods asynchronously.

Each object starts its own thread? lol, NO WAY! I can definitely implement a
high-performance version of DP in which a plurality of thread multiplexes
multiple objects. N number of threads for O number of objects. N = 4; O =
10000. Sure. No problem. DP does not have to work like you explicitly
suggest. Sorry, but you make huge mistake.

> The initial thread and the called
> methods then are executed in an interleaved manner. If the initial
> thread finishes, the object continues to serve the potentially
> simultaneous method calls, i.e. it becomes a (shared) passive object.
> http://brinch-hansen.net/papers/1978a.pdf

> Well, both language proposals are much higher level with respect to
> parallelism than what is planned into the new brave C++0x.

DP is NOT as expensive as you claim it is. E.g. each object starts it's OWN
thread. No way!

;^|

== 2 of 2 ==
Date: Mon, Sep 29 2008 5:05 am
From: "Chris M. Thomasson"

[`comp.lang.c++' added; this message was multi-posted

Here is link to context which does not show up on `comp.lang.c++':

http://groups.google.com/group/comp.programming.threads/browse_frm/thread/a4a668e20be49644

]

"gremlin" <gremlin@rosetattoo.com> wrote in message
news:aNGdnZOrE-PTXX3VnZ2dnUVZ_hGdnZ2d@comcast.com...
>
> "Chris M. Thomasson" <no@spam.invalid> wrote in message
> news:_XRDk.1159$FV4.492@newsfe07.iad...
>> "gremlin" <gremlin@rosetattoo.com> wrote in message
>> news:AeGdnQFC5KvsMELVnZ2dnUVZ_oninZ2d@comcast.com...
>>> http://www.cilk.com/multicore-blog/bid/6703/C-Inventor-Bjarne-Stroustrup-answers-the-Multicore-Proust-Questionnaire
>>
>> Why did you multi-post this?
>>
>> http://groups.google.com/group/comp.lang.c++/browse_frm/thread/58c6635e208a36bf
>
> thought it might be of interest to several programming groups.

Well, if you forgot a group; fine. However, it's better to simply cross-post
instead of multi-post. I added `comp.lang.c++' and all follow-ups will
include that group. See, responders on this group will not be able to see
correspondence on others groups that you posted to (e.g., comp.lang.c++).

> bad move?

Na; you most likely forgot to add a C++ list in the message broadcast.

;^)

==============================================================================
TOPIC: ODR: A simple question
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/d65f12d76742875b?hl=en
==============================================================================

== 1 of 3 ==
Date: Mon, Sep 29 2008 3:01 am
From: ebony.soft@gmail.com

Dear all
Hi

I encountered a simple but IMO important problem about the C++ linkage
model and One Definition Rule. Why the following code link?

file1.cpp
int x;

file2.cpp
double x;

x was defined in two different translation units with different types.
It breaks the ODR.
The following code is also linked:

file1.cpp
int x;

file2.cpp
extern double x;
It is obvious the type x in declaration and definition are different.
I ran and tested codes in Visual Studio 6.0 and .Net 2005.

Thank you in advance
- Saeed Amrollahi

== 2 of 3 ==
Date: Mon, Sep 29 2008 4:17 am
From: Pete Becker

On 2008-09-29 06:01:07 -0400, ebony.soft@gmail.com said:

>
> I encountered a simple but IMO important problem about the C++ linkage
> model and One Definition Rule. Why the following code link?
>
> file1.cpp
> int x;
>
> file2.cpp
> double x;
>
> x was defined in two different translation units with different types.
> It breaks the ODR.

The language definition doesn't require compilers to diagnose
violations of the ODR. Code like this has undefined behavior. As a
practical matter, recognizing errors like this is expensive, given
C++'s separate compilation model.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

== 3 of 3 ==
Date: Mon, Sep 29 2008 6:44 am
From: James Kanze

On Sep 29, 1:17 pm, Pete Becker <p...@versatilecoding.com> wrote:
> On 2008-09-29 06:01:07 -0400, ebony.s...@gmail.com said:
> > I encountered a simple but IMO important problem about the
> > C++ linkage model and One Definition Rule. Why the following
> > code link?

> > file1.cpp
> > int x;

> > file2.cpp
> > double x;

> > x was defined in two different translation units with
> > different types. It breaks the ODR.

> The language definition doesn't require compilers to diagnose
> violations of the ODR. Code like this has undefined behavior. As a
> practical matter, recognizing errors like this is expensive, given
> C++'s separate compilation model.

And the relatively low quality of most linkers. It wouldn't be
very hard to implement, if the linker supported it. For
historical reasons, most linkers don't.

==============================================================================
TOPIC: std:sort predicate function optional arguments
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/919bd84768c51f2e?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Sep 29 2008 3:01 am
From: Ganesh

hi !

Can the predicate function used in std::sort take optional
arguments ? For instance. I have a class Point. I create a vector of
this and then want to compare the slopes of these points with respect
to another point of the same class (Graham's convex hull algorithm
anyone ?)

ganesh

== 2 of 2 ==
Date: Mon, Sep 29 2008 3:50 am
From: Xiaobin Huang

On 9月29日, 下午6时01分, Ganesh <ganesh.i...@gmail.com> wrote:
> hi !
>
> Can the predicate function used in std::sort take optional
> arguments ? For instance. I have a class Point. I create a vector of
> this and then want to compare the slopes of these points with respect
> to another point of the same class (Graham's convex hull algorithm
> anyone ?)
>
> ganesh

you can provide your own predicate.

class cmp {
public:
cmp(...) {
// init thePoint_
}
bool operator() (point const& lh, point const& rh) {
// ...
}
private:
point thePoint_;
};

==============================================================================
TOPIC: new multicore programming docs for GCC and Visual Studio
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/721c9d1676786578?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Sep 29 2008 6:02 am
From: "Chris M. Thomasson"

[comp.lang.c++ added...

http://groups.google.com/group/comp.programming.threads/browse_frm/thread/e753228b20889a11

]

"Dmitriy V'jukov" <dvyukov@gmail.com> wrote in message
news:4306b243-2d28-4ec6-a275-883db633b9b8@l42g2000hsc.googlegroups.com...
On Sep 29, 4:23 pm, "Chris M. Thomasson" <n...@spam.invalid> wrote:
>
> > >> Are you using something like the algorithm in TBB?
> >
> > >http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TM-548.pdf
> >
> > > TBB is based on MIT's Cilk work:
> > >http://www.cilk.com/multicore-blog/bid/5607/Cilk-Wins-Most-Influentia...
> >
> > How does the internal low-level impl compare to the following:
> >
> > http://www.cs.bgu.ac.il/~hendlerd/papers/dynamic-size-deque.pdf
> >
> > I am looking for raw pseudo-code for atomic deque internal impl
> > details...
> > AFAICT, this work from SUN would scale better than Clik. Please correct
> > me
> > if I am way off base here. It seems like spawning a successor thread has
> > overheads... Humm. Pleas try to bear with me here; okay? Correct my
> > ignorance on Clik's work-stealing internal impl... Well, let me pick an
> > impl
> > to focus on... Say, DEC Alpha?

> AFAIK, in early days Cilk's work-stealing deque used mutex-based
> pop(). But I remember there was some mentions of non-blocking
> algorithms in the Cilk's papers, something like "some people point us
> that it's possible to implement work-stealing deque in completely non-
> blocking manner". And I don't know whether non-blocking deque was
> finally incorporated into Cilk.

> If mutex is spin-mutex (i.e. there is only 1 atomic RMW per lock/
> unlock) and stealing is rare, then mutex-based deque is nearly the
> same as non-blocking deque with 1 RMW... provided that push() doesn't
> use mutex. And provided that atomic RMW has the same cost as StoreLoad
> memory fence (x86).

You mean:

1 atomic RMW and 1 StoreLoad membar for lock
1 atomic RMW and 1 LoadStore membar for unlock

2 atomics, and 2 membars; fairly expensive... Well... You indeed have a good
point in the case that stealing is rare...

== 2 of 2 ==
Date: Mon, Sep 29 2008 6:06 am
From: "Dmitriy V'jukov"

On Sep 29, 5:02 pm, "Chris M. Thomasson" <n...@spam.invalid> wrote:

> You mean:
>
> 1 atomic RMW and 1 StoreLoad membar for lock
> 1 atomic RMW and 1 LoadStore membar for unlock
>
> 2 atomics, and 2 membars; fairly expensive... Well... You indeed have a good
> point in the case that stealing is rare...

No, I mean for spin-mutex:
1 atomic RMW + 1 StoreLoad membar for lock
store-release for unlock

Which for x86 means:
1 atomic RMW for lock (StoreLoad is implied, and so basically
costless)
plain store for unlock (release is implied)

Dmitriy V'jukov

==============================================================================
TOPIC: cout vs std::cout
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/4f48acdaa9e16cee?hl=en
==============================================================================

== 1 of 4 ==
Date: Mon, Sep 29 2008 7:27 am
From: ytrembla@nyx.nyx.net (Yannick Tremblay)

In article <gbonpf$2ve$1@cb.generation-online.de>,
Hendrik Schober <spamtrap@gmx.de> wrote:
>Mark Casternoff wrote:
> OTOH, I have used #2 for about a decade now and worked on projects
> where it was required that /all/ identifiers have to be within some
> namespaces and that /all/ identifiers are to be addressed with their
> fully qualified name. So I /know/ that it isn't hard to read code
> which fully qualifies all identifiers after a short while of looking
> at such code (that's a "short" as in "weeks" or "months"). And this
> isn't only my personal POV. Most of the time I worked under the rule
> that using declarations (and even using directives!) where allowed
> within any local scopes not bigger than a function, but this was
> rarely ever used by anyone (with "rarely" meaning "far less than 1%
> of the project's code"). I suppose that was because, after a short
> while, people who really tried to work that way liked code better
> that used fully qualified identifiers. (I abhor code that uses a
> naked 'list' beside a naked 'cout', as I have no idea whether that
> is 'std::list' or some other identifier.)
>
> What I've learned, though, is to avoid creating namespaces which are
> long and hard to type right even after weeks ('StringUtility') of
> usage. :)

So essentially, the virtual ban on "using" coupled with the compulsory
namespace for everything leads to the creation of crytic namespace
identifiers?

<Ridiculous example>
Instead of the self explanatory "StringUtility", the
namespace becomes "su" and the call to su::strip(std::string const &)
which was meant to strip a string from trailing whitespaces
accidentally resolve to su::strip(std::string const &) from the su
namespace that a different developper created as a short for SuperUser
namespace, attempting to strip user rights from the passed string?
</Ridiculous example>

Personally, I try to place most things in namespaces. I very very
rarely use "using std;" because I find it far too broad and remove
clarity to the code. "list" for example is a very common word that
only has meaning with a context. std::list is clear. But the ban on
using directive of more than function scope: No thanks!

Yannick

== 2 of 4 ==
Date: Mon, Sep 29 2008 7:38 am
From: ytrembla@nyx.nyx.net (Yannick Tremblay)

In article <6ka9p5F6fbcoU1@mid.dfncis.de>,
Matthias Buelow <mkb@incubus.de> wrote:
>Mark Casternoff wrote:
>
>> I've seen both methods in code, but I'm seeing #2 a lot more frequently.
>
>It's because many C++ programmers prefer long-winded bureaucracy over
>conciseness or even (shock!) simplicity. :) Why do you think the STL is
>like it is?
>I've never heard a good reason why one shouldn't do a "using namespace
>std;" at the beginning of every compilation unit. Maybe there're some
>special cases where it might cause problems but usually not using that
>is rather nonsensical, imho. The std:: is just clutter and that's
>usually bad in a program.

The std:: namespace contains an awful lot of identifiers that use very
simple common words.

If you remove std:: namespace an put everything global, the following
becomes very undesirable since you would have trouble figuring out
which "map"

namespace DoraTheExplorer
{
class map
{
//
};

}
//////////////////
#include "Dora.h"
#include <map>

using namespace std; // or remove std:: altogether
using namespace DoraTheExplorer;

int main()
{
map theMap; // should this compile or error
// due to missing template arguments?
}

== 3 of 4 ==
Date: Mon, Sep 29 2008 8:01 am
From: Hendrik Schober

Yannick Tremblay wrote:
> In article <gbonpf$2ve$1@cb.generation-online.de>,
> Hendrik Schober <spamtrap@gmx.de> wrote:
>> Mark Casternoff wrote:
>> OTOH, I have used #2 for about a decade now and worked on projects
>> where it was required that /all/ identifiers have to be within some
>> namespaces and that /all/ identifiers are to be addressed with their
>> fully qualified name. So I /know/ that it isn't hard to read code
>> which fully qualifies all identifiers after a short while of looking
>> at such code (that's a "short" as in "weeks" or "months"). And this
>> isn't only my personal POV. Most of the time I worked under the rule
>> that using declarations (and even using directives!) where allowed
>> within any local scopes not bigger than a function, but this was
>> rarely ever used by anyone (with "rarely" meaning "far less than 1%
>> of the project's code"). I suppose that was because, after a short
>> while, people who really tried to work that way liked code better
>> that used fully qualified identifiers. (I abhor code that uses a
>> naked 'list' beside a naked 'cout', as I have no idea whether that
>> is 'std::list' or some other identifier.)
>>
>> What I've learned, though, is to avoid creating namespaces which are
>> long and hard to type right even after weeks ('StringUtility') of
>> usage. :)
>
> So essentially, the virtual ban on "using" coupled with the compulsory
> namespace for everything leads to the creation of crytic namespace
> identifiers?
> [Ridiculous example deleted]

No. The next project introduced its string utilities
in a namespace 'Strings'.

> Yannick

Schobi

== 4 of 4 ==
Date: Mon, Sep 29 2008 8:04 am
From: Matthias Buelow

Yannick Tremblay wrote:

> using namespace std; // or remove std:: altogether
> using namespace DoraTheExplorer;

...^ here

> int main()
> {
> map theMap; // should this compile or error
> // due to missing template arguments?

It should wail about symbol collision...^

Dunno if it does (too lazy^Wbusy to check now), b0rk3d as C++ is, it
probably doesn't.

==============================================================================
TOPIC: CopyConstructible requirement for standard library containers
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/f8121f7c614c7949?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Sep 29 2008 8:00 am
From: "subramanian100in@yahoo.com, India"

Suppose 'Test' is a class.

In order to use 'Test' as element type for a standard library
container, say, vector, 'Test' class must be CopyConstructible and
Assignable.

Does CopyConstructible mean that the class must support both direct-
initialization and copy-initialization ?

Kindly clarify.

Thanks
V.Subramanian

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c++"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c++?hl=en

To unsubscribe from this group, send email to comp.lang.c+++unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c++/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

soft and program

Monday, September 29, 2008

25 new messages in 11 topics - digest

No comments:

Blog Archive

About Me