soft and program: comp.lang.c++ - 26 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: Exception Misconceptions: Exceptions are for unrecoverable errors.
http://groups.google.com/group/comp.lang.c++/t/786cfdf0ab25866d?hl=en
==============================================================================

== 1 of 8 ==
Date: Wed, Dec 23 2009 3:04 pm
From: Branimir Maksimovic

dragan wrote:
> Saying "Exceptions are for unrecoverable errors" seems to imply that they
> are to be used only or mostly in such situations.

I use exception everywhere instead of error code return from function.
It is easier to program if you get rid of statements like
if(f()==error){ return error or handle error }

Also I have very few try's only in places for top level cleanup...
Exceptions are mechanism to make code cleaner...and to get rid of
error codes as return values from functions..

Greets

== 2 of 8 ==
Date: Wed, Dec 23 2009 3:12 pm
From: Branimir Maksimovic

Kaz Kylheku wrote:
> On 2009-12-22, Vladimir Jovic <vladaspams@gmail.com> wrote:
>> Stefan Ram wrote:
>> [snip]
>>> More elegantly? Actually, for correct and secure C++ code,
>>> all functions need to be written to be »exception safe«, but
>>> only a minority of C++ programmers does so or even is aware
>>> of it.
>>>
>> Why?
>
> The above is false. Exception-safe code is needed to write code
> that avoids resource leaks in the face of an exception.
>
> For instance:
>
> {
> char *p = new char[256];
> f();
> }

hm , why would you do this?

isnt't that
{
vector<char> p(256);
f();
}
is simpler?
You can always get &p[0] and use it like buffer and you get
size for free....

>
> If f throws an exception, this statement block is abandoned, and the
> allocated memory is leaked. Of course other kinds of resources can be
> leaked, like handles to operating system resources such as open files.
>
I use vectors ....strings and such stuff.

Greets

--
http://maxa.homedns.org/

== 3 of 8 ==
Date: Wed, Dec 23 2009 3:21 pm
From: Branimir Maksimovic

tanix wrote:
> In article <hgskgk$kc2$1@news.albasani.net>, Vladimir Jovic <vladaspams@gmail.com> wrote:
> C++ would probably be benefited tremendously if it adopted some
> of the central Java concept, such as GC, threads and GUI.

GC is heavy performance killer especially on multiprocessor systems
in combination with threads....it is slow, complex and inefficient...
It has sense in functional languages because of recursion, but
in java?!
GC without threads, but processes and shared memory instead, is ok on
multiprocessor systems...

>
> Except that would require an equivalent of a virtual machine
> underneath.

virtual machine is also heavy performance killer...

>
> And that is one of central issues with Java.

Yes.
I think java is designed in such way that it will still be slow in
comparison to other compiled languages...if it is compiled
language.

Greets

--
http://maxa.homedns.org/

== 4 of 8 ==
Date: Wed, Dec 23 2009 3:51 pm
From: Kaz Kylheku

On 2009-12-23, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
> Kaz Kylheku wrote:
>> On 2009-12-22, Vladimir Jovic <vladaspams@gmail.com> wrote:
>>> Stefan Ram wrote:
>>> [snip]
>>>> More elegantly? Actually, for correct and secure C++ code,
>>>> all functions need to be written to be »exception safe«, but
>>>> only a minority of C++ programmers does so or even is aware
>>>> of it.
>>>>
>>> Why?
>>
>> The above is false. Exception-safe code is needed to write code
>> that avoids resource leaks in the face of an exception.
>>
>> For instance:
>>
>> {
>> char *p = new char[256];
>> f();
>> }
>
> hm , why would you do this?

To demonstrate one way in which code fails to be exception safe.

> isnt't that
> {
> vector<char> p(256);
> f();
> }
> is simpler?

This code no longer demonstrates a resource leak in the face of an exception,
and so it would not have made a sutitable example to accompany my article.

Doh?

== 5 of 8 ==
Date: Wed, Dec 23 2009 4:06 pm
From: Kaz Kylheku

On 2009-12-23, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
> tanix wrote:
>> In article <hgskgk$kc2$1@news.albasani.net>, Vladimir Jovic <vladaspams@gmail.com> wrote:
>> C++ would probably be benefited tremendously if it adopted some
>> of the central Java concept, such as GC, threads and GUI.
>
> GC is heavy performance killer especially on multiprocessor systems

Is not.

> in combination with threads....it is slow, complex and inefficient...

Religious belief.

> It has sense in functional languages because of recursion, but
> in java?!

Java has recursion. Moreover, there are functional languages built on the Java
platform.

Recursion is not directly connected to the need for garbage collection; this is
some kind of strange misconception.

> GC without threads, but processes and shared memory instead, is ok on
> multiprocessor systems...

GC is very efficient from an SMP point of view, because it allows
for immutable objects to be truly immutable, over most of their
lifetime. No book-keeping operations have to be performed on objects
that are just passed around throughout the program (such as bumping
refcounts up and down).

No storage reclamation strategy is free of overhead. Even if your program
correctly manages memory by itself with explicit new and delete, there is a
cost.

Moreover, a poorly implemented heap allocator (like virtually
every default malloc implementation out there in the real world)
is an SMP performance killer.

Like malloc and new, GC can be badly implemented in a way that kills SMP
performance. So can any aspect a programming language implementation, including
the compiler.

If you find a sufficiently bad compiler and library for some language, you can
``prove'' any statement about how bad that language is.

>> Except that would require an equivalent of a virtual machine
>> underneath.
>
> virtual machine is also heavy performance killer...

That may be so, but GC does not require a virtual machine. GC has been used for
five decades, with natively compiled code, starting in the late 1950's on IBM
704 mainframes, as part of the Lisp run-time support.

>>
>> And that is one of central issues with Java.
>
> Yes.
> I think java is designed in such way that it will still be slow in
> comparison to other compiled languages...if it is compiled
> language.

Unfortunately, that is wishful thinking. Natively compiled Java has very little
disadvantage compared to C and C++. (Mainly in areas of doing low-level things
with memory, or directly interfacing with the ``bare iron''; the sorts
of things that are poorly supported in Java).

