Wednesday, December 30, 2009

comp.lang.c++ - 25 new messages in 10 topics - digest

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

comp.lang.c++@googlegroups.com

Today's topics:

* c++ as scripting language - 5 messages, 5 authors
http://groups.google.com/group/comp.lang.c++/t/8b6a860779bd7319?hl=en
* Buffer wrapping in a stream - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/17cb466bada074d5?hl=en
* branches (if) and iterations (for) - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/62cf21e8adcb5b4f?hl=en
* Gigantic Class - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/b3756783d92fd56a?hl=en
* How do I wirte a .hpp file? (template, friend ,class,overload )? - 1
messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/22cc444eb98ed60d?hl=en
* "Reusable" operator overloading for enum? - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/981ab2c7a0c2c5ff?hl=en
* ===Welcome to comp.lang.c++! Read this first. - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/eaae59a3ac3d0782?hl=en
* Writing good articles that have much better chance to be seen by others - 3
messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/ddbe20a354342370?hl=en
* map vs list performance - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/f0b7f86d78b91416?hl=en
* C++ jobs down another 40% - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/6718a9cd2f3ecdbf?hl=en

==============================================================================
TOPIC: c++ as scripting language
http://groups.google.com/group/comp.lang.c++/t/8b6a860779bd7319?hl=en
==============================================================================

== 1 of 5 ==
Date: Wed, Dec 30 2009 12:11 am
From: Michael Doubez


On 30 déc, 00:37, Sam <s...@email-scan.com> wrote:
> Michael DOUBEZ writes:
> > Le 29/12/2009 17:31, Fred Zwarts a écrit :
> >> Michael Doubez wrote:
> >>> On 29 déc, 13:16, Sam<s...@email-scan.com>  wrote:
> >>>> balajee writes:
> >>>>> Hi,
> >>>>> I am new bee to C++. Basically I am TCL pogrammer, write scripts to
> >>>>> automate interactive applications such as telnet,ftpetc. Can we use
> >>>>> C+ + also for the same purpose? as scripting language for above
> >>>>> applications?
>
> >>>> C++ is not a scripting language. It is a compiled language.
>
> >>> It is not.
> >>> An interpreter engine does exists:
> >>>http://root.cern.ch/drupal/content/cint
>
> >> The C++ language is not by definition a compiled language.
> >> But CINT is a bad example.
>
> > But it is the only interpreter I know of.
>
> It may be an interpreter of something, but unless it is capable of accepting
> any syntactically valid C++ source, and "interpreting" it to produce the
> same results as if it were compiled, then it cannot be accurately described
> as a C++ interpreter.

A standard C++ interpreter may not be the goal of CINT developers.

In the standard, the term 'compilation unit' is used but not defined;
and I suspect it is used as a synonym of 'translation unit' which *is*
defined. If you define 'compiled language' has 'without translation',
you are right but nowadays most interpreted languages use JIT and
nothing prevents from doing the same with c++.

--
Michael


== 2 of 5 ==
Date: Wed, Dec 30 2009 4:36 am
From: "Fred Zwarts"


BGB / cr88192 wrote:
> "Sam" <sam@email-scan.com> wrote in message
> news:cone.1262129829.39427.22505.500@commodore.email-scan.com...
>
> <--
> Michael DOUBEZ writes:
>
>> Le 29/12/2009 17:31, Fred Zwarts a écrit :
>>> Michael Doubez wrote:
>>>> On 29 déc, 13:16, Sam<s...@email-scan.com> wrote:
>>>>> balajee writes:
>>>>>> Hi,
>>>>>> I am new bee to C++. Basically I am TCL pogrammer, write scripts
>>>>>> to automate interactive applications such as telnet,ftpetc. Can
>>>>>> we use C+ + also for the same purpose? as scripting language for
>>>>>> above applications?
>>>>>
>>>>> C++ is not a scripting language. It is a compiled language.
>>>>
>>>> It is not.
>>>> An interpreter engine does exists:
>>>> http://root.cern.ch/drupal/content/cint
>>>
>>> The C++ language is not by definition a compiled language.
>>> But CINT is a bad example.
>>
>> But it is the only interpreter I know of.
>
> It may be an interpreter of something, but unless it is capable of
> accepting any syntactically valid C++ source, and "interpreting" it
> to produce the same results as if it were compiled, then it cannot be
> accurately described as a C++ interpreter.
> -->
>
> granted, but AFAIK it may be close enough, nevermind missing features
> and slight differences...
>
> for example, what does it matter that much, if for example, "foo.bar"
> and "foo->bar" are equivalent, ...
> what if say, 95% of the time, things work, but in those 5% of edge
> cases, fails miserably?...

I think scoping rules are essential. It may be less then 1% of the rules,
but if destructors are not called at the end of the scope,
if const variables can be redefined within scope to be non-const,
then a very essential part of C++ is missing.


