soft and program: comp.lang.c++ - 20 new messages in 12 topics

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

comp.lang.c++@googlegroups.com

Today's topics:

==============================================================================
TOPIC: The last few Oppertunities
http://groups.google.com/group/comp.lang.c++/t/72e843cee863a6d6?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Dec 31 2008 9:50 am
From: Juha Nieminen

secrito1@gmail.com wrote:
> I am formulating a society of computer programmers where we discuss
> anything important and casual secretly to protect ourselves of *****.
> if u are interested in joining a secret group called *****, please
> contact me by email only any questions are exceptable. Thanks.

Ooh! Supersecret l33t h4x0rz FTW!

== 2 of 2 ==
Date: Wed, Dec 31 2008 4:13 pm
From: red floyd

Juha Nieminen wrote:
> secrito1@gmail.com wrote:
>> I am formulating a society of computer programmers where we discuss
>> anything important and casual secretly to protect ourselves of *****.
>> if u are interested in joining a secret group called *****, please
>> contact me by email only any questions are exceptable. Thanks.
>
> Ooh! Supersecret l33t h4x0rz FTW!

I think he wants to keep it secret because he's embarrassed about his
spelling.

==============================================================================
TOPIC: function prototype has throw
http://groups.google.com/group/comp.lang.c++/t/1da830ebfab98681?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Dec 31 2008 11:39 am
From: purpletech@gmail.com

if a function prototype has a throw at the end what does that mean ?

thanks.

== 2 of 2 ==
Date: Wed, Dec 31 2008 1:32 pm
From: vj

i found out myself

its exception specification, to guarantee the caller that the function
will throw only from the specified list

On Dec 31, 11:39 am, purplet...@gmail.com wrote:
> if a function prototype has a throw at the end what does that mean ?
>
> thanks.

==============================================================================
TOPIC: pause(), delay(), sleep()?
http://groups.google.com/group/comp.lang.c++/t/75988b3f3fddba2c?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 31 2008 11:40 am
From: Bill H

jason.cipriani@gmail.com wrote:
> On Dec 30, 11:56 pm, Bill H <will...@hotmail.com> wrote:
>> I wrote a few programs a few years back using various C packages but
>> haven't messed with it much since. I just looked back in some code I
>> managed to crank out early last year and noticed a place where I could
>> use a slight delay while I pop-up a little message box, but can't seem
>> to find the old sleep() function. I'm now using the Borland Free
>> Command Line Compiler, using the c++ compiler. I've acquired some used
>> books on C++, but the pause(), delay(), sleep() stuff ain't even in the
>> index. What is the new way to make this happen? Thanks.
>
> AFAIK Borland's compiler is only for Windows, this implies that your
> platform is Windows. Therefore, the function you are looking for is
> probably the Windows API function Sleep(). See documentation here:
>
> http://msdn.microsoft.com/en-us/library/ms686298(VS.85).aspx
>
> HTH,
> Jason

Thanks, Yes, I am programming in a command window under WinXP. The link
above seems like it might provide my answer. Thanks again.

==============================================================================
TOPIC: Custom STL in place allocator crashed
http://groups.google.com/group/comp.lang.c++/t/0a248a2e913ba6c1?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 31 2008 11:42 am
From: "Thomas J. Gritzan"

