soft and program: comp.lang.c++ - 25 new messages in 10 topics

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

comp.lang.c++@googlegroups.com

Today's topics:

==============================================================================
TOPIC: ===Welcome to comp.lang.c++! Read this first.
http://groups.google.com/group/comp.lang.c++/t/8359863cfafcc5aa?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Jan 30 2010 9:30 pm
From: Shiva

Welcome to comp.lang.c++! Read this first.

This post is intended to give the new reader an introduction to reading
and posting in this newsgroup. We respectfully request that you read
all the way through this post, as it helps make for a more pleasant
and useful group for everyone.

First of all, please keep in mind that comp.lang.c++ is a group for discussion
of general issues of the C++ programming language, as defined by the ANSI/ISO
language standard. If you have a problem that is specific to a particular system
or compiler, you are much more likely to get complete and accurate answers in a
group that specializes in your platform. A listing of some newsgroups is given
at the end of this post.

The FAQ (Frequently Asked Question) list has a wealth of information for
both the new and veteran C++ programmer. No matter what your experience
level, you are encouraged to read the entire list, if only to familiarize
yourself with what answers are available to minimize redundant replies.
The comp.lang.c++ FAQ is available at http://www.parashift.com/c++-faq-lite/

If the FAQ list does not help, then many regular readers of this group
are happy to assist with problems of standard C++. We have only a few
requests that we ask be adhered to, for the benefit of all:

* Please put a short summary in the subject line. Descriptions such as
"HELP!!!!!!" are not helpful, and many regular posters ignore such
requests. A good example is, "Problem with Virtual Functions."

* State the question or the problem clearly and concisely. Describe what
you are trying to do, and the problem you are running into. Include all
relevant error messages.

* Include the smallest, complete and compilable program that exhibits your
problem. As a rule, posters in comp.lang.c++ will not do homework, but will
give helpful hints if you have shown some willingness to try a solution.

* comp.lang.c++ is forum for discussion, and as such some regular posters do
not give E-mail replies. Very often follow-ups to postings have corrections,
so plan on taking part in the discussion if you post a question. If you
do receive e-mail replies, it is considered polite to post a summary.

* Don't post in HTML format. Many readers of this newsgroup don't use
newsreaders which can handle HTML postings.

* If you have to include source code in your post, include the
source in the message body. Don't use attachments. A lot
of contributors to this newsgroup won't even notice the existence
of attachments or won't open them. You try to get any help
you can get, don't you?

Some netiquette topics which frequently crop up on comp.lang.c++ are
also answered in the FAQ.

* Should I post job advertisements and/or resumes on comp.lang.c++?
http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.10

* What if I really need a job; should I post my resume on comp.lang.c++?
http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.11

* What should I do to someone who posts something off-topic?
http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.12

A note on comp.lang.c++ etiquette: Accuracy is valued very highly in this
newsgroup; therefore posts are frequently corrected, sometimes perhaps
too harshly, and often to the annoyance of new posters who consider the
correction trivial. Do not take it personally; the best way to fit in
with comp.lang.c++ is to express gratitude for the correction, move on,
and be more careful next time.

This is a very busy group, so these requests are designed to make it as
pleasant and efficient an experience as possible. We hope it proves
a valuable commodity to you.

A list of some Newsgroups :
Languages and Programming
-------------------------
comp.lang.c The C Programming Language
comp.lang.asm.x86 x86 assembly language programming
comp.programming Non-language specific programming
comp.graphics.algorithms Issues of computer graphics

Operating Systems
-----------------
comp.os.msdos.programmer DOS, BIOS, Memory Models, interrupts,
screen handling, hardware
comp.os.ms-windows.programmer.win32 MS/Windows: Mice, DLLs, hardware
comp.os.os2.programmer.misc OS/2 Programming
comp.sys.mac.programmer.misc Macintosh Programming
comp.unix.programmer General Unix: processes, pipes, POSIX,
curses, sockets
comp.unix.[vendor] Various Unix vendors

Microsoft VC++
-------------
microsoft.public.vc.language VC++ issues
microsoft.public.vc.mfc MFC Issues
microsoft.public.dotnet.languages.vc C++/CLR Issues
microsoft.public.dotnet.framework .Net Framework

Borland C++ Builder
-------------------
borland.public.cppbuilder.language Borland C++ Builder
borland.public.cpp.language
borland.public.cppbuilder

-Shiva
http://www.slack.net/~shiva/welcome.txt

Sun Jan 31 00:30:00 EST 2010

==============================================================================
TOPIC: isspace
http://groups.google.com/group/comp.lang.c++/t/89ca303518428e34?hl=en
==============================================================================

== 1 of 5 ==
Date: Sun, Jan 31 2010 12:20 am
From: Paavo Helde

gervaz <gervaz@gmail.com> wrote in news:f9eec1c9-5570-461a-bdec-
6dec26dab285@o28g2000yqh.googlegroups.com:

> On Jan 30, 1:15 pm, James Kanze <james.ka...@gmail.com> wrote:
>> On Jan 30, 12:05 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
>>
>> > James Kanze <james.ka...@gmail.com> writes:
>> > >There are no standard names for locales
>> > AFAIK, C90 defines a locale by the name of "C",
>> > which should also be visible from C++.
>>
>> And Posix defines "POSIX". Neither of which are really useful
>> for anything.
>>
>> --
>> James Kanze
>
> Ok, so I think that I will open my file specifying to use UTF-8
> encoding, but how can I do it in C++?

You can open it as a narrow stream and read in as binary UTF-8, or
(maybe) you can open it as a wide stream and get an automatic translation
from UTF-8 to wchar_t. The following example assumes that you have a file
test1.utf containing valid UTF-8 text. It reads the file in as a wide
stream and prints out the numeric values of all wchar_t characters.

#include <iostream>
#include <fstream>
#include <locale>
#include <string>

int main() {
std::wifstream is;
const std::locale filelocale("en_US.UTF8");
is.imbue(filelocale);
is.open("test1.utf8");

std::wstring s;
while(std::getline(is, s)) {
for (std::wstring::size_type j=0; j<s.length(); ++j) {
std::cout << s[j] << " ";
}
std::cout << "\n";
}
}