Java has the same low-level numeric types, and the way it deals with objects is
not much different from pointers to classes in C++.

There is no reason to expect something like a matrix multiplication with
Java arrays to be slow, when Java is compiled to native code by an optimizing
compiler.

== 6 of 8 ==
Date: Wed, Dec 23 2009 5:03 pm
From: Branimir Maksimovic

Kaz Kylheku wrote:
> On 2009-12-23, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
>> tanix wrote:
>>> In article <hgskgk$kc2$1@news.albasani.net>, Vladimir Jovic <vladaspams@gmail.com> wrote:
>>> C++ would probably be benefited tremendously if it adopted some
>>> of the central Java concept, such as GC, threads and GUI.
>> GC is heavy performance killer especially on multiprocessor systems
>
> Is not.

Hm, explain to me how can any thread, access or change any pointer in
memory without lock while gc is collecting....
There is no way for gc to collect without stopping all threads
without locking.... because gc is just another thread(s) in itself...

>
>> in combination with threads....it is slow, complex and inefficient...
>
> Religious belief.

Of course. GC is complex program that has only one purpose.
To let programmer not write free(p), but programmer
still has to write close(fd).
What's the purpose of that?

> Recursion is not directly connected to the need for garbage collection; this is
> some kind of strange misconception.
>
>> GC without threads, but processes and shared memory instead, is ok on
>> multiprocessor systems...
>
> GC is very efficient from an SMP point of view, because it allows
> for immutable objects to be truly immutable, over most of their
> lifetime. No book-keeping operations have to be performed on objects
> that are just passed around throughout the program (such as bumping
> refcounts up and down).

Refcounts are negligible in comparison to what gc is doing.
GC cannot be efficient since it cannot access program
memory while program is working....ad it doesn;t know what program is
doing... therefore GC can perform well only if it collect
when absolutely necessary. And when it had to collect performance
became catastrophic...

>
> No storage reclamation strategy is free of overhead. Even if your program
> correctly manages memory by itself with explicit new and delete, there is a
> cost.

Manual memory deallocation is simple, fast and efficient. Nothing
so complex like GC.
Cost of new and delete is nothing in comparison to GC.

>
> Moreover, a poorly implemented heap allocator (like virtually
> every default malloc implementation out there in the real world)
> is an SMP performance killer.

Yeah right. And GC thread is black magic , right?

>
> Like malloc and new, GC can be badly implemented in a way that kills SMP
> performance. So can any aspect a programming language implementation, including
> the compiler.

GC cannot be implemented efficiently since it has to mess with
memory...while other threads are working.
Add that compacting collector which have to update all references
in program and some copy/pasting... that can be optimised... to be
faster than new/delete , yeah right ;)

> That may be so, but GC does not require a virtual machine. GC has been used for
> five decades, with natively compiled code, starting in the late 1950's on IBM
> 704 mainframes, as part of the Lisp run-time support.

I used GC with C++...

>> I think java is designed in such way that it will still be slow in
>> comparison to other compiled languages...if it is compiled
>> language.
>
> Unfortunately, that is wishful thinking. Natively compiled Java has very little
> disadvantage compared to C and C++. (Mainly in areas of doing low-level things
> with memory, or directly interfacing with the ``bare iron''; the sorts
> of things that are poorly supported in Java).

I don;t want to discuss this, but it is obvious that nothing in java is
designed with performance in mind. Quite opposite....

Greets

--
http://maxa.homedns.org/

== 7 of 8 ==
Date: Wed, Dec 23 2009 10:50 pm
From: tanix@mongo.net (tanix)

In article <20091223155119.133@gmail.com>, Kaz Kylheku <kkylheku@gmail.com> wrote:
>On 2009-12-23, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
>> tanix wrote:
>>> In article <hgskgk$kc2$1@news.albasani.net>, Vladimir Jovic
> <vladaspams@gmail.com> wrote:

>>> C++ would probably be benefited tremendously if it adopted some
>>> of the central Java concept, such as GC, threads and GUI.

>> GC is heavy performance killer especially on multiprocessor systems

No idea what you are talking about.

>Is not.

>> in combination with threads....it is slow, complex and inefficient...

Where are you pulling THIS stuff from?

>Religious belief.

I'd say so.

>> It has sense in functional languages because of recursion, but
>> in java?!

No idea what does recursion has to do with it.

>Java has recursion. Moreover, there are functional languages built on the Java
>platform.

>Recursion is not directly connected to the need for garbage collection; this is
>some kind of strange misconception.

I would think recursion has 0 impact on GC from what I see.

>> GC without threads, but processes and shared memory instead, is ok on
>> multiprocessor systems...

>GC is very efficient from an SMP point of view, because it allows
>for immutable objects to be truly immutable, over most of their
>lifetime. No book-keeping operations have to be performed on objects
>that are just passed around throughout the program (such as bumping
>refcounts up and down).

>No storage reclamation strategy is free of overhead. Even if your program
>correctly manages memory by itself with explicit new and delete, there is a
>cost.

>Moreover, a poorly implemented heap allocator (like virtually
>every default malloc implementation out there in the real world)
>is an SMP performance killer.

>Like malloc and new, GC can be badly implemented in a way that kills SMP
>performance. So can any aspect a programming language implementation, including
>the compiler.

>If you find a sufficiently bad compiler and library for some language, you can
>``prove'' any statement about how bad that language is.

>>> Except that would require an equivalent of a virtual machine
>>> underneath.
>>
>> virtual machine is also heavy performance killer...

>That may be so, but GC does not require a virtual machine. GC has been used for
>five decades, with natively compiled code, starting in the late 1950's on IBM
>704 mainframes, as part of the Lisp run-time support.

>>> And that is one of central issues with Java.
>>
>> Yes.
>> I think java is designed in such way that it will still be slow in
>> comparison to other compiled languages...if it is compiled
>> language.

> Unfortunately, that is wishful thinking. Natively compiled Java
> has very little disadvantage compared to C and C++.
> (Mainly in areas of doing low-level things
> with memory, or directly interfacing with the ``bare iron''; the sorts
>of things that are poorly supported in Java).

Correct.