zr schrieb:
> On Dec 31, 4:20 am, "Thomas J. Gritzan" <phygon_antis...@gmx.de>
> wrote:
>> Allen schrieb:
>>
>>> On 12月31日, 上午9时14分, Allen <Allen.Che...@gmail.com> wrote:
>>>> There is a custom STL in place allocator in Google codes.
>>>> The InPlaceAlloc.h URL ishttp://www.google.com/codesearch/p?hl=en#HClD5fLW7P8/InPlaceAlloc.h&q...
>>>> #include <vector>
>>>> #include "InPlaceAlloc.h"
>>>> int main()
>>>> {
>>>> char * buffer = new char[1024];
>> Avoid new[]. Avoid delete[]. Except buried down in a class or library.
>> You can use std::vector to allocate a buffer:
>>
>> std::vector<char> buffer(1024);
>>
> Why is using a vector to allocate better than using new[] and delete
> []?

In general, because it lessens the risk of memory leaks.
With new[], you have to delete[] in every possible code path, which can
be quite complicated in some functions, especially if you allocate
multiple arrays.
It is very hard to make it exception safe. Most people don't even try it
and ignore that issue. With std::vector or any other smart-pointer or
RAII construct, the objects will be destroyed even then.

In this special case, the buffer is used by the other std::vector and
its allocator. The code delete[]s the buffer to early while it is still
in use. But destructors run in reverse order to its constructor calls,
so if you use std::vector in this case, the buffer won't be deallocated
until the vector that uses this buffer is alive.

--
Thomas

==============================================================================
TOPIC: testsuite to validate POD argument passing between C and C++
http://groups.google.com/group/comp.lang.c++/t/3f7162262fcbaf98?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 31 2008 12:14 pm
From: Francis Glassborow

alfps wrote:
> On 27 Des, 14:49, kama...@gmail.com wrote:
>> { Note cross-post to clc++m. -mod }
>>
>> Hello,
>>
>> I am looking for a testsuite which validates that POD can be passed
>> between modules written in C and ones writtn in C++ but with C
>> interfaces. If there is a standard body that has identified valid/
>> invalid behaviour in this regard and the test suite validates the
>> same, pl let me know the details.
>
> The question is unclear and to my mind meaningless.
>
> Please try to provide a concrete example.
>
> With complete code that can be compiled (or not, if that is the
> point).
>
>

I think that the OP is a bit confused. A POD can always be used in mixed
C/C++ code PROVIDING that the C and C++ compilers are compatible. That
has nothing to do with the code itself and everything to do with the
compilers.

--
Note that robinton.demon.co.uk addresses are no longer valid.

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

==============================================================================
TOPIC: Returning a private nested class of a class template
http://groups.google.com/group/comp.lang.c++/t/324488f7f247fb0a?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Dec 31 2008 2:26 pm
From: ymost@hotmail.com

Hi,
I have a class with a friend function that returns an instance of a
private nested class:

//--------------------------------------------------
class A {
class B {};
friend B func(double x);
};

A::B func(double x) {return A::B();}

int main() {
func(1.2);
return 0;
}
//------------------------------------------------

This code compiles and runs on the MS Visual C++ 2008 compiler.
However, if I use a class template instead:

//--------------------------------------------------
template<typename T> class A {
class B {};
friend B func(T x);
};

template<typename T> typename A<T>::B func(T x) {return A<T>::B();}

int main() {
func(1.2); // <-- error received here
return 0;
}
//------------------------------------------------

I get an error:
error C2248: 'A<T>::B' : cannot access private class declared in class
'A<T>'.
Notice the error is in 'main', and not in the function definition, so
I don't think the problem is with the friend declaration.

So is returning an instance of a private nested class legal or not?

== 2 of 2 ==
Date: Wed, Dec 31 2008 4:15 pm
From: red floyd

ymost@hotmail.com wrote:
> Hi,
> I have a class with a friend function that returns an instance of a
> private nested class:
>
> //--------------------------------------------------
> class A {
> class B {};
> friend B func(double x);
> };
>
> A::B func(double x) {return A::B();}
>
> int main() {
> func(1.2);
> return 0;
> }
> //------------------------------------------------
>
> This code compiles and runs on the MS Visual C++ 2008 compiler.
> However, if I use a class template instead:
>
> //--------------------------------------------------
> template<typename T> class A {
> class B {};
> friend B func(T x);
> };
>
> template<typename T> typename A<T>::B func(T x) {return A<T>::B();}
>
> int main() {
> func(1.2); // <-- error received here
> return 0;
> }
> //------------------------------------------------
>
> I get an error:
> error C2248: 'A<T>::B' : cannot access private class declared in class
> 'A<T>'.
> Notice the error is in 'main', and not in the function definition, so
> I don't think the problem is with the friend declaration.
>
> So is returning an instance of a private nested class legal or not?

No, it's not legal, because the destructor for the private class needs
to run.

==============================================================================
TOPIC: MFC Golmine site updated http://mfcgoldmine.by.ru/index.html
http://groups.google.com/group/comp.lang.c++/t/cd8333fd25b20df2?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Dec 31 2008 3:30 pm
From: "Brian Muth"

This site sucks. Don't go there. If you do, make sure your "shields are up".

== 2 of 2 ==
Date: Wed, Dec 31 2008 4:11 pm
From: "Jonathan Wood"

"Brian Muth" <bmuth@mvps.org> wrote in message
news:uvGpU$5aJHA.1676@TK2MSFTNGP03.phx.gbl...

> This site sucks. Don't go there. If you do, make sure your "shields are
> up".

I tried it earlier and don't want to try again. This post really has no
business here.

Still, I'm curious as to why you say it sucks.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com
http://www.softcircuits.com/blog/

==============================================================================
TOPIC: "#define" vs "const int"
http://groups.google.com/group/comp.lang.c++/t/6af68a548d4c7cba?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Dec 31 2008 6:13 pm
From: blargg.h4g@gishpuppy.com (blargg)

Pete Becker wrote:
> Rolf Magnus said:
> > Pete Becker wrote:
> >> Jeff Schwab said:
> >>> Pete Becker wrote:
> >>>> Pascal J. Bourguignon said:
> >>>>> So you really don't want to think about these matters. Just write:
> >>>>> const int foo=4; since that's what the language provides you, and
> >>>>> since it gives more information than #define foo 4 to the compiler,
> >>>>> chances are it will be able to generate more optimized code, but you
> >>>>> shouldn't care.
> >>>>
> >>>> What additional information does it give the compiler? Obviously,
> >>>> unlike a manifest constant, the code could take its address, but that
> >>>> inhibits rather than enhances optimization.
> >>>
> >>> It's not so much that "const foo" gives the compiler additional
> >>> information, but that the macro potentially hides information, e.g.
> >>> replacing all uses of the name "foo" within subsequent namespaces and
> >>> function definitions.
> >>
> >> Yes, eveyone knows that macros are evil. But they're not as evil as
> >> everyone thinks they are.
> >
> > It doesn't matter much how "evil" they are. If there is a better way to do
> > the same, then why not use that? Macros are only used as replacements for
> > constants because people are used to that from C, which lacks support for
> > real constants. Otherwise, nobody would even think about using a macro for
> > that.
>
> Sigh. Please note the comment that I replied to originally. I really
> don't want to get into a pissing match about the merits of macros.

Can't you figure it out? Macros are EVIL. That means we CANNOT even
talk about them or think about their behavior. We must convert
everyone into a believer and ensure they never discuss macros, other
than to argue against all mention/use of them. Our minds are fragile,
and the moment we start to contemplate macros versus alternatives,
even if only hypothetically in order to shed light on other issues, we
will lose all discipline and plunge ourselves into pre-C++ darkness.

== 2 of 2 ==
Date: Wed, Dec 31 2008 6:24 pm
From: Pete Becker

On 2008-12-31 21:13:57 -0500, blargg.h4g@gishpuppy.com (blargg) said:

>
> Can't you figure it out? Macros are EVIL. That means we CANNOT even
> talk about them or think about their behavior. We must convert
> everyone into a believer and ensure they never discuss macros, other
> than to argue against all mention/use of them. Our minds are fragile,
> and the moment we start to contemplate macros versus alternatives,
> even if only hypothetically in order to shed light on other issues, we
> will lose all discipline and plunge ourselves into pre-C++ darkness.

<g>

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

==============================================================================
TOPIC: a simple question
http://groups.google.com/group/comp.lang.c++/t/5024236a053d7dcc?hl=en
==============================================================================

== 1 of 4 ==
Date: Wed, Dec 31 2008 6:37 pm
From: hpsoar

Hello every one, I'm new here, and I'm also new to C++, I have just
learned a C++ course, and I want to know what you usually do with C++.
I will appreciate it if anyone gives me an answer.

== 2 of 4 ==
Date: Wed, Dec 31 2008 8:19 pm
From: Sam

hpsoar writes:

> Hello every one, I'm new here, and I'm also new to C++, I have just
> learned a C++ course, and I want to know what you usually do with C++.

I use it to earn a living.

== 3 of 4 ==
Date: Wed, Dec 31 2008 8:43 pm
From: hpsoar

On 1月1日, 下午12时19分, Sam <s...@email-scan.com> wrote:
> application_pgp-signature_part
> < 1K查看下载
>
> hpsoar writes:
> > Hello every one, I'm new here, and I'm also new to C++, I have just
> > learned a C++ course, and I want to know what you usually do with C++.
>
> I use it to earn a living.
Can you give some details, such as what kind of project you do with C+
+

== 4 of 4 ==
Date: Wed, Dec 31 2008 11:29 pm
From: red floyd

hpsoar wrote:
> On 1月1日, 下午12时19分, Sam <s...@email-scan.com> wrote:
>> application_pgp-signature_part
>> < 1K查看下载
>>
>> hpsoar writes:
>>> Hello every one, I'm new here, and I'm also new to C++, I have just
>>> learned a C++ course, and I want to know what you usually do with C++.
>> I use it to earn a living.
> Can you give some details, such as what kind of project you do with C+
> +

I wrote missile avionics software, as well as missile defense algorithms.

==============================================================================
TOPIC: eigenheimzulage forum,kredit immobilienfinanzierung,günstige
immobilienkredite,hypotheken darlen,die eigenheimzulage in,
http://groups.google.com/group/comp.lang.c++/t/0f99b8882d52e100?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 31 2008 8:52 pm
From: ramesh23812@googlemail.com

eigenheimzulage forum,kredit immobilienfinanzierung,günstige
immobilienkredite,hypotheken darlen,die eigenheimzulage in,

immobilienfinanzierung darlehen baufinanzierung zins vergleich in
Kirgistan
kreditrechner baufinanzierung tilgung bauspardarlehen in Deggendorf
hypothek zinssatz darlehen baufinanzierung in Neuseeland
bauspardarlehen im vergleich bau finanzierung zins in Suriname
kredit hauskauf eigenheimzulage einkommen in Zerbst
mhs immobilienfinanzierung finanzierung immobilie ausland in Georgien
finanzierung haus rechner banken hypothek in Syrien
baufinanzierung zinsen kredit aufs haus in Kap Verde

==============================================================================
TOPIC: C++ improvements: my 2008 summary
http://groups.google.com/group/comp.lang.c++/t/bd9fbd78c03cf774?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 31 2008 9:29 pm
From: Grizlyk

To continue some ideas of message "C++ improvements: core and user
properties, default compiler ".

Hi, boys and girls, what news on Pluke :)?

Concerning the C++ improvements.

The proccess hardly move and there are nothing to be proud, but some
things are done.

In spite of the fact, that there are no great interest for the ideas
in the group, i am publishing the snapshort of some parts of current
state of the development, because i myself never did the kind of work
(programming language improvement) befor and the improvements are not
private, so i will not angry if anyone will make it faster and better
than i do.

1. Human-oriented representation of C++ source code.

The original C++ language, divided into two parts (cC++/uC++) must
have representation of source code for each part for human usage.

While considering the representation we can find, that with the user
part (uC++), to support OO design we neeed to have ability to easy
export not only interfaces of code, but implementations - parts of
open source code and copirighted compiled code from one project to
another.

The current C++ way of exporting implementation, inherited from C, is
creation a solid "compilation units", source code of which is hard
linked (often with the help of preprocessor) with development
environment of source project. The linkage is so deep, that often even
just a project itself can not be exported to other compatible machine
without valuable changes of the project, but export a part of the code
into other project is very non-trivial thing.

- The problem here is much more complex source code for C++, than for
C.

The problem is representation of source code. The current way of
abstracion as "some units with interface and implementation" by
"class" or by "compilation unit" is not enough to export
implementation of methods to increase reusage of code. The _effective_
instantiation of OO messages in language with reach low-level
properties requires export implementation of single, separated methods
of class or namespace.