(Tested on Linux with a recent gcc, I am not too sure if this works on
Windows. First, wchar_t in MSVC is too narrow for real Unicode, at best
one might get UTF-16 as a result.)

hth
Paavo

== 2 of 5 ==
Date: Sun, Jan 31 2010 1:39 am
From: Paavo Helde

Paavo Helde <myfirstname@osa.pri.ee> wrote in
news:Xns9D116950C4paavo256@216.196.109.131:

> gervaz <gervaz@gmail.com> wrote in news:f9eec1c9-5570-461a-bdec-
> 6dec26dab285@o28g2000yqh.googlegroups.com:
>
>> On Jan 30, 1:15 pm, James Kanze <james.ka...@gmail.com> wrote:
>>> On Jan 30, 12:05 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
>>>
>>> > James Kanze <james.ka...@gmail.com> writes:
>>> > >There are no standard names for locales
>>> > AFAIK, C90 defines a locale by the name of "C",
>>> > which should also be visible from C++.
>>>
>>> And Posix defines "POSIX". Neither of which are really useful
>>> for anything.
>>>
>>> --
>>> James Kanze
>>
>> Ok, so I think that I will open my file specifying to use UTF-8
>> encoding, but how can I do it in C++?
>
> You can open it as a narrow stream and read in as binary UTF-8, or
> (maybe) you can open it as a wide stream and get an automatic
> translation from UTF-8 to wchar_t. The following example assumes that
> you have a file test1.utf containing valid UTF-8 text. It reads the
> file in as a wide stream and prints out the numeric values of all
> wchar_t characters.
>
> #include <iostream>
> #include <fstream>
> #include <locale>
> #include <string>
>
> int main() {
> std::wifstream is;
> const std::locale filelocale("en_US.UTF8");
> is.imbue(filelocale);
> is.open("test1.utf8");
>
> std::wstring s;
> while(std::getline(is, s)) {
> for (std::wstring::size_type j=0; j<s.length(); ++j) {
> std::cout << s[j] << " ";
> }
> std::cout << "\n";
> }
> }
>
> (Tested on Linux with a recent gcc, I am not too sure if this works on
> Windows. First, wchar_t in MSVC is too narrow for real Unicode, at
> best one might get UTF-16 as a result.)

For curiosity, I tested this also on Windows with MSVC9, and as expected
it did not work, the locale construction immediately threw an exception
(bad locale name). Neither did any alterations work ("english.UTF8",
".UTF8", ".utf-8", ".65001").

Thus, if one wants any portability it seems the best approach currently
is still to read in binary UTF-8 and perform any needed conversions by
hand.

Paavo

== 3 of 5 ==
Date: Sun, Jan 31 2010 3:30 am
From: gervaz

On Jan 31, 10:39 am, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
> Paavo Helde <myfirstn...@osa.pri.ee> wrote innews:Xns9D116950C4paavo256@216.196.109.131:
>
>
>
> > gervaz <ger...@gmail.com> wrote in news:f9eec1c9-5570-461a-bdec-
> > 6dec26dab...@o28g2000yqh.googlegroups.com:
>
> >> On Jan 30, 1:15 pm, James Kanze <james.ka...@gmail.com> wrote:
> >>> On Jan 30, 12:05 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
>
> >>> > James Kanze <james.ka...@gmail.com> writes:
> >>> > >There are no standard names for locales
> >>> > AFAIK, C90 defines a locale by the name of "C",
> >>> > which should also be visible from C++.
>
> >>> And Posix defines "POSIX". Neither of which are really useful
> >>> for anything.
>
> >>> --
> >>> James Kanze
>
> >> Ok, so I think that I will open my file specifying to use UTF-8
> >> encoding, but how can I do it in C++?
>
> > You can open it as a narrow stream and read in as binary UTF-8, or
> > (maybe) you can open it as a wide stream and get an automatic
> > translation from UTF-8 to wchar_t. The following example assumes that
> > you have a file test1.utf containing valid UTF-8 text. It reads the
> > file in as a wide stream and prints out the numeric values of all
> > wchar_t characters.
>
> > #include <iostream>
> > #include <fstream>
> > #include <locale>
> > #include <string>
>
> > int main() {
> > std::wifstream is;
> > const std::locale filelocale("en_US.UTF8");
> > is.imbue(filelocale);
> > is.open("test1.utf8");
>
> > std::wstring s;
> > while(std::getline(is, s)) {
> > for (std::wstring::size_type j=0; j<s.length(); ++j) {
> > std::cout << s[j] << " ";
> > }
> > std::cout << "\n";
> > }
> > }
>
> > (Tested on Linux with a recent gcc, I am not too sure if this works on
> > Windows. First, wchar_t in MSVC is too narrow for real Unicode, at
> > best one might get UTF-16 as a result.)
>
> For curiosity, I tested this also on Windows with MSVC9, and as expected
> it did not work, the locale construction immediately threw an exception
> (bad locale name). Neither did any alterations work ("english.UTF8",
> ".UTF8", ".utf-8", ".65001").
>
> Thus, if one wants any portability it seems the best approach currently
> is still to read in binary UTF-8 and perform any needed conversions by
> hand.
>
> Paavo

Under Windows, you have to use const std::locale filelocale
("English_Australia.1252") according to http://docs.moodle.org/en/Table_of_locales,
I've tested it in VC++08 and it works. Any suggestion in how to handle
the dualism?

Thanks, Mattia

== 4 of 5 ==
Date: Sun, Jan 31 2010 4:58 am
From: James Kanze

On Jan 31, 9:39 am, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
> Paavo Helde <myfirstn...@osa.pri.ee> wrote
> innews:Xns9D116950C4paavo256@216.196.109.131:

[...]
> >> Ok, so I think that I will open my file specifying to use UTF-8
> >> encoding, but how can I do it in C++?

> > You can open it as a narrow stream and read in as binary
> > UTF-8, or (maybe) you can open it as a wide stream and get
> > an automatic translation from UTF-8 to wchar_t. The
> > following example assumes that you have a file test1.utf
> > containing valid UTF-8 text. It reads the file in as a wide
> > stream and prints out the numeric values of all wchar_t
> > characters.