>Java has the same low-level numeric types, and the way it deals with
>objects is not much different from pointers to classes in C++.

Indeed. And once you deal with objects, ALL the "advantages"
in performance of C++, or even C, are gone, and you are on the
same level, if not better, depending on what kind of algorithms
are implemented to handle things like collections, such as list,
tree, hash map, map, etc.

In real programs, you don't deal with bits and bytes and register
values. You deal with OBJECTS. Once you deal with objects and do
just about any operation on them of any significance, all your
"performance" gains are gone. Non existant.

>There is no reason to expect something like a matrix multiplication with
>Java arrays to be slow, when Java is compiled to native code by an optimizing
>compiler.

Interesting point people seem to miss is that overall performance,
people seem to miss is that the overall advantage of having a JVM
is shielding you from all sorts of nasty problems when you
have to deal directly with O/S and provides you a portability
mechanism, so if you decide to wire in the GUI, threads, gc or
whatever, you don't have to worry about how it is going to run
on a different platform.

The cost of JVM in terms of memory footprint is negligible
by today's standards. Probably 10 - 15 % of your total memory
requirements for more or less complex apps that are useful
enough to even bother about.

Another point about performance is if your language has a rich
set and enough of expressive power so you do not incure that
much performance overhead. Overall impact on your performance
I'd estimate to be no more than 10-20%, probably in the worst case.

I'd be curious to see the benchmarks.

You incure performance overhead when you do lil things on a
very low level, poking into memory or what have you.

You'd have to substantiate your claims with some hard data,
and even there, it highly depends on what kind of things
your app does.

I my case, I have not noticed ANY issues with performance.
I am processing at least 1000 of articles per second, and
even that is not the limit because of my overly defensive
coding style for reading file. I bet I can double that
performance if I spend a couple of days, if not couple of
hours on it. It think at least 30 to 50% is quite realistic.

The way I check it, is to see how fast my app is processing
files by simply looking at the rate at which my drive light
flashes. In a perfect app, it would stay solid red with
very little flashing. That means it achieved a PERFECT
performance or theoretical limit, bound by disk i/o.

In my case, it does not. So, in my case, I am processing the
stuff at a rate equivalent to about 6 megs per second in
terms of disk access speed. Considering the amount of
processing going on under the hood, I'd like to see YOUR
app doing better using C++.

And what is going on during the processing is this:
you read each text line, pass it to the article parser
engine. That one detects various article headers,
saves them in the object to generate an article object.
Once the article is parsed, the filtering engine kicks
in to filter the articles on anything you can imagine,
including the article headers and article body, a pretty
heavy duty filter.

THEN, two indexes are constructed on the fly, by message
ID and by article date stamp. A typical operation
processes at least 100k articles. So, just to construct
a sorted index on that many articles is quite a trip
by itself.

So, if you consider that overall speed of processing
is not far from direct disk read, such as in file copy,
then that is good enough for a poor guy like me.

I bet you can't do it faster in C++, no matter WHAT you do.
Prolly 10-20% is the best case.

But...

What I get in return is to be able to write the GUI code
with a single language, without worrying about all sorts
of graphics toolkits. I do not have to worry about threads.
I know it will run on any platform where you can install
JVM. I have a pretty rich set of language. Just collections
alone, out of the box is all I needed to date.

And I don't have to worry of someone's toolkit or library,
all of a sudden, will either becomes a closed source, or
stops being maintained and develop. And I don't have to
worry whether there IS such a toolkit on a different
platform of IDE environment or not.

I am not even using the Java preferred IDE, becase I don't
like any of them. Just code completion alone, is my MAJOR
concern, and I mean code completion from the moment you
type your first character, that is able to recognize what
are the valid symbols in the scope I am in.

I can crank out the code probably twice as fast as they
can on those IDEs. Well, I did not try to compete with
anyone, but just for the sake of arguments. Sure, IDE
alone is not enough to achive such results. But, combined
with code design and architecture issues, a typical
significant program update, where some more or less
major functionality added, take a couple of days on average.
I don't rememober a case where I had to spend more than
a week, and I mean thing so radical, that I had to modify
at least 10 source files and change all sorts of GUI
code in several panels.

And THAT is what I am after. An OVERALL performance of
development cycle, portability, the amount of worrying,
the clarity of syntax and language notation.

I do not even use generics. A matter of principle.
I personally think it is one of the worst ideas in Java
since the day one. Most of it is bluff that translates
in orders of magnitude increase in complexity in terms
of being able to quickly read your code and understand
what it does.

I work on my code by looking at some scren for a couple
of seconds and I can see what is going on there.
I do not need to spend half an hour staring at some
hieroghlyphs from Martians. I don't have that time.

My brain is not overloaded with all sorts of useless
bells and whistles, taking most of my brain processing
time just to understand those utterly unintuitive
constructs and tricks.

So far, never regretted it.

In other words, just about ALL I have to worry is a single
something, a single language, a single syntax, a single
set of tricks.

Just the fact of me being able to run my app on Windows
and linux without even recompiling it, as I did,
wins the argument hands down, no matter what kind of artument its.

Simple as that.

But that is for ME. Not for you.

For you, I can only wish good luck.

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.

== 8 of 8 ==
Date: Wed, Dec 23 2009 11:02 pm
From: tanix@mongo.net (tanix)

In article <hguelj$k49$1@news.albasani.net>, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
>Kaz Kylheku wrote:
>> On 2009-12-23, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
>>> tanix wrote:
>>>> In article <hgskgk$kc2$1@news.albasani.net>, Vladimir Jovic
> <vladaspams@gmail.com> wrote:

>>>> C++ would probably be benefited tremendously if it adopted some
>>>> of the central Java concept, such as GC, threads and GUI.
>>> GC is heavy performance killer especially on multiprocessor systems
>>
>> Is not.
>
>Hm, explain to me how can any thread, access or change any pointer in
>memory without lock while gc is collecting....
>There is no way for gc to collect without stopping all threads
>without locking.... because gc is just another thread(s) in itself...

To me, you are talking a kernel moder device driver talk.
You are saying things that may or may not happen in THEORY,
without considering the overall applicability of some concept
to the overall program performance, feature set, ease of use,
and on and on and on.