== 3 of 5 ==
Date: Wed, Dec 30 2009 5:07 am
From: Rolf Magnus


BGB / cr88192 wrote:

> for example, what does it matter that much, if for example, "foo.bar" and
> "foo->bar" are equivalent, ...

How does it know if you want to access a member of an object or use its
operator->, e.g. when using std::auto_ptr?

> what if say, 95% of the time, things work, but in those 5% of edge cases,
> fails miserably?...

If it's supposed to be useful as a C++ interpreter, it must work with most
existing code (libraries) without the need to heavily modify it first. Is
that the case?

> it would be like, say, if you had someone who was not very good with
> English, but most of the time were understood and understood what was
> being said, but every so often would have notable grammer errors, not make
> sense, or fail to understand well-formed statements.
>
> do we say then that they can't speak English?... no, we usually just say
> it isn't very good at it.

Spoken languages and programming languages can't really be compared that
way.

== 4 of 5 ==
Date: Wed, Dec 30 2009 7:48 am
From: Robert Hairgrove


Michael Doubez wrote:
> On 29 déc, 13:16, Sam <s...@email-scan.com> wrote:
>> C++ is not a scripting language. It is a compiled language.
>
> It is not.
> An interpreter engine does exists:
> http://root.cern.ch/drupal/content/cint

How does this "interpreter" handle templates, for example?

Any language will eventually need to be translated into some kind of
pseudo-code or byte code (even if interpreted) or else into machine
language, if it is to be executed at all. Machines can only understand
machine language. This applies to C++ as well as Java or (shudder)
Visual Basic.

There is no denying that some small subset of C++ could be interpreted
and executed at runtime instead of first compiled and then the resulting
file run as an executable. However, all but toy programs have to deal
with issues such as memory management, variable scope, namespaces,
pointers, exceptions, etc. which cannot be resolved at runtime, but need
to be dealt with at compile time. An interpreter cannot do this IMHO.


== 5 of 5 ==
Date: Wed, Dec 30 2009 12:44 pm
From: James Kanze


On 30 Dec, 15:48, Robert Hairgrove <rhairgr...@bigfoot.com> wrote:
> Michael Doubez wrote:

[...]
> Any language will eventually need to be translated into some kind of
> pseudo-code or byte code (even if interpreted) or else into machine
> language, if it is to be executed at all. Machines can only understand
> machine language. This applies to C++ as well as Java or (shudder)
> Visual Basic.

Yes, but the interpreter can interpret a textual representation
without converting it into an itermediate format. I'm not
saying that it's a good solution, but I've used one or two that
worked that way.

> There is no denying that some small subset of C++ could be
> interpreted and executed at runtime instead of first compiled
> and then the resulting file run as an executable. However, all
> but toy programs have to deal with issues such as memory
> management, variable scope, namespaces, pointers, exceptions,
> etc. which cannot be resolved at runtime, but need to be dealt
> with at compile time. An interpreter cannot do this IMHO.

Sure it can. Some of these, like memory management, are purely
runtime. Things like lexical scope are considerably trickier,
but they can be done.

--
James Kanze

==============================================================================
TOPIC: Buffer wrapping in a stream
http://groups.google.com/group/comp.lang.c++/t/17cb466bada074d5?hl=en
==============================================================================

== 1 of 4 ==
Date: Wed, Dec 30 2009 1:16 am
From: Philippe MESMEUR


Hi,

I'm currently trying to wrap a buffer in an ostream in order to access
it as following:

void TestOutStream(ostream & a_oStream)
{
a_oStream << "HELLO" << endl << "WORLD" << endl;
a_oStream << "FOO\nBAR" << endl;
a_oStream << "\001\002\003" << endl;
cout << "=> tellp: " << a_oStream.tellp() << endl;
}

const unsigned int SIZE = 32;
char buf[SIZE];

ostream.SetBuffer(buf, SIZE); /// here is what I would like to do
TestOutStream(ostream);

cout << buf << endl;


The writting in the ostream (or an inherited class, of course) would
write in the buffer buf. The buffer overloading would also be managed.


Do such an std class exist?
What should I do?

Thank you very much for your help

Philippe


== 2 of 4 ==
Date: Wed, Dec 30 2009 7:10 am
From: Philippe MESMEUR


On 30 déc, 10:16, Philippe MESMEUR <philippe.mesm...@gmail.com> wrote:
> Hi,
>
> I'm currently trying to wrap a buffer in an ostream in order to access
> it as following:
>
> void TestOutStream(ostream & a_oStream)
> {
>         a_oStream << "HELLO" << endl << "WORLD" << endl;
>         a_oStream << "FOO\nBAR" << endl;
>         a_oStream << "\001\002\003" << endl;
>         cout << "=> tellp: " << a_oStream.tellp() << endl;
>
> }
>
> const unsigned int SIZE = 32;
> char               buf[SIZE];
>
> ostream.SetBuffer(buf, SIZE);  /// here is what I would like to do
> TestOutStream(ostream);
>
> cout << buf << endl;
>
> The writting in the ostream (or an inherited class, of course) would
> write in the buffer buf. The buffer overloading would also be managed.
>
> Do such an std class exist?
> What should I do?
>
> Thank you very much for your help
>
> Philippe