> > #include <iostream>
> > #include <fstream>
> > #include <locale>
> > #include <string>

> > int main() {
> > std::wifstream is;
> > const std::locale filelocale("en_US.UTF8");

The above line supposes 1) that you're on a Unix platform
(because it uses the Unix conventions for naming locales), and
2) that the "en_US.UTF8" locale has been installed---under that
name. (I've worked on a lot of systems where this was not the
case.)

> > is.imbue(filelocale);
> > is.open("test1.utf8");

> > std::wstring s;
> > while(std::getline(is, s)) {
> > for (std::wstring::size_type j=0; j<s.length(); ++j) {
> > std::cout << s[j] << " ";
> > }
> > std::cout << "\n";
> > }
> > }

> > (Tested on Linux with a recent gcc, I am not too sure if
> > this works on Windows. First, wchar_t in MSVC is too narrow
> > for real Unicode, at best one might get UTF-16 as a result.)

UTF-16 is "real Unicode". Just like UTF-8.

> For curiosity, I tested this also on Windows with MSVC9, and
> as expected it did not work, the locale construction
> immediately threw an exception (bad locale name). Neither did
> any alterations work ("english.UTF8", ".UTF8", ".utf-8",
> ".65001").

That's because Windows uses different conventions for naming
locales. (Windows Vista and later clames that names conforming
to RFC 4646 are used, see
http://msdn.microsoft.com/en-us/library/dd373814%28VS.85%29.aspx.
Except that RFC 4646 doesn't seem to contain information
concerning the character encoding. I'm guessing that Windows
would use the code page for this---65001 for UTF-8. But I don't
know how it has to be added to the "en-US".)

> Thus, if one wants any portability it seems the best approach
> currently is still to read in binary UTF-8 and perform any
> needed conversions by hand.

It should be sufficient to find out how the different locales are
named for each system, and read this information in from some
sort of configuration file.

--
James Kanze

== 5 of 5 ==
Date: Sun, Jan 31 2010 5:17 am
From: Paavo Helde

gervaz <gervaz@gmail.com> wrote in
news:a5a4ece2-5b9d-4846-a818-9de61c130654@r24g2000yqd.googlegroups.com:

> On Jan 31, 10:39 am, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
>> Paavo Helde <myfirstn...@osa.pri.ee> wrote
>> innews:Xns9D116950C4paavo256@2
> 16.196.109.131:
>>
>>
>>
>> > gervaz <ger...@gmail.com> wrote in news:f9eec1c9-5570-461a-bdec-
>> > 6dec26dab...@o28g2000yqh.googlegroups.com:
>>
>> >> On Jan 30, 1:15 pm, James Kanze <james.ka...@gmail.com> wrote:
>> >>> On Jan 30, 12:05 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
>>
>> >>> > James Kanze <james.ka...@gmail.com> writes:
>> >>> > >There are no standard names for locales
>> >>> > AFAIK, C90 defines a locale by the name of "C",
>> >>> > which should also be visible from C++.
>>
>> >>> And Posix defines "POSIX". Neither of which are really useful
>> >>> for anything.
>>
>> >>> --
>> >>> James Kanze
>>
>> >> Ok, so I think that I will open my file specifying to use UTF-8
>> >> encoding, but how can I do it in C++?
>>
>> > You can open it as a narrow stream and read in as binary UTF-8, or
>> > (maybe) you can open it as a wide stream and get an automatic
>> > translation from UTF-8 to wchar_t. The following example assumes
>> > that you have a file test1.utf containing valid UTF-8 text. It
>> > reads the file in as a wide stream and prints out the numeric
>> > values of all wchar_t characters.
>>
>> > #include <iostream>
>> > #include <fstream>
>> > #include <locale>
>> > #include <string>
>>
>> > int main() {
>> > std::wifstream is;
>> > const std::locale filelocale("en_US.UTF8");
>> > is.imbue(filelocale);
>> > is.open("test1.utf8");
>>
>> > std::wstring s;
>> > while(std::getline(is, s)) {
>> > for (std::wstring::size_type j=0; j<s.length(); ++j)
> {
>> > std::cout << s[j] << " ";
>> > }
>> > std::cout << "\n";
>> > }
>> > }
>>
>> > (Tested on Linux with a recent gcc, I am not too sure if this works
>> > on Windows. First, wchar_t in MSVC is too narrow for real Unicode,
>> > at best one might get UTF-16 as a result.)
>>
>> For curiosity, I tested this also on Windows with MSVC9, and as
>> expected it did not work, the locale construction immediately threw
>> an exception (bad locale name). Neither did any alterations work
>> ("english.UTF8", ".UTF8", ".utf-8", ".65001").
>>
>> Thus, if one wants any portability it seems the best approach
>> currently is still to read in binary UTF-8 and perform any needed
>> conversions by hand.
>>
>> Paavo
>
> Under Windows, you have to use const std::locale filelocale
> ("English_Australia.1252") according to
> http://docs.moodle.org/en/Table_of_locales, I've tested it in VC++08
> and it works. Any suggestion in how to handle the dualism?

Did you actually test the results? It seems this is reading UTF-8 in
unaltered, so there is no point to use a wide stream in the first place.

Paavo

==============================================================================
TOPIC: calling base class method from derive class object without virtual
http://groups.google.com/group/comp.lang.c++/t/44c777f6059b8071?hl=en
==============================================================================

== 1 of 4 ==
Date: Sun, Jan 31 2010 12:39 am
From: Tinku

#include<iostream>

class base
{
public:
int get();
int put();
};
class Derive: public base
{
public:
int get();
int put();
};

int base::get()
{
int x = 5;
return x;
}
int base::put()
{
int y = 10;
return y;
}
int Derive::get()

{
int a = 9;
return a;
}
int Derive::put()
{
int b = 20;
return b;
}

int main()
{
Derive d;
d.get(); // this line will return 9 according to class how can I
get 5 from here (base class method get();)

return 0;
}

How can I call base class method from derive class object without
using virtual.

== 2 of 4 ==
Date: Sun, Jan 31 2010 12:55 am
From: Robert Fendt

And thus spake Tinku <sumit15nov@gmail.com>
Sun, 31 Jan 2010 00:39:53 -0800 (PST):