To tell you the truth, about the ONLY things I care about
as far as memory management goes is how much headache does
it produce for me for managing it and whether it works or not.

YOU can fiddle with those bits all you want.
Does not matter to me even a bit. I have no plans to rewrite
GC and can not even conceive such an idea.

All I know IT WORKS. And I can do it number of times faster
than you. And it still going to work. I don't even WANT
to hear about memory management issues as being ANY kind
of problem. We are WAY past that stage in the game.

Simple as that.

Now we have to solve the issues of having non dynamically
scoped languages being as portable as modern dynamically
scoped languages, such Php, the premiere language of web,
Javascript, Python, Ruby, SQL, and even HTML.

What seems to apply here is the issue of not seeing the
forest for the trees, more than anything else.

>>> in combination with threads....it is slow, complex and inefficient...

>> Religious belief.

>Of course. GC is complex program that has only one purpose.
>To let programmer not write free(p), but programmer
>still has to write close(fd).
>What's the purpose of that?

Because close is a LOGICAL operation that can not be performed
automatically unless the program terminates.

And free() is not, just as GC proves beyond all doubt.

>> Recursion is not directly connected to the need for garbage collection;
>> this is some kind of strange misconception.
>>
>>> GC without threads, but processes and shared memory instead, is ok on
>>> multiprocessor systems...
>>
>> GC is very efficient from an SMP point of view, because it allows
>> for immutable objects to be truly immutable, over most of their
>> lifetime. No book-keeping operations have to be performed on objects
>> that are just passed around throughout the program (such as bumping
>> refcounts up and down).
>
>Refcounts are negligible in comparison to what gc is doing.
>GC cannot be efficient since it cannot access program
>memory while program is working....ad it doesn;t know what program is
>doing... therefore GC can perform well only if it collect
>when absolutely necessary. And when it had to collect performance
>became catastrophic...

Sorry. But this is totally unproductive.
Cya.

>> No storage reclamation strategy is free of overhead. Even if your program
>> correctly manages memory by itself with explicit new and delete, there is a
>> cost.
>
>Manual memory deallocation is simple, fast and efficient. Nothing
>so complex like GC.
>Cost of new and delete is nothing in comparison to GC.
>
>>
>> Moreover, a poorly implemented heap allocator (like virtually
>> every default malloc implementation out there in the real world)
>> is an SMP performance killer.
>
>Yeah right. And GC thread is black magic , right?
>
>>
>> Like malloc and new, GC can be badly implemented in a way that kills SMP
>> performance. So can any aspect a programming language implementation,
> including
>> the compiler.
>
>GC cannot be implemented efficiently since it has to mess with
>memory...while other threads are working.
>Add that compacting collector which have to update all references
>in program and some copy/pasting... that can be optimised... to be
>faster than new/delete , yeah right ;)
>
>> That may be so, but GC does not require a virtual machine. GC has been used
> for
>> five decades, with natively compiled code, starting in the late 1950's on IBM
>> 704 mainframes, as part of the Lisp run-time support.
>
>I used GC with C++...
>
>>> I think java is designed in such way that it will still be slow in
>>> comparison to other compiled languages...if it is compiled
>>> language.
>>
>> Unfortunately, that is wishful thinking. Natively compiled Java has very
> little
>> disadvantage compared to C and C++. (Mainly in areas of doing low-level
> things
>> with memory, or directly interfacing with the ``bare iron''; the sorts
>> of things that are poorly supported in Java).
>
>I don;t want to discuss this, but it is obvious that nothing in java is
>designed with performance in mind. Quite opposite....
>
>Greets
>

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.

==============================================================================
TOPIC: different ways of allocating memory
http://groups.google.com/group/comp.lang.c++/t/cae68a10a2667fb5?hl=en
==============================================================================

== 1 of 3 ==
Date: Wed, Dec 23 2009 3:20 pm
From: "Larry"

Hi,

I am in the process of coding a C++ programm to capture input audio data
and save it real time (wave file) by using the waveForm API.

Now this is the code I have written so far:

<<main.cpp
#include <windows.h>
#pragma comment (lib, "winmm.lib")
#include <mmsystem.h>
#include <iostream>
#include <fstream>
#include <stdlib.h> // Define "system" function
#include <string>
#define system_buf_len 4096

void CALLBACK waveInProc(HWAVEIN hwi,UINT uMsg,DWORD dwInstance,DWORD
dwParam1,DWORD dwParam2);
bool addbuffer(WAVEHDR *pWaveHdr);

int main()
{
// Definisco la struttura WAVEFORMATEX
WAVEFORMATEX waveFormat;
waveFormat.wFormatTag = WAVE_FORMAT_PCM;
waveFormat.wBitsPerSample = 16;
waveFormat.nChannels = 1;
waveFormat.nSamplesPerSec = 8000;
waveFormat.nBlockAlign = (waveFormat.nChannels *
waveFormat.wBitsPerSample) / 8;
waveFormat.nAvgBytesPerSec = (waveFormat.nSamplesPerSec *
waveFormat.nBlockAlign);
waveFormat.cbSize = 0;

MMRESULT mmres; // ...
HWAVEIN phvi; // Handle for the input device
UINT uDevice = 0; // Device id "Gruppo Microfoni"

// waveInOpen
mmres = waveInOpen(&phvi,
uDevice,
(LPWAVEFORMATEX)&waveFormat,
(DWORD)waveInProc,
0,
CALLBACK_FUNCTION
);

// Prepare Buffer

int i=0;
int num_buff = 3;
WAVEHDR *buffer = (WAVEHDR *) malloc(sizeof(WAVEHDR)*num_buff);
for (i=0; i<num_buff; i++)
{
buffer[i].lpData = (LPSTR) malloc(system_buf_len);
buffer[i].dwBufferLength = system_buf_len;
buffer[i].dwBytesRecorded = 0;
buffer[i].dwUser = 0;
buffer[i].dwFlags = 0;
buffer[i].dwLoops = 0;

waveInPrepareHeader(phvi, &buffer[i], sizeof(WAVEHDR));
waveInAddBuffer(phvi, &buffer[i], sizeof(WAVEHDR));
}
//waveInStart;
waveInStart(phvi);
system("pause");
//waveInClose;
waveInClose(phvi);
return 0;
}

void CALLBACK waveInProc(HWAVEIN hwi,UINT uMsg,DWORD dwInstance,DWORD
dwParam1,DWORD dwParam2)
{
WAVEHDR* pWaveHdr;
switch(uMsg)
{
case MM_WIM_DATA:
pWaveHdr = ((WAVEHDR*)dwParam1);
if (pWaveHdr && hwi)
{
if (pWaveHdr->dwFlags && WHDR_DONE == WHDR_DONE)
{
addbuffer(pWaveHdr);
waveInAddBuffer(hwi, pWaveHdr, sizeof(WAVEHDR));
}
}
break;

case MM_WIM_OPEN:
std::cout << "MM_WIN_OPEN" << std::endl;
break;
case MM_WIM_CLOSE:
std::cout << "MM_WIN_CLOSE" << std::endl;
break;
}
}

bool addbuffer(WAVEHDR *pWaveHdr)
{
std::cout << pWaveHdr->dwBytesRecorded << std::endl;
char * buff = pWaveHdr->lpData;
std::ofstream usc;
usc.open("ciao.wave", std::ios::app|std::ios::binary);
usc.write(buff,pWaveHdr->dwBytesRecorded);
usc.close();

return true;
}
<</main.cpp

I run across sort of similar code where it uses a different way to allocate
memory:

<<diff.cpp
pwf.wBitsPerSample= 16;
pwf.wf.nChannels = 1;
pwf.wf.nSamplesPerSec = 8000;

pwf.wf.wFormatTag = WAVE_FORMAT_PCM;
pwf.wf.nBlockAlign =
pwf.wf.nChannels * pwf.wBitsPerSample / 8;
pwf.wf.nAvgBytesPerSec =
pwf.wf.nSamplesPerSec * pwf.wf.nBlockAlign;

if (waveInOpen(&rip->hwi,
/*WAVE_MAPPER*/ 0, (LPWAVEFORMATEX)&pwf,
(DWORD) rip->eventh, 0, CALLBACK_EVENT )) {
printf("Couldn't open sound device. Leaving..\n");
goto problem;
}

/* Preparing system buffers */

sb = (WAVEHDR**) malloc(sizeof(WAVEHDR**) * system_buf_num);
if(!sb)
goto problem;

for (i = 0; i < system_buf_num; i++)
sb[i] = NULL;

for (i = 0; i < system_buf_num; i++) {

count = i;
sb[i] = (WAVEHDR*) malloc(sizeof(WAVEHDR));

if (sb[i] == NULL) {
put_debug_message("malloc() error!\n");
goto problem;
}

sb[i]->lpData = (LPBYTE) malloc(system_buf_len);
sb[i]->dwBufferLength = system_buf_len;
sb[i]->dwBytesRecorded = 0;
sb[i]->dwUser = 0;
sb[i]->dwFlags = 0;
sb[i]->dwLoops = 0;

if(!sb[i]->lpData)
goto problem;

if (waveInPrepareHeader(rip->hwi, sb[i], sizeof(WAVEHDR))) {
put_debug_message("waveInPrepareHeader problem!\n");
goto problem;
}
if (waveInAddBuffer(rip->hwi, sb[i], sizeof(WAVEHDR))) {
put_debug_message("waveInAddBuffer problem!\n");
goto problem;
}
}

<</diff.cpp

So, basically I am using:

WAVEHDR *buffer = (WAVEHDR *) malloc(sizeof(WAVEHDR)*num_buff);

whereas the other code is using:

sb = (WAVEHDR**) malloc(sizeof(WAVEHDR**) * system_buf_num);

Now, I am really interested in this latter form of allocating! what is the
main differences?

How should I declare "sb" before allocating it? would: /WAVEHDR *sb/ ok?

Also, in my code I use: buffer[i].lpData to access data...in the other code
is used: sb[i]->lpData... why?

thanks

== 2 of 3 ==
Date: Wed, Dec 23 2009 4:14 pm
From: Maxim Yegorushkin

On 23/12/09 23:20, Larry wrote:

[]

> So, basically I am using:
>
> WAVEHDR *buffer = (WAVEHDR *) malloc(sizeof(WAVEHDR)*num_buff);

This allocates num_buff WAVEHDR objects.

> whereas the other code is using:
>
> sb = (WAVEHDR**) malloc(sizeof(WAVEHDR**) * system_buf_num);

This allocates system_buf_num WAVEHDR** objects. However, the cast is
incorrect. It is WAVEHDR*** pointer that can point to WAVEHDR** objects.

> Now, I am really interested in this latter form of allocating! what is
> the main differences?

They allocate different objects. The first allocates WAVEHDR objects,
the second allocates WAVEHDR** objects.

--
Max

== 3 of 3 ==
Date: Wed, Dec 23 2009 4:28 pm
From: "Larry"

"Maxim Yegorushkin" <maxim.yegorushkin@gmail.com> ha scritto nel messaggio
news:4b32b260$0$9753$6e1ede2f@read.cnntp.org...

>> sb = (WAVEHDR**) malloc(sizeof(WAVEHDR**) * system_buf_num);
>
> This allocates system_buf_num WAVEHDR** objects. However, the cast is
> incorrect. It is WAVEHDR*** pointer that can point to WAVEHDR** objects.

so should it be:

sb = (WAVEHDR***) malloc(sizeof(WAVEHDR**) * system_buf_num); ??

ho should I declare sb first??

is there any reason to go for this way of allocating buffers?

thanks

==============================================================================
TOPIC: C++ jobs down another 40%
http://groups.google.com/group/comp.lang.c++/t/6718a9cd2f3ecdbf?hl=en
==============================================================================

== 1 of 3 ==
Date: Wed, Dec 23 2009 3:26 pm
From: Branimir Maksimovic

Jon Harrop wrote:
> The number of job adverts in the UK citing C++ has fallen 40% for the second
> year in a row:
>
> http://flyingfrogblog.blogspot.com/2009/12/c-is-dying.html
>
F# is not bad, I like it!