- The problem here is the fundamental problem of "function".

"Function" has "interface" (list of parameters and return value), but
links of the function to other, external resources (resources are not
defined inside the function local scope), have no any "interfaces". I
decided, that the unspecified, unlimited, unchecked access to external
resources makes "function" open in bad reason - inportable.

- The problems of C++ name lookup.

The related question is the fact, the C++, unlike C, has non-boolean
name lookup, in other words, names of C++ can be placed not only in
global or local scope, that is why C++ can not just extend simple
rules of C-style boolean name lookup.

Using the several facts i offer to consider "function" as an
abstraction with pair of interfaces: "front end interface" (ordinary)
and "back end interface" (new). The goal of the rear interface is
- explitely specification of external resources for each function (the
same as now ordinary function explitely specifies own ordinary
interface);
- using types to the kind of specification of externals.

The way to move software from one project to another is "on fly"
substitution of correct type of externals (applying correct type of
back end interface) during insertion code from one project to another.

2. What kind of syntax can be introduced for C++ to express back-end
function interface, to make typed access to external resource?

Any thing can not be infinitly improved by a little inheritance of
original thing, because during the evolution we find a point, where
valuable changes must be done to reach result and the new thing will
be enogh incompatible with original thing.

The all above force me to the idea, that C++ can not be easy improved
into the pair c/u, the source language requires dramatic, important,
valueable and visible changes, to lose all inherited "bad" prorerties
and new language can not be compatible with old C++ (old C++ can be
represented as dialect of new only).