> int main()
> {
> Derive d;
> d.get(); // this line will return 9 according to class how can I
> get 5 from here (base class method get();)
>
> return 0;
> }
>
> How can I call base class method from derive class object without
> using virtual.

Actually, virtual functions and polymorphy work precisely the other way round.

To answer your question, you can do two things: (1) specify the function by "d.Base::get()" (that _should_ work, though I hardly use that syntax); (2) get a pointer to 'd', cast that to a base pointer, and then call get() on it.

Regards,
Robert

== 3 of 4 ==
Date: Sun, Jan 31 2010 6:28 am
From: Saeed Amrollahi

On Jan 31, 11:39 am, Tinku <sumit15...@gmail.com> wrote:
> Hi
>
> #include<iostream>
>
> class base
> {
> public:
> int get();
> int put();};
>
> class Derive: public base
> {
> public:
> int get();
> int put();
>
> };
>
> int base::get()
> {
> int x = 5;
> return x;}
>
> int base::put()
> {
> int y = 10;
> return y;}
>
> int Derive::get()
>
> {
> int a = 9;
> return a;}
>
> int Derive::put()
> {
> int b = 20;
> return b;
>
> }
>
> int main()
> {
> Derive d;
> d.get(); // this line will return 9 according to class how can I
> get 5 from here (base class method get();)
>
> return 0;
>
> }
>
> How can I call base class method from derive class object without
> using virtual.

Actually, virtual functions are used to enable polymorphism and
calling
member functions of derived class object via base class objects
(pointers and references). If you want to call base class member
functions
through derived class object use something like this:

class Base {
public:
int get() { cout << "I am in base\n"; return 9; }
};

class Derived : public Base {
public:
int get() { return Base::get(); } // call base class members
};

int main()
{
Derived d;
d.get();
return 0;
}

== 4 of 4 ==
Date: Sun, Jan 31 2010 6:40 am
From: "Alf P. Steinbach"

* Tinku:
>
> int main()
> {
> Derive d;
> d.get(); // this line will return 9 according to class how can I
> get 5 from here (base class method get();)
>
> return 0;
> }
>
> How can I call base class method from derive class object

d.base::get();

> without using virtual.

I think you may have misunderstood 'virtual'; it sort of goes the other way.

Cheers & hth.,

- Alf

==============================================================================
TOPIC: Safe to use substr?
http://groups.google.com/group/comp.lang.c++/t/cece8bdad80abdbe?hl=en
==============================================================================

== 1 of 3 ==
Date: Sun, Jan 31 2010 12:47 am
From: Robert Fendt

And thus spake Immortal Nephi <Immortal_Nephi@hotmail.com>
Sat, 30 Jan 2010 18:49:34 -0800 (PST):

> I want to know that size_type returns –1 (minus one) is safe before I
> extract one string into two substrings. First example is safe and
> second example is not sure.
>
> const basic_string <char>::size_type npos = -1;

Why don't you just use std::string (which is a typedef of std::basic_string<char>)? It is more readable. Secondly, consider using string::npos instead of redefining it yourself. IIRC, the exact definition of npos is implementation-defined, thus it is dangerous to assume too much about it. It _is_ in fact defined as (size_t)-1 on almost all systems, but strictly speaking that depends on implementation and processor architecture.

> begin_index returns 0 and end_index returns 5. substr is safe.

Let's just say, it does what you expected it to do.

> Second example:
>
> begin_index = data.find_first_not_of( " ", end_index );
> end_index = data.find_first_of( " ", begin_index );
> token2 = data.substr( begin_index, end_index - begin_index );
> length_index = token2.length();
>
> begin_index returns 6 and end_index returns –1. Is substr safe for
> token2 because end_index returns –1 indicates space character is not
> found.

Yes. The standard specifies that its parameters are of type string::size_type, thus (at least in case of basic_string<char> and basic_string<wchar_t>) they are definitely unsigned. So in fact you are passing a _very_ large number as second parameter. My standard library docs state that if the second parameter points beyond the string, the end of the string is assumed instead (in fact, the default value for the second parameter is string::npos).

> Another question—is size_type the same as size_t? They are always
> unsigned maximum integer. Can I always copy variable from size_type
> to signed integer or unsigned integer?

First question: yes, and no. size_type gets into string via traits class templates. If you are not familiar with that technique, I suggest you read up on it, since it is used extensively throughout the STL. The point being that you can adapt basic_string to just about any type of underlying data, thus it does not assume that every length is of type size_t but rather gets its definition via a traits template.

That said, it _is_ true that basic_string<char> and basic_string<wchar_t> (i.e., string and wstring) do use a definition of size_type that is identical to size_t.

Second question: no. You cannot assume that size_t is the same size as "int". It might, or it might not (in fact, e.g. on newer MSVC++ in 64bit mode, it is not!). Secondly, while it is safe to cast an unsigned value to signed and back (the resulting value being IIRC guaranteed to be identical to the original), the semantics of interpreting an unsigned value as signed if it is 'too large' are unspecified.

On most systems, casting a large unsigned number to signed yields a negative number, since that is how signed values are usually implemented. However, I don't think the standard actually specifies that casting numeric_limits<max>(unsigned) to int actually yields "-1".

Regards,
Robert

== 2 of 3 ==
Date: Sun, Jan 31 2010 4:24 am
From: James Kanze

On Jan 31, 2:49 am, Immortal Nephi <Immortal_Ne...@hotmail.com> wrote:
> I want to know that size_type returns -1 (minus one)

size_type never contains -1. It can't, since it is an unsigned
type. (Also, variables and types don't "return" anything. Only
functions return things.)

> is safe before I extract one string into two substrings.
> First example is safe and second example is not sure.

> const basic_string <char>::size_type npos = -1;

Which results in an implicit conversion, according to the rules
of conversion of signed to unsigned. Basically, npos will be
the largest possible value of size_type.

But why are you defining this? (And why are you using
basic_string< char > instead of the typedef std::string?) If,
for convenience, you want a local constant variable (to be able
to write npos, rather than std::string::npos), then:

std::string::size_type const npos = std::string::npos;

is the simplest solution.

> basic_string< char >::size_type begin_index, end_index, length_index;

Just a general rule (good practice, not a language requirement):
don't define variables until you can initialize them.

> end_index = 0;

> string data = "Hello World!!", token1, token2;

> First example:

> begin_index = data.find_first_not_of( " ", end_index );
> end_index = data.find_first_of( " ", begin_index );
> token1 = data.substr( begin_index, end_index - begin_index );
> length_index = token1.length();

> begin_index returns 0 and end_index returns 5. substr is safe.

> Second example:

> begin_index = data.find_first_not_of( " ", end_index );
> end_index = data.find_first_of( " ", begin_index );
> token2 = data.substr( begin_index, end_index - begin_index );
> length_index = token2.length();

> begin_index returns 6 and end_index returns -1.

Again, end_index doesn't return anything; data.substring returns
std::string::npos. Which is the largest possible value which
can be held in an std::string::size_type.

> Is substr safe for token2 because end_index returns -1
> indicates space character is not found.

What does the documentation for substr say? What is the meaning
of the second argument? (I don't have my copy of the standard
handy to quote exactly, but what it says is something along the
lines of "the second argument specifies the maximum length of
the returned string", and that the return value is something
like "std::string( s.begin() + position, s.begin() + position +
std::min(length, s.size() - position))".)

> Another question---is size_type the same as size_t?

For std::string and std::wstring, yes. If you instantiate
std::basic_string with a non-standard allocator, not
necessarily.

> They are always unsigned maximum integer.

No. size_t is an unsigned integer large enough that the size of
the largest possible object can be represented in it. I've used
machines where size_t was 16 bits, for example.

> Can I always copy variable from size_type to signed integer or
> unsigned integer?

There are several possible answers to that question. If you
mean copy without loss of value, the answer is no; a lot of
modern machines have a 64 bit size_type, but a 32 bit integer
type, and there's no way you can convert a 64 bit type into a 32
bit type without loss of value.

Formally, of course, you can convert to the unsigned
integer---the results of converting to the signed integer are
implementation defined, but on most implementations, the
conversion is well defined as well. But if the value doesn't
fit, you'll get some other value.

Finally, in practice, it's likely that practical constraints
mean that you won't have strings larger than what can be
represented in an int. In which case, there's no problem.

> const basic_string <char>::size_type npos = -1;

> signed int sNpos = npos;

The results here are implementation defined. It's very likely
that sNpos will end up -1, but it's not guaranteed by the
standard. (And if sNpos does end up -1, then the conversion
back to size_t is guaranteed, so comparison with a size_t will
work.)

> unsigned int uNpos = npos;

Perfectly legal, but uNpos will not compare equal to npos on
most 64 bit machines.

I'm not too clear as to what your goal is. First, for better or
for worse, std::string uses an unsigned size_t for all of its
indexing and positionning. Mixing signed and unsigned in C++
often gives surprising results, and should be avoided. (Using
unsigned for numeric values should generally be avoided as well,
but the rule about not mixing is more critical, and trumps this
rule---if an external library uses unsigned, you should stick
with whatever type it uses.)

Also, and this is really just a question of personal preference,
but I prefer by far using the algorithms in <algorithm> to the
special member functions in std::string. Once you're used to
the standard library, it just seems more comfortable working
with iterators than with indexes. And it avoids all of the
issues related to unsigned types in C++. Given that any time
you're going to be processing text, you're going to be using
functions like isalpha, isspace, etc. a lot, the first thing to
do is to defined predicate object types for each of the
functions and its complement. (Macros make this fairly easy.)
Then you use them with std::find_if. So your initial example
becomes:

typedef std::string::const_iterator text_iterator;
std::string const data( "Hello, world!" );
text_iterator begin_token = std::find_if(data.begin(), data.end(),
is_not_space());
text_iterator end_token = std::find_if(begin_token, data.end(),
is_space());
// or is_not_alnum(), or whatever...
std::string const first_token( begin_token, end_token );

(As I say, this is a personal preference, not any established
rule. But IMHO, it fits in better with the philosophy of the
standard library.)

--
James Kanze

== 3 of 3 ==
Date: Sun, Jan 31 2010 4:29 am
From: James Kanze

On Jan 31, 8:47 am, Robert Fendt <rob...@fendt.net> wrote:
> And thus spake Immortal Nephi <Immortal_Ne...@hotmail.com>
> Sat, 30 Jan 2010 18:49:34 -0800 (PST):

> > I want to know that size_type returns -1 (minus one) is safe
> > before I extract one string into two substrings. First
> > example is safe and second example is not sure.

> > const basic_string <char>::size_type npos = -1;

> Why don't you just use std::string (which is a typedef of
> std::basic_string<char>)? It is more readable. Secondly,
> consider using string::npos instead of redefining it yourself.
> IIRC, the exact definition of npos is implementation-defined,
> thus it is dangerous to assume too much about it. It _is_ in
> fact defined as (size_t)-1 on almost all systems, but strictly
> speaking that depends on implementation and processor
> architecture.

The standard requires it to be defined as
static_cast< size_type >( -1 )
The implemenation and process architecture dependencies are in
the definition of size_type (which must be size_t in the default
allocator). The actual numeric value will vary, but it is well
defined, and used correctly as a sentinal value, there should be
no portability problems.

--
James Kanze

==============================================================================
TOPIC: Avoiding pointers to member functions
http://groups.google.com/group/comp.lang.c++/t/91122aae5ea3693a?hl=en
==============================================================================

== 1 of 3 ==
Date: Sun, Jan 31 2010 12:55 am
From: Marcel Müller

Hi!

Robert Fendt wrote:
> I am trying to find the best way to make part of a class's behaviour configurable during runtime, yet with as little overhead as possible. Maybe someone here has an idea? So far I have come up with 3 alternatives, all of which I do not really like for different reasons.

> (1) The 'simple' solution would be to implement various alternatives of the (private) member function in question, and use a "pointer to member function" to access it. Runtime configuration can be achieved by changing the pointer value, and a function pointer should be at least as efficient as a single vtable lookup. However, I loathe function pointer syntax, and they are clumsy to use (and they IMHO hide semantics by their convoluted syntax).

Function pointers are a solution if and only if the number of possible
cases is known at the design time of your class.
Nowadays there is no much performance impact compared to switch case. If
the number of cases is larger it can be considerably faster, unless the
behavior is switched many times, because you store the (partial) result
of a decision rather than taking the decision every time anew.

> (2) So, what about a functor class. It would have to be a member or friend of the outer class, and it cannot directly access the latters internals (even with 'friend' I would still have to give it a pointer to the current instance). I am also concerned about performance, since there is an additional level of indirection involved at several points when using this model.

Functors are something like user exits. They will not basically switch
functionality between a fixed number of cases. But they provide
extensibility to the user of a class instance. Of, course this is
restricted to the users permissions.

Functors have no explicit runtime overhead, since everything is done at
compile time unless you explicitly have run time code, e.g. in the
constructor. So you can control the overhead very well.
Because of this functors are often suitable in conjunction with templates.

> (3) Last but not least: strict OO design, make a base class and several differently behaving child classes, and use a factory pattern to achieve at least some level of runtime flexibility. This is less flexible, so I do not really like that possibility either. Also there is the risk of duplicate code.

Inheritance is a solution if and only if the behavior of existing
objects never changes over their lifetime. The performance is comparable
to the function pointers, because the vtable calls are similar to
function pointers.

But if your behavior is constant over object lifetime there is another
solution. As cr88192 already said you can combine 2 and 3. And if you
use a template base class which takes the functors as template arguments
you will end up with no runtime overhead.

However, the same will happen with an optimizing compiler, if you pass
an enumeration type as template argument to your class to switch the
behavior and use switch/case again. If you do not like the resulting
long type names, feel free to use typedefs and end up with the same type
names as with (3). Of course, the additional restriction of limited
cases applies here.

Marcel

== 2 of 3 ==
Date: Sun, Jan 31 2010 12:58 am
From: KjellKod

On Jan 30, 8:00 pm, Robert Fendt <rob...@fendt.net> wrote:
> Hi all,
>
> I am trying to find the best way to make part of a class's behaviour configurable during runtime, yet with as little overhead as possible. Maybe someone here has an idea? So far I have come up with 3 alternatives, all of which I do not really like for different reasons.
>
> (1) The 'simple' solution would be to implement various alternatives of the (private) member function in question, and use a "pointer to member function" to access it. Runtime configuration can be achieved by changing the pointer value, and a function pointer should be at least as efficient as a single vtable lookup. However, I loathe function pointer syntax, and they are clumsy to use (and they IMHO hide semantics by their convoluted syntax).
>
> (2) So, what about a functor class. It would have to be a member or friend of the outer class, and it cannot directly access the latters internals (even with 'friend' I would still have to give it a pointer to the current instance). I am also concerned about performance, since there is an additional level of indirection involved at several points when using this model.
>
> (3) Last but not least: strict OO design, make a base class and several differently behaving child classes, and use a factory pattern to achieve at least some level of runtime flexibility. This is less flexible, so I do not really like that possibility either. Also there is the risk of duplicate code.
>
> So, would someone please tell which obvious clear, flexible and efficient solution I am missing?
>
> Regards,
> Robert

Instead of functor class why not use the same functionality but
through recognized good software solutions? I'm thinking of the
different "signal and slots" implementations that are out there.
Boost, Qt (the original signal-and-slot), libsig++. Just google and
you'll find a few more.

Regards
Kjell

== 3 of 3 ==
Date: Sun, Jan 31 2010 4:35 am
From: James Kanze

On Jan 30, 7:00 pm, Robert Fendt <rob...@fendt.net> wrote:

> I am trying to find the best way to make part of a class's
> behaviour configurable during runtime, yet with as little
> overhead as possible. Maybe someone here has an idea? So far I
> have come up with 3 alternatives, all of which I do not really
> like for different reasons.

> (1) The 'simple' solution would be to implement various
> alternatives of the (private) member function in question, and
> use a "pointer to member function" to access it. Runtime
> configuration can be achieved by changing the pointer value,
> and a function pointer should be at least as efficient as a
> single vtable lookup. However, I loathe function pointer
> syntax, and they are clumsy to use (and they IMHO hide
> semantics by their convoluted syntax).

Also, they tend to be much less efficient than calling a virtual
function.

But the real arguments against them are those you raised, along
with the fact that you cannot associate data with them. (You
don't say what sort of configuration you're dealing with, but
it's easy to imagine configurations with parameters, e.g.
scaling or translations.)

> (2) So, what about a functor class. It would have to be a
> member or friend of the outer class, and it cannot directly
> access the latters internals (even with 'friend' I would still
> have to give it a pointer to the current instance). I am also
> concerned about performance, since there is an additional
> level of indirection involved at several points when using
> this model.

I doubt that the performance issues will be relevant. It's a
possible solution.

> (3) Last but not least: strict OO design, make a base class
> and several differently behaving child classes, and use a
> factory pattern to achieve at least some level of runtime
> flexibility. This is less flexible, so I do not really like
> that possibility either. Also there is the risk of duplicate
> code.

I'm not too sure where you see the code duplication; the derived
class can always call functions in the base class for common
funtionality.

What you describe is basically the template method pattern. It
has the drawback that you can't change the configuration once
the class has been instantiated.

> So, would someone please tell which obvious clear, flexible
> and efficient solution I am missing?

It sounds to me that you're looking for the strategy pattern,
but it's hard to say without more details.

--
James Kanze

==============================================================================
TOPIC: Discount Wholesale Armani Jeans Christian Audigier Jeans ED Hardy Jeans
(www.vipchinatrade.com)
http://groups.google.com/group/comp.lang.c++/t/62cb14b1f5535017?hl=en
==============================================================================

== 1 of 3 ==
Date: Sun, Jan 31 2010 1:47 am
From: yoyo

@@@@Free shipping Cheap True Religion Jeans ARMANI jeans belts
Wholesale paypal payment <www.vipchinatrade.com>