Greets

--
http://maxa.homedns.org/

== 2 of 3 ==
Date: Wed, Dec 23 2009 10:37 pm
From: Christof Warlich

Stefan Ram wrote:
> »I wish the C++ people would wake up and realize that C++
> is drowning in its own complexity.«

I was rather frustrated when I realized that C++0x will neither be
finalized in this decade and, even worse, will not include Concepts.
Many programmers just deny using even well designed templates like BOOST
just due to the unfortunate error messages being printed when passing in
an incompatible type.

What's really needed is a real leap in C++ usability, offering its full
feature set to the experts while giving decent directions to the average
library user. Concepts would have been the first step, a new standard
library making use of Concepts the second. The final vision must be to
make C++ as save and easy to use as Python for every-day tasks while
still offering its full power to the dauntless expert.

== 3 of 3 ==
Date: Wed, Dec 23 2009 11:11 pm
From: tanix@mongo.net (tanix)

In article <4b330c19$0$6733$9b4e6d93@newsspool2.arcor-online.net>, Christof Warlich <cwarlich@gmx.de> wrote:
>Stefan Ram wrote:
>> �I wish the C++ people would wake up and realize that C++
>> is drowning in its own complexity.�
>
>I was rather frustrated when I realized that C++0x will neither be
>finalized in this decade and, even worse, will not include Concepts.
>Many programmers just deny using even well designed templates like BOOST
>just due to the unfortunate error messages being printed when passing in
>an incompatible type.
>
>What's really needed is a real leap in C++ usability, offering its full
>feature set to the experts while giving decent directions to the average
>library user. Concepts would have been the first step, a new standard
>library making use of Concepts the second. The final vision must be to
>make C++ as save and easy to use as Python for every-day tasks while
>still offering its full power to the dauntless expert.

Kinda.
Those "purists" tend to think that by inventing more and more of kinky
things, they somehow, magically, make the language more powerful and
more flexible.

One of the MOST important parameters of language for me
is to be able to read it as a read a news article, often skipping
the whole paragraps.

With all these great "improvements", I have to read it as a Bible
and think about every funky delimiter as if were a word of God.

TOTAL waste of my time.

I do not accept most of these notation perversions.

Instead of concentrating on those things that do seem the most
significant in the modern world, the concentrate on some kinky
things that will require 10 times more brain processing power
and heat generation from your scull, than it necessary to do
the same exact thing with the same exact results overall.

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.

==============================================================================
TOPIC: C++ call C# .NET api (dll)
http://groups.google.com/group/comp.lang.c++/t/b42e544e36439542?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Dec 23 2009 3:51 pm
From: Slickuser

Hi,

I have two projects, one wrote in C++ and one in C# .NET 3.5 Framework
sp1.

I would like the C++ project to call C# project dll. How can I expose
api/function from C# to allow C++ to call. Mostly I will not have the
source code to C# project, just api I can call.

Example of C# file below so I can get something going. Any help?

Test.cs
using System;
using System.Collections.Generic;
using System.Text;

namespace ProjectX
{
public class Test
{

public static void Main()
{
Console.WriteLine("Main!");
}

public void TestCount()
{
Console.WriteLine("Count!");
}

}
}

== 2 of 2 ==
Date: Wed, Dec 23 2009 7:12 pm
From: red floyd

On 12/23/2009 3:51 PM, Slickuser wrote:
> Hi,
>
> I have two projects, one wrote in C++ and one in C# .NET 3.5 Framework
> sp1.
>
> I would like the C++ project to call C# project dll. How can I expose
> api/function from C# to allow C++ to call. Mostly I will not have the
> source code to C# project, just api I can call.
>[redacted]

Wrong group. Try one with "visual studio" or "dotnet" in it's name

==============================================================================
TOPIC: How do I write what the friend template function in template class?
http://groups.google.com/group/comp.lang.c++/t/422bace48aaa5de5?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 23 2009 5:36 pm
From: maigre_dragon

> Hi
>
> I don't understand what you mean. You want a special function as a
> friend to MemoryMap class?
> As you wrote above code (of course it has a few syntax errors!), after
> each template instantiation, you have an appropriately typed output
> function. For example
> for MemoryMap<char> you have an operator<< for MemoryMap<char>, for
> MemoryMap<string> you
> have an operator<< for MemoryMap<string> and ...
> If you want an specializaed friend function, I believe you can add the
> following function to
> your class:
> friend std::ostream& operator<< (std::ostream& out,
> MemoryMap<char*>& x)
> {
> /* ... */
> }
>
> Regards,
> -- Saeed Amrollahi

Ok! Yes, this is I mean.
Do I wirte?
//MemoryMap.hpp
template< typename T>
class MemoryMap{
public:
MemoryMap(const T):data_(T){}
friend std::ostream& operator<< (std::ostream& out, MemoryMap<T>& x);
private:
T data_;
};
//MemoryMap.cpp
std::ostream& operator<< (std::ostream& out, MemoryMap<char*>& x){
//snip
}
std::ostream& operator<< (std::ostream& out,MemoryMap<std::string>& x){
//snip
}

==============================================================================
TOPIC: Merry Christmas!
http://groups.google.com/group/comp.lang.c++/t/42a1418a56e1e706?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 23 2009 6:14 pm
From:

Merry X'mas! Let's put this year behind and look forward.

==============================================================================
TOPIC: Different types of cast
http://groups.google.com/group/comp.lang.c++/t/b5b881bc79379355?hl=en
==============================================================================

== 1 of 3 ==
Date: Wed, Dec 23 2009 9:53 pm
From: Ravi

What is the difference between static cast and reinterpret cast?

== 2 of 3 ==
Date: Wed, Dec 23 2009 10:48 pm
From: Christof Warlich

Ravi wrote:
> What is the difference between static cast and reinterpret cast?

With static_cast you may only cast within the same inheritance
hierarchy, i.e. it is more restrictive and thus somewhat safer.

dynamic_cast is similar, adding run-time checking and making the cast
really safe.

reinterpret_cast allows any cast.

== 3 of 3 ==
Date: Wed, Dec 23 2009 11:56 pm
From: Tomislav Novak

On 2009-12-24, Christof Warlich <cwarlich@gmx.de> wrote:
> Ravi wrote:
>> What is the difference between static cast and reinterpret cast?
>
> With static_cast you may only cast within the same inheritance
> hierarchy, i.e. it is more restrictive and thus somewhat safer.

static_cast also enables one to convert between types with implicit or
explicit conversion operators.

> dynamic_cast is similar, adding run-time checking and making the cast
> really safe.
>
> reinterpret_cast allows any cast.

Of course, it works for pointer types only (just to clarify further).

--
T.

==============================================================================
TOPIC: workaround for auto_ptr<> in STL containers?
http://groups.google.com/group/comp.lang.c++/t/ea539aaeae39cd19?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 23 2009 10:06 pm
From: Christof Warlich

Branimir Maksimovic schrieb:
>> Any ideas how this (i.e. auto-deletion of unreferenced objects) could
>> be handled in a generic way while using STL containers?
>>
> Why don;t you use just shared_ptr or implement reference counting in
> base class?
> http://www.boost.org/doc/libs/1_35_0/boost/shared_ptr.hpp

Yes, I new BOOST smart pointers do work fine with STL containers, but as
I'm bound to a really ancient compiler (gcc2.95) in an embedded project,
I fear encountering difficulties with Boost libraries.

Anyhow, implementing a light-weight reference counting myself might be
an alternative.

Thanks and regards,

Christof

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

== 1 of 1 ==
Date: Wed, Dec 23 2009 10:17 pm
From: yqever

test

==============================================================================
TOPIC: clcm
http://groups.google.com/group/comp.lang.c++/t/5f665081d6a6b15e?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 23 2009 11:42 pm
From: "Balog Pal"

"Bo Persson" <bop@gmb.dk>

> Nowadays many of us (including most of the moderators :-) actually read
> both groups, just not to miss any interesting topics.