It is not very good news, because any easy improvements of C++ are
much easy to do than invention of quite new language.

The idea of the explicit declaration of externals for each portable
part of code has technical problems, the declarations of external are
hard to be coded, in fact all not explicitly declared names will be
errors.

But with IDE, integrated into language, as uC++ does, the most trivial
way as "hit the problem by own forehead" can be used with success, the
IDE can hide any trivial operations, finds new names from code,
creates records for the names in declaration of back end interface and
user will control the existed records only.

The fact of IDE intergrated into language changes the syntax very
much, in fact the presence of IDE is the similar to presence of
english letters and digits in keyboard.

I am not sure, that function with two interfaces is smart idea and i
have no "complete theory of comparison the two kind of functions with
program design", but some artificial examples looks quite successfull
and now i consider the idea as working.

3. Summary.

All encountered problems of C++ improvements still can not set the
process of improvement into state of separated properties to upgrade,
i still did not find independed "bones" of uC++, from any
improvements.

best regards

==============================================================================
TOPIC: map of std::complex
http://groups.google.com/group/comp.lang.c++/t/926f261ed6642f3b?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 31 2008 9:34 pm
From: "Joe Smith"

James Kanze wrote:
>On Dec 29, 11:31 pm, "Joe Smith" <unknown_kev_...@hotmail.com> wrote:
>> "James Kanze" wrote:
>> >On Dec 29, 1:08 am, Juha Nieminen <nos...@thanks.invalid> wrote:
>> >> Wouldn't that be the same as:
>> >> return lhs.real() < rhs.real() ||
>> >> (lhs.real() == rhs.real() && lhs.imag() < rhs.imag());
>
>> >Or even the canonical:
>
>> > return lhs.real() < rhs.real() ||
>> > (!(rhs.real() < lhs.real()) && lhs.imag() < rhs.imag());
>
>> >(Personally, I prefer your version, and find it more natural.
>> >But the above is what the standard library usually uses.)
>
>> His suggestion is the most natural, but the latter has the
>> advantage of not needing a working ==.
>
>Do you have some types where < is defined, but there is no
>working ==? Such types wouldn't get through code review at the
>places I've worked.
>
>> They are also not equivlent: lhs as 6+6i and rhs as 5+7i gives
>> different results for the two.
>
>They both evaluate to false, which is what I'd expect. If they
>do give different results, the definitions of < and == aren't
>compatible.
>

Right. I origninally misread the second example,
as

return lhs.real() < rhs.real() ||
(!(LHS.real() < RHS.real()) && lhs.imag() < rhs.imag());

(Caps for emphasis).

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

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

Thursday, January 1, 2009

comp.lang.c++ - 20 new messages in 12 topics - digest

No comments:

Blog Archive

About Me