Discount Wholesale Affliction Jeans <free shipping paypal payment>
Discount Wholesale AK Jeans ( www.vipchinatrade.com )
Discount Wholesale Armani Jeans
Discount Wholesale Artful Dodger Jeans <free shipping paypal payment>
Discount Wholesale BAPE Jeans
Discount Wholesale BBC Jeans ( www.vipchinatrade.com )
Discount Wholesale Black Label Jeans
Discount Wholesale Cavalli Jeans
Discount Wholesale Christian Audigier Jeans
Discount Wholesale Coogi Jeans
Discount Wholesale Crown Holder Jeans ( www.vipchinatrade.com )
Discount Wholesale D&G Jeans
Discount Wholesale Diesel Jeans
Discount Wholesale ECKO Jeans ( www.vipchinatrade.com )
Discount Wholesale ED Hardy Jeans
Discount Wholesale Evisu Jeans
Discount Wholesale G-STAR Jeans <free shipping paypal payment>
Discount Wholesale GUCCI Jeans
Discount Wholesale Iceberg Jeans
Discount Wholesale Kanji Jeans ( www.vipchinatrade.com )
Discount Wholesale Laguna Beach Jeans
Discount Wholesale Levi s Jeans
Discount Wholesale LRG Jeans <free shipping paypal payment>
Discount Wholesale LV Jeans
Discount Wholesale Prada Jeans ( www.vipchinatrade.com )
Discount Wholesale RMC Jeans
Discount Wholesale Roca Wear Jeans <free shipping paypal payment>
Discount Wholesale Rock&Republic Jeans
Discount Wholesale True Religion Jeans <free shipping paypal payment>
Discount Wholesale Versace Jeans
Discount Wholesale ZEN Jeans ( www.vipchinatrade.com )

== 2 of 3 ==
Date: Sun, Jan 31 2010 7:52 am
From: wendy

Cheap Wholesale Shox NZ <www.vipchinatrade.com> paypal payment
Cheap Wholesale Shox OZ <www.vipchinatrade.com> free shipping
Cheap Wholesale Shox R2 <www.vipchinatrade.com> paypal payment
Cheap Wholesale Shox R3 <www.vipchinatrade.com> paypal payment
Cheap Wholesale Shox R3+R4 <www.vipchinatrade.com> paypal payment
Cheap Wholesale Shox R4 <www.vipchinatrade.com> paypal payment
Cheap Wholesale Shox R5 <www.vipchinatrade.com> free shipping
Cheap Wholesale Shox Reverie lover
Cheap Wholesale Shox RZ <www.vipchinatrade.com> paypal payment
Cheap Wholesale Shox TL <www.vipchinatrade.com> free shipping
Cheap Wholesale Shox Torch <www.vipchinatrade.com> paypal payment
Cheap Wholesale Shox TZ <www.vipchinatrade.com> paypal payment

Cheap Wholesale Nike Air Max 87 <www.vipchinatrade.com> free shipping
Cheap Wholesale Nike Air Max 89 <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Nike Air Max 90 <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Nike Air Max 91 <www.vipchinatrade.com> free shipping
Cheap Wholesale Nike Air Max 92 Man <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Nike Air Max 93 <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Nike Air Max 95 <www.vipchinatrade.com> free shipping
Cheap Wholesale Nike Air Max 97 <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Nike Air Max 180 Man <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Nike Air Max 2006 <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Nike Air Max 2009 <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Nike Air Max Clssic BW <www.vipchinatrade.com> free
shipping
Cheap Wholesale Nike Air Max LTD <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Nike Air Max Skyline <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Nike Air Max STAB <www.vipchinatrade.com> free
shipping
Cheap Wholesale Nike Air Max Tailwind <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Nike Air Max TN <www.vipchinatrade.com> paypal
payment

Air Force one <www.vipchinatrade.com> paypal payment
Cheap Wholesale Air Force One Man <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Air Force One Women <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Air Force One M&W <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Air Force one 25 Man <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Air Force One 25 Women <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Air Force One Kid <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Air Force one Mid Man <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Air Force one Mid Women <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Air Force one Hight Women <www.vipchinatrade.com>
paypal payment

== 3 of 3 ==
Date: Sun, Jan 31 2010 8:03 am
From: wendy

==============================================================================
TOPIC: templates + RTTI + shared library = impossible?
http://groups.google.com/group/comp.lang.c++/t/7cdc437c782232bc?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Jan 31 2010 3:29 am
From: James Kanze

On Jan 30, 6:31 pm, legalize+jee...@mail.xmission.com (Richard) wrote:
> James Kanze <james.ka...@gmail.com> spake the secret code
> <bf3a79e7-9307-44eb-8b60-4897105cd...@c4g2000yqa.googlegroups.com> thusly:

> >On Jan 29, 12:27 am, "BGB / cr88192" <cr88...@hotmail.com> wrote:
> >> "Dan Caugherty" <dan.caughe...@gmail.com> wrote in message

> >> similar issues can also manifest in other ways as well:
> >> malloc/free not working between DLL's [...]

> >This is a purely Windows problem, present probably because
> >Windows doesn't bundle the CRT DLL's with the OS (I think). [...]

> The issue is that each module (DLL or EXE) has its own Win32
> heap. Memory allocated by a module will be allocated from
> that module's heap and must be freed by code in that module to
> be freed from the corect heap.

That's not really an issue for C++ programs, at least those that
are using new, and not the Windows API directly, to allocate
memory. C++ programs don't allocate memory from Windows, they
call the operator new function, which in turn calls malloc.
And malloc is in the CRT library. If the CRT library is in a
distinct DLL, all Windows allocations will be from that DLL, and
will use that DLL's heap. If you statically link a separate
instance of the CRT with each DLL, then each DLL will have a
separate instance of the operator new function and malloc, and
will use its own heap.