With the 1 day moderation delay clcm is as good as dead. :( If there is no
manpower to process stuff within a few hours there could be at least an
author whitelist for auto-approve, until there is an evident problem.

==============================================================================
TOPIC: ۞۩๑۞۩ AAA True Leather brand handbags Cheap wholesale (Chanel, Burberry,
LV......) at www.fjrjtrade.com <paypal payment>
http://groups.google.com/group/comp.lang.c++/t/ed8d4dbec996838e?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Dec 24 2009 12:14 am
From: "www.fjrjtrade.com"

۞۩๑۞۩ AAA True Leather brand handbags Cheap wholesale (Chanel,
Burberry, LV......) at www.fjrjtrade.com <paypal payment>

Cheap wholesale handbags www.fjrjtrade.com

Cheap wholesale AAA True Leather handbags www.fjrjtrade.com

Cheap wholesale AAA True Leather handbags

http://www.fjrjtrade.com/1201-AAA-True-Leather.html

Cheap wholesale Burberry Handbags AAA

http://www.fjrjtrade.com/1927-Burberry-Handbags-AAA.html

Cheap wholesale Burberry Purse AAA

http://www.fjrjtrade.com/1928-Burberry-Purse-AAA.html

Cheap wholesale D&G Handbags AAA

http://www.fjrjtrade.com/1943-DG-Handbags-AAA.html

Cheap wholesale Fendi Handbags AAA

http://www.fjrjtrade.com/1929-Fendi-Handbags-AAA.html

Cheap wholesale Hermes Handbags AAA

http://www.fjrjtrade.com/1930-Hermes-Handbags-AAA.html

Cheap wholesale Kooba Handbags AAA

http://www.fjrjtrade.com/1932-Kooba-Handbags-AAA.html

Cheap wholesale Loewe Handbags AAA

http://www.fjrjtrade.com/1933-Loewe-Handbags-AAA.html

Cheap wholesale Marc Jacobs Handbags AAA

http://www.fjrjtrade.com/1934-Marc-Jacobs-Handbags-AAA.html

Cheap wholesale Mulberry Handbags AAA

http://www.fjrjtrade.com/1936-Mulberry-Handbags-AAA.html

Cheap wholesale Prada Handbags AAA

http://www.fjrjtrade.com/1938-Prada-Handbags-AAA.html

Cheap wholesale Thomaswlde Handbags AAA

http://www.fjrjtrade.com/1937-Thomaswlde-Handbags-AAA.html

Cheap wholesale Valentnv Handbags AAA

http://www.fjrjtrade.com/1940-Valentnv-Handbags-AAA.html

Cheap wholesale Versace Handbags AAA

http://www.fjrjtrade.com/1942-Versace-Handbags-AAA.html

Cheap wholesale Balenciaga Handbags AAA

http://www.fjrjtrade.com/1203-Balenciaga-Handbags-AAA.html

Cheap wholesale Balenciaga Purse AAA

http://www.fjrjtrade.com/1204-Balenciaga-Purse-AAA.html

Cheap wholesale Bally Purse AAA

http://www.fjrjtrade.com/1205-Bally-Purse-AAA.html

Cheap wholesale Boss purse AAA

http://www.fjrjtrade.com/1206-Boss-purse-AAA.html

Cheap wholesale Chanel Handbags AAA

http://www.fjrjtrade.com/1207-Chanel-Handbags-AAA.html

Cheap wholesale Chanel Purse AAA

http://www.fjrjtrade.com/1208-Chanel-Purse-AAA.html

Cheap wholesale Chloe Handbags AAA

http://www.fjrjtrade.com/1209-Chloe-Handbags-AAA.html

Cheap wholesale Coach Handbags AAA

http://www.fjrjtrade.com/1211-Coach-Handbags-AAA.html

Cheap wholesale Miumiu Handbags AAA

http://www.fjrjtrade.com/1212-Miumiu-Handbags-AAA.html

Cheap wholesale Dior Handbags AAA

http://www.fjrjtrade.com/1214-Dior-Handbags-AAA.html

Cheap wholesale Gucci Handbags AAA

http://www.fjrjtrade.com/1216-Gucci-Handbags-AAA.html

Cheap wholesale Gucci Purse AAA

http://www.fjrjtrade.com/1217-Gucci-Purse-AAA.html

Cheap wholesale Hermes Purse AAA

http://www.fjrjtrade.com/1218-Hermes-Purse-AAA.html

Cheap wholesale JIMMY CHOO Handbags AAA

http://www.fjrjtrade.com/1219-JIMMY-CHOO-Handbags-AAA.html

Cheap wholesale LV Handbags AAA

http://www.fjrjtrade.com/1221-LV-Handbags-AAA.html

Cheap wholesale LV Purse AAA

http://www.fjrjtrade.com/1222-LV-Purse-AAA.html

More brand items at website:
http://www.fjrjtrade.com

==============================================================================
TOPIC: ◈•_•◈wholesale cheap t-shirts coat Jacket sweater at www.ecyaya.com
http://groups.google.com/group/comp.lang.c++/t/5c07b79d2f92fa3a?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Dec 24 2009 12:18 am
From: hero

◈•_•◈wholesale cheap t-shirts coat Jacket sweater at www.ecyaya.com

wholesale AFF T-shirt ( www.ecyaya.com )

wholesale ARMANI T-shirt www.ecyaya.com

wholesale BAPE T-shirt ( www.ecyaya.com )

wholesale BBC T-shirt www.ecyaya.com

wholesale BOSS T-shirt www.ecyaya.com

wholesale Burberry T-shirt ( www.ecyaya.com )

wholesale CA T-shirt men's www.ecyaya.com

wholesale CA T-shirt women's ( www.ecyaya.com )

wholesale COOGI T-shirt ( www.ecyaya.com )

wholesale CRYSTAL ROCK women's ( www.ecyaya.com )

wholesale D&G T-shirt www.ecyaya.com

wholesale DIESEL T-shirt ( www.ecyaya.com )

wholesale DSQUARED T-shirt men's ( www.ecyaya.com )

wholesale DSQUARED T-shirt women's ( www.ecyaya.com )

wholesale Eck? Unltd T-shirt ( www.ecyaya.com )

wholesale ED T-shirt men's

wholesale ED T-shirt women's (www.ecyaya.com)

wholesale EVISU T-shirt ( www.ecyaya.com )

wholesale GGG T-shirt ( www.ecyaya.com )

wholesale G-STAR T-shirt ( www.ecyaya.com )

wholesale HLST T-Shirt www.ecyaya.com

wholesale Lacoste T-shirt ( www.ecyaya.com )

wholesale Lacoste T-shirt women's ( www.ecyaya.com )

wholesale LRG T-shirt ( www.ecyaya.com )

wholesale O&L T-shirt www.ecyaya.com

wholesale POLO 3 T-shirt ( www.ecyaya.com )

wholesale 4 T-shirt ( www.ecyaya.com )

wholesale POLO 5 T-shirt (www.ecyaya.com)

wholesale POLO T-shirt men's ( www.ecyaya.com )

POLO T-shirt women's ( www.ecyaya.com )

Prada T-shirt ( www.ecyaya.com )

RUEHL T-Shirt www.ecyaya.com

SMET T-Shirt men's ( www.ecyaya.com )

SMET T-Shirt women's www.ecyaya.com

VERSACE T-shirt ( www.ecyaya.com )

A&F Abercrombie & Fitch T-shirt men's ( www.ecyaya.com )

A&F Abercrombie & Fitch T-shirt women's ( www.ecyaya.com )
wholesale ADIDAS Sunglass www.ecyaya.com
wholesale ARMANI Sunglass www.ecyaya.com
wholesale Burberry Sunglass www.ecyaya.com
wholesale BVLGARL Sunglass www.ecyaya.com
wholesale Cartier Sunglass www.ecyaya.com
wholesale CHANEL Sunglass www.ecyaya.com
wholesale COACH Sunglass www.ecyaya.com
wholesale D&G Sunglass www.ecyaya.com
wholesale DIESEL Sunglass www.ecyaya.com
wholesale DIOR Sunglass www.ecyaya.com
wholesale ED Hardy Sunglass www.ecyaya.com
wholesale FENDI Sunglass www.ecyaya.com
wholesale Ferragamo Sunglass www.ecyaya.com
wholesale GIVENCHY Sunglass www.ecyaya.com
wholesale GUCCI Sunglass www.ecyaya.com
wholesale LV Sunglass www.ecyaya.com
wholesale NIKE Sunglass www.ecyaya.com
wholesale Oakley Sunglass www.ecyaya.com
wholesale POLICE Sunglass www.ecyaya.com
wholesale PRADA Sunglass www.ecyaya.com
wholesale Ray.Ban Sunglass www.ecyaya.com
wholesale ROBERTO CAVALLI Sunglass www.ecyaya.com
wholesale Salvatore Sunglass www.ecyaya.com
wholesale VERSACE Sunglass www.ecyaya.com
wholesale YSL Sunglass www.ecyaya.com

goggle:

wholesale Armani goggle www.ecyaya.com
wholesale Catier goggle www.ecyaya.com
wholesale Chanel goggle www.ecyaya.com
wholesale D&G goggle www.ecyaya.com
wholesale DIOR goggle www.ecyaya.com
wholesale FENDI goggle www.ecyaya.com
wholesale FERRE goggle www.ecyaya.com
wholesale FRED goggle www.ecyaya.com
wholesale GUCCI goggle www.ecyaya.com
wholesale LV goggle www.ecyaya.com
wholesale MONT BLANC goggle www.ecyaya.com
wholesale NIKE goggle www.ecyaya.com
wholesale Oakley goggle www.ecyaya.com
wholesale POLICE goggle www.ecyaya.com
wholesale PRADA goggle www.ecyaya.com
wholesale PUMA goggle www.ecyaya.com
wholesale RAY.BAN goggle www.ecyaya.com
wholesale VERSACE goggle www.ecyaya.com

Our advantages:
1) A rate quality wholesale price.
2) rapid and safe delivery time: 4-6days
3) no minute order requirement.
4) different styles, colors and sizes in stock for your reference
Whatever you need, you are free to contact me.
Website:www.ecyaya.com

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

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, December 24, 2009

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

No comments:

Blog Archive

About Me