http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* code coverage tools - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/f49a00a394e54eea?hl=en
* using local static variable inside a function - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/7d53e8ea36d0502c?hl=en
* Any surveys about the premature optimization status nowadays? - 5 messages,
2 authors
http://groups.google.com/group/comp.lang.c++/t/dae885f4f1cdfad5?hl=en
* multiple inheritance ambiguity question - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/f9304159324663a2?hl=en
* Develop API for my cpp app - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/678ee3e7f6119411?hl=en
* Code::Blocks / Deleting A Project / C++ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/da234ca7da9e743f?hl=en
* ◆Whoelsale Original Nokia N97 and Apple Iphone 3Gs 16gb and 32gb, Iphone 3G
8gb and 16gb products◆ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/446946f056e6d3b2?hl=en
* ๑♥๑SELL Nokia N97, Apple Iphone 3GS,3G, Blackbery 9500,9000bold New,unlocked
at www.toptradea.com๑♥๑ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/f1c2654df7aa32e7?hl=en
* Open Source C++ Secure Client Platform Independent Library - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c++/t/ff3d4790e9c6c445?hl=en
==============================================================================
TOPIC: code coverage tools
http://groups.google.com/group/comp.lang.c++/t/f49a00a394e54eea?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Oct 1 2009 3:40 pm
From: flowher
Hello from France,
I was looking at open source code coverage tools and in the end I've
chosen covtool (http://covtool.sourceforge.net/). Do you guys have any
experience with it ? Is it good? Are there any better?
I havn't checked any commercial products, yet. Do you have some suggestions?
Regards,
Kris
==============================================================================
TOPIC: using local static variable inside a function
http://groups.google.com/group/comp.lang.c++/t/7d53e8ea36d0502c?hl=en
==============================================================================
== 1 of 3 ==
Date: Thurs, Oct 1 2009 3:40 pm
From: "Christian Freund"
When I declare a variable with storage class static keyword in a function I
expect that the variable retains its state between calls to that function,
no matter from where it is called and how many times at once.
Usage of storage class static for variables inside of functions is defined
by the standard.
This means, most likely, the resulting function is not thread-safe.
... Until you use a thread synchronization around that static variable.
I think a compiler that gives new memory to static content in functions in
the same process is far from the standard. When you look at it closer, the
C++ standard does require that static objects in functions are not
thread-safe, because it tells in which area and how often to store them.
Nevertheless the assumption that something is not safe, because it is not
written in a standard, is striking.
"Pete Becker" <pete@versatilecoding.com> schrieb im Newsbeitrag
news:yaKdnekR0fQJLF7XnZ2dnUVZ_hqdnZ2d@giganews.com...
>
> Yes, of course it was. But the claim was:
>
> Since standard C++ knows nothing about threads,
> the mechanism used to ensure this is not thread safe.
>
> The conclusion doesn't follow from the premise. The C++ standard does not
> require that the initialization mechanism for function-static data object
> not be thread safe.
>
> --
> Pete
> Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
> "The Standard C++ Library Extensions: a Tutorial and Reference"
> (www.petebecker.com/tr1book)
== 2 of 3 ==
Date: Thurs, Oct 1 2009 4:39 pm
From: Sam
Christian Freund writes:
> I think a compiler that gives new memory to static content in functions in
> the same process is far from the standard. When you look at it closer, the
> C++ standard does require that static objects in functions are not
> thread-safe, because it tells in which area and how often to store them.
I cannot find anything in the current C++ standard that refers to anything
called a "thread". It falls outside of the scope; as such, as soon as
threads are introduced into the picture, the results are no longer defined
by the current standard. Instead, one must consult the documentation of the
particular C++ implementation to learn what the effects of threads are, in
that implementation.
== 3 of 3 ==
Date: Thurs, Oct 1 2009 9:45 pm
From: "Ross A. Finlayson"
On Oct 1, 4:39 pm, Sam <s...@email-scan.com> wrote:
> Christian Freund writes:
> > I think a compiler that gives new memory to static content in functions in
> > the same process is far from the standard. When you look at it closer, the
> > C++ standard does require that static objects in functions are not
> > thread-safe, because it tells in which area and how often to store them.
>
> I cannot find anything in the current C++ standard that refers to anything
> called a "thread". It falls outside of the scope; as such, as soon as
> threads are introduced into the picture, the results are no longer defined
> by the current standard. Instead, one must consult the documentation of the
> particular C++ implementation to learn what the effects of threads are, in
> that implementation.
>
> application_pgp-signature_part
> < 1KViewDownload
How about, making a flag on the static initializer, and a write lock
that's only used once after the initialization so the initializer hits
the uninitialized flag, sets the write lock, and initializes and frees
the write lock and clears the uninitialized flag, but then a thread
waiting for the write lock because of the uninitialized flag might
want to initialize the function of the initializer otherwise failed,
so maybe there should be a timestamp with function calls and times
since the lock, so other functions can determine whether the lock is
frozen and break it, calling then the extra analyzers of the
verification of the static input record in an error-resistant network.
The idea here is to have first a flag that any caller can read. If
it's set, (or the function pointer can be pointed to after the static
initializer block after the first call), the the function is
initialized. If it's unset, then the caller calls the static
initializer of the function scope because the object isn't
initialized, instead of calling the initializer with the object, for
specialized initializers of functions' static members to not
initialize unused static members (lazy). So anyways, the function
takes the write lock that immediately follows the flag and sets it so
other function wait until the flag is cleared to proceed past that
point in the function. Then, it increments the following write
semaphore, which is only used if at all by other functions with
interest in how many calls to the function have tried to initialize
it. That is an extra step on the initializer. Then the static
variables are set up by the initializer, some of them are loaded at
class definitions, but in Java it is when the method is called.
About the scope blocks, and variable visibility, also there are often
static initializers throughout the function as the procedure demands
them besides in statement blocking, about the difference in the
program before and after the objects are statically initialized.
So, the specialized code path has that there are threading semantics
on the atomic static initialization of the object, because the
compiler automatically generates static initialization semantics via
the language definition and its semantics with regards to the linear
sequence of processing in statement blocks with jumps. Then, the user
might want there to be configurable levels of validation about when
other function families export semantics.
Using local static variables is great because if they're sufficient
then otherwise is waste, barring reclamation frameworks. C++ is great
in that the variables don't have to all be at the beginning of the
function, like traditional C, but then the order of initialization of
variables is pretty clearly specified except for example the design
choices about things like order of intialization in initializers and
so on, it's a feature of the language.
Then, with having more than just the one lock in the locks on the
static initializer and static initializers of nested local blocks,
with the flag, the lock, then the semaphore that is never decremented
unlike regular semaphore semantics but shouldn't hold a reference in
the semaphore table, it's more a simple count, there are various other
considerations of what information the calling function had before it
jumped to the static initializer block proper. The most recent time
written would expand the description of how long the process has been
in the write lock blocking other functions from calling the function,
where then if there were other functions that could initialize the
object and the normal initializer failed for some reason, there could
be a retry with in severely affected places, each variable to be
initialized having its own static initializer block semantics, with
waiting callers not being able to call the function proper but to
check on the status of the static initializer so see where it had set
write locks, in working towards locks that the caller might not want
to block upon, where a lock stops execution until the system calls
back another function released the lock, varying on whether the caller
really needs to call the function or can call parts of it that are
initialized already and not others.
It would of course be preferable to build the extensions into the
semantics of the language to avoid maintenance of static initializer
guards with whatever lock framework is in place, trying to make re-
entrant code safe about its static initializers
class static_initializer; // for this class in scope, mark the lock
static void static_initializer::end // here the writer knows it's done
void example_function(int i)
{
static_initializer; // following objects are protected to be
initialized one at a time
static large_table_of_constants t = new large_table_of_constants;
static_initializer::end; // no more with locked initialization
static const char const* label = "LABEL"; // don't care if this is
threadsafe, it's constant
return t.value(i);
}
Without a lock in the initializer, two functions could call the
example_function at around the same time, where the processor
allocates time just as the first is halfway through and the second
then starts, calling functions on the same object again, which is bad,
could lead to undefined behavior. It might not, the problem is then
there are two new tables and when the function exits the destructor
isn't called,where there is a question how to indicate a lights-out
call so then the function destroys its static variables, static
function destructors. As well, functions might want to generally
reset the variable besides worrying about the static variable, that is
preserved between function calls, in the run-time. That is where, I
wonder when static variables have their destructors called.
Regards,
Ross F.
==============================================================================
TOPIC: Any surveys about the premature optimization status nowadays?
http://groups.google.com/group/comp.lang.c++/t/dae885f4f1cdfad5?hl=en
==============================================================================
== 1 of 5 ==
Date: Thurs, Oct 1 2009 3:43 pm
From: "robertwessel2@yahoo.com"
On Oct 1, 4:07 am, "Francesco S. Carta" <entul...@gmail.com> wrote:
> Translating a complete, non-trivial program from a language to another
> isn't exactly child-play and if a program has the chance of _needing_
> to be implemented in a language, choosing another in first place is
> not a "premature pessimization", it is a "serious project management
> flaw", in my opinion.
While you said "complete," I think it's worth pointing out that
prototypes can often be usefully written in languages other than the
final implementation language. In situations where significant
uncertainly about the design exists, and a prototype is justified (and
frankly that's true in reality far more than happens in practice), the
prototype should be written in with a tool that make it easy to write
and modify (in the short term), while possibly ignoring many other
factors (like deployment and performance). A decided advantage of
using a different (and impractical to deploy) language is that you
don't end up with management insisting you turn the prototype into
production code.
== 2 of 5 ==
Date: Thurs, Oct 1 2009 4:26 pm
From: "Francesco S. Carta"
On 2 Ott, 00:43, "robertwess...@yahoo.com" <robertwess...@yahoo.com>
wrote:
> On Oct 1, 4:07 am, "Francesco S. Carta" <entul...@gmail.com> wrote:
>
> > Translating a complete, non-trivial program from a language to another
> > isn't exactly child-play and if a program has the chance of _needing_
> > to be implemented in a language, choosing another in first place is
> > not a "premature pessimization", it is a "serious project management
> > flaw", in my opinion.
>
> While you said "complete," I think it's worth pointing out that
> prototypes can often be usefully written in languages other than the
> final implementation language. In situations where significant
> uncertainly about the design exists, and a prototype is justified (and
> frankly that's true in reality far more than happens in practice), the
> prototype should be written in with a tool that make it easy to write
> and modify (in the short term), while possibly ignoring many other
> factors (like deployment and performance). A decided advantage of
> using a different (and impractical to deploy) language is that you
> don't end up with management insisting you turn the prototype into
> production code.
First of all, let me point out once more that I'm an hobbyist who has
always coded alone.
I'm highlighting it (again) because all of these points of mine should
be taken with a grain of salt: I'm speaking about things that I
_could_ dig and understand, but I never actually faced them in real
life.
Just to bring my words back to their real value.
That said, I suppose that "prototyping in a language which is _not_
going to be the production language" as "a way to safely halt-on-start
weird management requests" is an odd need - there must be something
wrong with the managers if they put the team on studying something
which isn't all that clear from start and then they push the team to
get something out ASAP.
But that wasn't your central point, of course. Your point was about
prototyping with a language that allows you to work out and test an
initial infrastructure more easily and more quickly than with C++, if
I got your words in the right way.
The main problem I'm facing here is that my knowledge about different
languages is very limited, hence I cannot tell how easily _I_ could
"prototype" in one language and then "produce" in another.
About that, I think that most of the initial design process should be
no-code stuff, but once that initial process is even just partly done
(components, interfaces, politics) I think it can be effectively
prototyped and tested expressing such stuff directly in the C++ code
(namespaces, class hierarchies, public vs protected vs private
interfaces, client vs implementation interfaces)... in other words, I
see C++ as a very effective language to express the main
infrastructure even in the first steps of the prototyping.
But once again, take my limited knowledge in account. Maybe all of
that can be more easily and more quickly implemented/modified in, say,
LISP... but I don't know LISP, that's the fact ;-)
OK, I've posted my fair amount of wanderings for today - maybe I would
be better having kept my full name reserved, in the perspective of
getting some job interview, someday ;-)
Cheers,
Francesco
--
Francesco S. Carta, hobbyist
http://fscode.altervista.org
== 3 of 5 ==
Date: Thurs, Oct 1 2009 4:36 pm
From: "Francesco S. Carta"
On 1 Ott, 19:30, jimxoch <dpxguard-goo...@yahoo.gr> wrote:
> On Oct 1, 12:07 pm, "Francesco S. Carta" <entul...@gmail.com> wrote:
>
> ...
>
> > @OP: Sorry Jim, I have no idea about the existence of surveys and
> > alike, wrt your original topic.
>
> Thanks anyway. Hope dies last :)
You're welcome, and... "hope": here I am! the first among its
supporters ;-)
Cheers,
Francesco
--
Francesco S. Carta, hobbyist
http://fscode.altervista.org
== 4 of 5 ==
Date: Thurs, Oct 1 2009 5:58 pm
From: "Francesco S. Carta"
On 2 Ott, 01:26, "Francesco S. Carta" <entul...@gmail.com> wrote:
> On 2 Ott, 00:43, "robertwess...@yahoo.com" <robertwess...@yahoo.com>
> wrote:
>
>
>
> > On Oct 1, 4:07 am, "Francesco S. Carta" <entul...@gmail.com> wrote:
>
> > > Translating a complete, non-trivial program from a language to another
> > > isn't exactly child-play and if a program has the chance of _needing_
> > > to be implemented in a language, choosing another in first place is
> > > not a "premature pessimization", it is a "serious project management
> > > flaw", in my opinion.
>
> > While you said "complete," I think it's worth pointing out that
> > prototypes can often be usefully written in languages other than the
> > final implementation language. In situations where significant
> > uncertainly about the design exists, and a prototype is justified (and
> > frankly that's true in reality far more than happens in practice), the
> > prototype should be written in with a tool that make it easy to write
> > and modify (in the short term), while possibly ignoring many other
> > factors (like deployment and performance). A decided advantage of
> > using a different (and impractical to deploy) language is that you
> > don't end up with management insisting you turn the prototype into
> > production code.
[self-snip]
> But that wasn't your central point, of course. Your point was about
> prototyping with a language that allows you to work out and test an
> initial infrastructure more easily and more quickly than with C++, if
> I got your words in the right way.
Sorry, I obviously didn't mean to change your words.
The above should read:
"[...] more easily and more quickly than with /, say,/ C++, [...]"
or, more fitting:
"[...] more easily and more quickly than with /another language/,
[...]"
I hope the perceived sense of my post didn't change for that small
mistake.
Have good time,
Francesco
--
Francesco S. Carta, hobbyist
http://fscode.altervista.org
== 5 of 5 ==
Date: Thurs, Oct 1 2009 9:54 pm
From: "robertwessel2@yahoo.com"
On Oct 1, 6:26 pm, "Francesco S. Carta" <entul...@gmail.com> wrote:
> On 2 Ott, 00:43, "robertwess...@yahoo.com" <robertwess...@yahoo.com>
> wrote:
> First of all, let me point out once more that I'm an hobbyist who has
> always coded alone.
>
> I'm highlighting it (again) because all of these points of mine should
> be taken with a grain of salt: I'm speaking about things that I
> _could_ dig and understand, but I never actually faced them in real
> life.
>
> Just to bring my words back to their real value.
>
> That said, I suppose that "prototyping in a language which is _not_
> going to be the production language" as "a way to safely halt-on-start
> weird management requests" is an odd need - there must be something
> wrong with the managers if they put the team on studying something
> which isn't all that clear from start and then they push the team to
> get something out ASAP.
Unfortunately that's too often the real world. You get to the point
where something *looks* like it works, and then everyone is suddenly
wanting to ship. Or your prototype gets demo'd to a customer, who
then starts jumping up and down screaming that they *need* that
*now*. It's a definite danger when doing a prototype, which is often
full of all sorts of crap code.
> But that wasn't your central point, of course. Your point was about
> prototyping with a language that allows you to work out and test an
> initial infrastructure more easily and more quickly than with C++, if
> I got your words in the right way.
Yep. Always use the tools that best fit the job at hand. "Best," of
course, has to take in your familiarity with the tools.
> The main problem I'm facing here is that my knowledge about different
> languages is very limited, hence I cannot tell how easily _I_ could
> "prototype" in one language and then "produce" in another.
>
> About that, I think that most of the initial design process should be
> no-code stuff, but once that initial process is even just partly done
> (components, interfaces, politics) I think it can be effectively
> prototyped and tested expressing such stuff directly in the C++ code
> (namespaces, class hierarchies, public vs protected vs private
> interfaces, client vs implementation interfaces)... in other words, I
> see C++ as a very effective language to express the main
> infrastructure even in the first steps of the prototyping.
There's not necessarily anything wrong with prototyping in C++. If
that suits your purpose, have at. My point was that there may be
better choices, since the prototype, by definition, will not have a
long life (we hope!).
> But once again, take my limited knowledge in account. Maybe all of
> that can be more easily and more quickly implemented/modified in, say,
> LISP... but I don't know LISP, that's the fact ;-)
And that's a limitation you *should* rectify. Every programmer should
learn a procedural language, an object oriented one, a functional one,
a couple of scripting languages, and probably at least dabble in some
assembler. And then deal with some related stuff like databases,
etc. If you want to use Lisp to cover some of that, great, if not,
something like Haskel or F#. The particular language really doesn't
matter. The paradigm does, but as you become a better programmer the
exact language does not.
Today you're writing C++ code, and tomorrow you might have to write
some C# (*yawn*, yet another OO language falling somewhere on the
Algol tree). Sure there will be quirks, and a learning curve, and
you'll be less productive for a while, but for languages within a
given paradigm, the change is, or should be, no big deal. But hitting
some of the major different paradigms is good for you, it gives you
insights into different approaches, and helps decouple your
understanding of programming from a particular language and
environment.
==============================================================================
TOPIC: multiple inheritance ambiguity question
http://groups.google.com/group/comp.lang.c++/t/f9304159324663a2?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Oct 1 2009 4:29 pm
From: "Alf P. Steinbach"
* Joshua Maurice:
> On Oct 1, 3:17 pm, "Francesco S. Carta" <entul...@gmail.com> wrote:
>> Well, I think that also Comeau gets :: base specifications wrong if
>> fed with something even slightly more complex, see this:
>>
>> -------
>> struct base1{ void display(){} };
>> struct base2{ void display(){} };
>> struct der1 : base1, base2 {};
>> struct der2 : base1, base2 {};
>> struct client : der1, der2 {};
>> int main() {
>> /*
>> tested with
>> - gcc 3.4.5
>> - Comeau Online
>> both choke on last three statements
>> */
>>
>> client cl;
>> der1* p_der1 = &cl;
>> base1* p_base1 = p_der1;
>>
>> /* compiles, OK */
>> p_base1->display();
>>
>> /* compile error: ambiguous (OK) */
>> cl.display();
>>
>> /* compile error: ambiguous (OK) */
>> cl.der1::display();
>>
>> /* compile error: ambiguous (BUG???) */
>> cl.der1::base1::display();
>>
>> }
>>
>> -------
>>
>> Comeau C/C++ 4.3.10.1 (Oct 6 2008 11:28:09) for
>> ONLINE_EVALUATION_BETA2
>> Copyright 1988-2008 Comeau Computing. All rights reserved.
>> MODE:strict errors C++ C++0x_extensions
>>
>> "ComeauTest.c", line 22: error: "client::display" is ambiguous
>> cl.display();
>> ^
>>
>> "ComeauTest.c", line 25: error: "der1::display" is ambiguous
>> cl.der1::display();
>> ^
>>
>> "ComeauTest.c", line 28: error: base class "base1" is ambiguous
>> cl.der1::base1::display();
>> ^
>>
>> 3 errors detected in the compilation of "ComeauTest.c".
>>
>> In strict mode, with -tused, Compile failed
>> Hit the Back Button to review your code and compile options.
>> Compiled with C++0x extensions enabled.
>>
>> -------
>>
>> As far as I understand it, "cl.der1::base1::display();" should
>> compile, am I correct?
>
> Odd.
> gcc version 4.1.2 20070626 (Red Hat 4.1.2-14)
> just choked on that too.
> foo.cpp: In function 'int main()':
> foo.cpp:22: error: request for member 'display' is ambiguous
> foo.cpp:2: error: candidates are: void base2::display()
> foo.cpp:1: error: void base1::display()
> foo.cpp:2: error: void base2::display()
> foo.cpp:1: error: void base1::display()
> foo.cpp:25: error: request for member 'display' is ambiguous
> foo.cpp:2: error: candidates are: void base2::display()
> foo.cpp:1: error: void base1::display()
> foo.cpp:28: error: 'base1' is an ambiguous base of 'client'
> I am also confused as I agree with your assessment Francesco. Line 28
> should not be ambiguous, at least as I understand the language rules.
> I'm leaning towards my understanding is flawed. Let me go see what the
> standard says...
The qualifications do not constitute a hint about which 'this' pointer to pass.
They merely specify /a/ class (the final one in the qualification chain) where
to look up the 'display' name. As far as the compiler is concerned the whole
qualification chain 'der1::base1' is equivalent to writing just 'base1::'.
Cheers & hth.,
- Alf
==============================================================================
TOPIC: Develop API for my cpp app
http://groups.google.com/group/comp.lang.c++/t/678ee3e7f6119411?hl=en
==============================================================================
== 1 of 2 ==
Date: Thurs, Oct 1 2009 6:20 pm
From: n0xi0uzz
Hi
How to develop API for my C++ application if i want to use it
something like an engine from perl and python?
Thanks.
== 2 of 2 ==
Date: Thurs, Oct 1 2009 6:40 pm
From: Victor Bazarov
n0xi0uzz wrote:
> How to develop API for my C++ application if i want to use it
> something like an engine from perl and python?
What is your C++ *language* question, again? For general inquiries
about software development, consider 'comp.software-eng' newsgroup.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
==============================================================================
TOPIC: Code::Blocks / Deleting A Project / C++
http://groups.google.com/group/comp.lang.c++/t/da234ca7da9e743f?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Oct 1 2009 9:25 pm
From: jasdad
On Oct 1, 10:44 am, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
> John wrote:
> > I am working out of a book and teaching myself the Computer
> > language C++ using the compiler called Code::Blocks.
>
> It's not a compiler, it's a development environment, although it really
> doesn't matter.
>
> > [..] If any one has any thoughts, ideas,
>
> > links or tutorials to pass on how I could delete this project I would
> > appreciate it.
>
> Here is an idea: find a better forum for product-specific questions,
> please. Your question is not about C++ language, and as such is
> off-topic here. You're free not to appreciate this idea, of course.
>
> V
> --
> Please remove capital 'A's when replying by e-mail
> I do not respond to top-posted replies, please don't ask
Aren't compilers, editors and IDEs very much a part of writing C++
code? You can't write C++ or any other language without those tools.
So I would think that that asking a question about a particular C++
IDE would be relevant. We all use compilers, editors and IDEs to do
our C++ work. And the poster did look elsewhere, but wanted to try
his luck here. There's probably not a better place. The wealth of
expertise that resides in this forum is practically unparalleled.
Heck, even Bjarne Stroustrup has posted here. So I say it's all good,
so long as it's directly or indirectly relevant to the C++ language.
But I could be talking out of my posterior because I'm not that up on
the rules around here. ;-)
Anyway, I'm quite fond of Code::Blocks myself - great cross platform
IDE that has project templates for plain old C++, wxWidgets, Qt,
Win32, FLTK, and GTK+.
==============================================================================
TOPIC: ◆Whoelsale Original Nokia N97 and Apple Iphone 3Gs 16gb and 32gb,
Iphone 3G 8gb and 16gb products◆
http://groups.google.com/group/comp.lang.c++/t/446946f056e6d3b2?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Oct 1 2009 10:07 pm
From: peng Selina
◆Whoelsale Original Nokia N97 and Apple Iphone 3Gs 16gb and 32gb,
Iphone 3G 8gb and 16gb products◆
"Apple [www.toptradea.com & www.toptradea.606c.com]
Nokia [www.toptradea.com & www.toptradea.606c.com]
Blackberry [www.toptradea.com & www.toptradea.606c.com]
Samsung [www.toptradea.com & www.toptradea.606c.com]
Sony Ericsson [www.toptradea.com & www.toptradea.606c.com]
HTC [www.toptradea.com & www.toptradea.606c.com]
"
==============================================================================
TOPIC: ๑♥๑SELL Nokia N97, Apple Iphone 3GS,3G, Blackbery 9500,9000bold New,
unlocked at www.toptradea.com๑♥๑
http://groups.google.com/group/comp.lang.c++/t/f1c2654df7aa32e7?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Oct 1 2009 10:08 pm
From: peng Selina
๑♥๑SELL Nokia N97, Apple Iphone 3GS,3G, Blackbery 9500,9000bold
New,unlocked at www.toptradea.com๑♥๑
"Apple [www.toptradea.com & www.toptradea.606c.com]
Nokia [www.toptradea.com & www.toptradea.606c.com]
Blackberry [www.toptradea.com & www.toptradea.606c.com]
Samsung [www.toptradea.com & www.toptradea.606c.com]
Sony Ericsson [www.toptradea.com & www.toptradea.606c.com]
HTC [www.toptradea.com & www.toptradea.606c.com]
"
==============================================================================
TOPIC: Open Source C++ Secure Client Platform Independent Library
http://groups.google.com/group/comp.lang.c++/t/ff3d4790e9c6c445?hl=en
==============================================================================
== 1 of 1 ==
Date: Fri, Oct 2 2009 12:03 am
From: conaku
I am looking for free c++ ssh-client library for windows . As of now I
have been using plink as ssh command-line utility but in that case i
do not have the freedom of keeping a handle to the connection . I can
see that NetSieben has come-up with a C++ SSH library but that is not
an open-source in complete sense . Please help me if you are aware of
any .
==============================================================================
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
No comments:
Post a Comment