The arrangement of using separate system heaps for each DLL
seems like a very poor design decision to me (supposing you're
right---the Windows documentation says that "Each *process* has
a default heap*---, but it doesn't really matter here. Even
with one common system heap, each instance of malloc/free will
use a different set of static variables to manage this heap, and
memory returned by a call to HeapAlloc in one instance of malloc
will not be known in any other instance.

As I said, the motivation for statically linking the CRT is that
it isn't bundled with the OS. If you link with it dynamically,
you either have to require that all systems on which you run
have it installed, in addition to the standard system stuff, or
that you bundle it into your deployment package. (The Microsoft
site has extensive documentation about these issues. I'd
suggest that anyone deploying code written for Windows which
uses DLL's wade through it. I'd also suggest avoiding DLL's in
your own application, if possible, since they do make deployment
more complicated.)

--
James Kanze

== 2 of 2 ==
Date: Sun, Jan 31 2010 3:34 am
From: James Kanze

On Jan 30, 9:32 pm, "BGB / cr88192" <cr88...@hotmail.com> wrote:
> "Richard" <legalize+jee...@mail.xmission.com> wrote in message
> news:hk1tta$jrg$1@news.xmission.com...
> > James Kanze <james.ka...@gmail.com> spake the secret code
> > <bf3a79e7-9307-44eb-8b60-4897105cd...@c4g2000yqa.googlegroups.com> thusly:

> >>On Jan 29, 12:27 am, "BGB / cr88192" <cr88...@hotmail.com> wrote:
> >>> "Dan Caugherty" <dan.caughe...@gmail.com> wrote in message

> >>> similar issues can also manifest in other ways as well:
> >>> malloc/free not working between DLL's [...]

> >>This is a purely Windows problem, present probably because
> >>Windows doesn't bundle the CRT DLL's with the OS (I think). [...]

> > The issue is that each module (DLL or EXE) has its own Win32
> > heap. Memory allocated by a module will be allocated from
> > that module's heap and must be freed by code in that module
> > to be freed from the corect heap.

> yeah.

No.

> partial solution: don't pass memory ownership across DLL boundaries...

It's not a problem if you link your modules correctly.

> but, yeah, DLL's do have at least the major good point of
> avoiding lots of 10 or 20 MB EXE's (instead, one gets maybe
> 10-20 1 MB DLL's...), and a bunch of smaller EXE's...

So how is this a good point? You still end up with 10 or 20 MB
used on the disk, and you've made deployment significantly more
complicated, and introduced yet another way things can go wrong:
mixing versions of the DLL's. And of course, DLL's and
templates don't mix very well.

> another good point, is that one need only remember to link in
> those they need, and any others "come along for the ride",
> which improves on the static-lib case, of having to remember
> to link in every static lib referenced both directly and
> indirectly, which can itself become a non-trivial problem.

Sorry, I don't understand this one. Are you using static libs,
or dynamically linked objects? What you (generally) want to
avoid is using a static library for something that will be used
from several different DLL's---that's what causes problems.

> as well as simplifying dynamically-loadable components, ...

> ...

> so, in general, they are a good tradeoff for their costs
> (sometimes questionable linkage semantics, having to annotate
> declarations, having to worry about moving around a small army
> of DLL's and keeping them visible from the current directory,
> ...).

DLL's are an added complication. You use them when you need
them, but you should avoid them otherwise.

--
James Kanze

==============================================================================
TOPIC: Another strange linux kernel change
http://groups.google.com/group/comp.lang.c++/t/e05a4158a9750a03?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Jan 31 2010 4:04 am
From: "Man-wai Chang to The Door (24000bps)"

> Maybe you know more about the pre-conditions satisfied when this
> particular piece of code is run, but from reading just what you posted
> j is used on the very next line, so I would assume it matters whether
> it starts at i or i+1.

If that line was critical, it should have caused a kernel error in the
very beginning... :)

--
@~@ Might, Courage, Vision, SINCERITY.
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (x86_64 Ubuntu 9.10) Linux 2.6.32.7
^ ^ 20:04:01 up 1 day 4:10 1 user load average: 1.21 1.11 1.09
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

==============================================================================
TOPIC: Link error in using queue class
http://groups.google.com/group/comp.lang.c++/t/dff9655ccbceda85?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Jan 31 2010 4:47 am
From: Saeed Amrollahi

Dear all
Hi

I am working on a program and I use queue of wstring:
It compiles properly but at link error, I get the following Link
error:

DBBroker.obj : error LNK2005: "public: static int const
std::deque<class std::basic_string<wchar_t,struct
std::char_traits<wchar_t>,class std::allocator<wchar_t> >,class
std::allocator<class std::basic_string<wchar_t,struct
std::char_traits<wchar_t>,class std::allocator<wchar_t> > >
>::_EEM_DS" (?_EEM_DS@?$deque@V?$basic_string@_WU?
$char_traits@_W@std@@V?$allocator@_W@2@@std@@V?$allocator@V?
$basic_string@_WU?$char_traits@_W@std@@V?
$allocator@_W@2@@std@@@2@@std@@$$Q2HB) already defined in
TSPipingNetworkMapSys.obj

I traced _EEM_DS in deque header file and it has the following
definition:
static const int _EEM_DS = _DEQUESIZ;
and _DEQUESIZ is a macro.
May be some implementation leakage was occurred .

FYI, DBBroker.cpp is one source file and TSPipingNetworkMapSys.cpp is
the main
cpp file which contains the main function. I use Visual Studio 2008.

Thanks in advance for your help
-- Saeed Amrollahi

== 2 of 2 ==
Date: Sun, Jan 31 2010 4:47 am
From: Saeed Amrollahi

Dear all
Hi

I am working on a program and I use queue of wstring:
It compiles properly but at link error, I get the following Link
error:

I traced _EEM_DS in deque header file and it has the following
definition:
static const int _EEM_DS = _DEQUESIZ;
and _DEQUESIZ is a macro.
May be some implementation leakage was occurred .

FYI, DBBroker.cpp is one source file and TSPipingNetworkMapSys.cpp is
the main
cpp file which contains the main function. I use Visual Studio 2008.

Thanks in advance for your help
-- Saeed Amrollahi

==============================================================================
TOPIC: Looking for C++ IDE,...
http://groups.google.com/group/comp.lang.c++/t/e8a1db0949215858?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Jan 31 2010 8:02 am
From: Branimir Maksimovic

Kerem Gümrükcü wrote:
> Hi,
>
> i am looking fo a (free, non-microsoft!) C++ IDE for windows, that
> can do most of the MSVC++ stuff (resources, projects, etc.)

I used code blocks, but vc express is better anyway, and pretty
good. For resource editing and things missing in free version of vc ide,
you can find free substitutes.
Besides that my main c++ ide is
http://joe-editor.sourceforge.net/index.html

Greets

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

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

Sunday, January 31, 2010

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

No comments:

Blog Archive

About Me