If I try something like:

stringbuf sbuf;
sbuf.pubsetbuf(buf, SIZE);
ostream os(&sbuf);
TestOutStream(os);

The code works under cygwin/g++ but not Visual Studio.
The problème seems to be in the function setbuf (which is called by
pubsetbuf) that is definded as follow in basic_streambuf:

virtual _Myt *__CLR_OR_THIS_CALL setbuf(_Elem *, streamsize)
{ // offer buffer to external agent (do nothing)
return (this);
}

Can anyone help me...
Philippe


== 3 of 4 ==
Date: Wed, Dec 30 2009 10:04 am
From: I V


On Wed, 30 Dec 2009 07:10:46 -0800, Philippe MESMEUR wrote:
> On 30 déc, 10:16, Philippe MESMEUR <philippe.mesm...@gmail.com> wrote:
>> The writting in the ostream (or an inherited class, of course) would
>> write in the buffer buf. The buffer overloading would also be managed.
>>
>> Do such an std class exist?

std::ostringstream sounds like it ought to do what you want (although it
works with std::string, rather than a char array)

> If I try something like:
>
> stringbuf sbuf;
> sbuf.pubsetbuf(buf, SIZE);
> ostream os(&sbuf);
> TestOutStream(os);

I think pubsetbuf is intended to set a buffer used for internal buffering
by the stream, not the characters on which the stringbuf directly
operates; the standard says the effect of calling pubsetbuf is
"implementation defined," so I guess the behavior of both G++ and VC++ is
conforming. The function to get the characters that have been written to
the stringbuf is stringbuf::str() (which returns a std::string).


== 4 of 4 ==
Date: Wed, Dec 30 2009 3:42 pm
From: Branimir Maksimovic


Philippe MESMEUR wrote:
>
>
> ostream.SetBuffer(buf, SIZE); /// here is what I would like to do
> TestOutStream(ostream);
>
> cout << buf << endl;
>
>
> The writting in the ostream (or an inherited class, of course) would
> write in the buffer buf. The buffer overloading would also be managed.
>
>
> Do such an std class exist?
> What should I do?

You should write streambuf class, in this group archives and
c.l.c++.moderated you have lot of examples, how to do this, also
anu decent stl book should have it.

This is sample of two buffers to write/read strings via rpc...

class RpcOutBuf: public std::streambuf {
public:

RpcOutBuf(const std::string& sName, const std::string& sHost, unsigned
long ulP
virtual ~RpcOutBuf();

protected:

/**
Flushes buffer
*/

int flushBuffer();

/**
when buffer is full this function is called;
@param current character c
function will write current c, and all previous characters
*/
int overflow(int c);

/**
Synchronizes data with server
*/
int sync();

private:
/**
Service number on Rpc Server
*/
unsigned long ulSvcNum_;
/**
Constant which limits buffers size;
*/
static const int sizeOf = 2048;
/**
Internal buffer
*/
char szBuffer_[sizeOf+1];
/**
Rpc Client used for connection
*/
RpcClient rpcOutBufClient_;

};

class RpcInBuf: public std::streambuf {
public:

RpcInBuf(const std::string& sName, const std::string& sHost, unsigned
long ulPr

protected:

/**
Reads characters via RPC into buffer
*/

virtual int underflow();

private:
/**
Service number on Rpc server
*/
unsigned long ulSvcNum_;
/**
Constant which limits buffers size;
*/
static const int sizeOf = 2048;
/**
Internal buffer
*/
char szBuffer_[sizeOf+1];
/**
Rpc Client used for connection
*/
RpcClient rpcInBufClient_;

};

RpcOutBuf::RpcOutBuf(const std::string& sName, const std::string& sHost,
unsign
: ulSvcNum_(ulSvcNum),
rpcOutBufClient_(sName, sHost, ulProg, ulVer)
{
rpcOutBufClient_.regProc("outbuf", ulSvcNum_,
(xdrproc_t)xdr_wrapstring, (xdrproc_t)xdr_int);

setp(szBuffer_, szBuffer_+(sizeOf-1));
}

RpcOutBuf::~RpcOutBuf()
{
sync();
}

int RpcOutBuf::flushBuffer()
{
int num = pptr()-pbase();
try{
if ( num ) {
szBuffer_[num]=0;
int status;timeval t={5,0};
#ifdef DEBUG
std::clog<<"\nbuffer to send: \n"<<szBuffer_<<'\n';

No comments: