http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* Does anyone else wish the C++ standards committee would give us parity with
other programming languages? - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/65479c8a9a474e0b?hl=en
* Is this a good reference-counting smart pointer class? - 2 messages, 2
authors
http://groups.google.com/group/comp.lang.c++/t/41558400ad1ce160?hl=en
* Nomenclature for interger size in C/C++ - 9 messages, 5 authors
http://groups.google.com/group/comp.lang.c++/t/d94de8ebc4095151?hl=en
* Standard C++ way to generate a Jump Table ??? - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/7686e7082cfac191?hl=en
* Help understanding this function - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/69b739b156823692?hl=en
* Question about reading from stream. - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/52af4ea746edf596?hl=en
* Do vector iterators remain valid after resize() if base pointer of elements
remains unchanged? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/a2112c3799287ef5?hl=en
* Unignorable return value - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/3b14b8ccfba9854c?hl=en
* A question about a section in "Inside the C++ Object Model" - 2 messages, 2
authors
http://groups.google.com/group/comp.lang.c++/t/f0c8344a7742e492?hl=en
* Hai ia am asha... - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/dcac4478fea117d0?hl=en
* Hai i am asha... - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/ba63c7296445cfdd?hl=en
* Hot sell jersey NFL NHL MLB NBA all star at China www.guoshitrade.com
wholesale freeshipping!!! - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/cab8867dad477410?hl=en
==============================================================================
TOPIC: Does anyone else wish the C++ standards committee would give us parity
with other programming languages?
http://groups.google.com/group/comp.lang.c++/t/65479c8a9a474e0b?hl=en
==============================================================================
== 1 of 3 ==
Date: Fri, Mar 27 2009 10:34 pm
From: sebastian
>> Or better yet, force them(C#, Java, etc) to do the catch up game....
What are you talking about? Catch up *how*? You can do just about
anything with C++. You might have to write it from scratch, of
course...
== 2 of 3 ==
Date: Sat, Mar 28 2009 4:23 am
From: James Kanze
On Mar 27, 6:55 pm, Anonymous Infidel <messiah2...@yahoo.com> wrote:
> > >Or better yet, force them(C#, Java, etc) to do the catch up game....
> > Might be useful if you would clarify what in your mind is making the
> > C++ language trail behind these other languages.
> Simple...That would be all the things they can do that C++ can't.
Which are? And what about all the things you can do in C++ that
you can't do in Java.
> Note: You can use Google to see the differences between C++
> and other programming languages.
Who needs to? Most of us have actively programmed in several
different languages. Including some of the newer ones, like
Java or C#.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
== 3 of 3 ==
Date: Sat, Mar 28 2009 4:28 am
From: James Kanze
On Mar 27, 10:09 pm, Arne Mertz <n...@arne-mertz.de> wrote:
> c...@mailvault.com schrieb:
> The problem is: some things that could be considered
> weaknesses in a certain context/with respect to a certain
> application you want to code, are strengths in other
> contexts/applications.
The problem is, exactly, that one size doesn't fit all.
> There is no means to have a perfect language, so in most cases
> there is no sense in wanting your favourite feature of other
> languages in C++ (or Java). The standards committee won't
> ever give us parity with other programming languages WRT
> automatic memory management, e.g. garbage collectors and all
> that stuff that make Java & Co. so "easy to use".
I wouldn't bet on garbage collectors. The committee has voted
in favor of them, although for schedule considerations, not
right away.
> They won't because C++ is not designed to have GC. Its not a
> bug, its a feature that we must/can manage the free stor
> ourselves.
Not really. It's a feature that we *can* manage it ourselves,
when appropriate. But the basic philosophy of C++ is to give
the programmer the choice, which means garbage collection when
appropriate.
> At any time there are lots of people complaining about "flaws"
> that C++ has and that should be correctet - not realizing that
> "correcting" these flaws would cut away some basic features of
> the language.
Or break backwards compatibility. The biggest "flaw" C++ has is
a totally broken declaration syntax, which leads to all sorts of
ambiguities and problems. It inherited that flaw from C, and
anything which might fix it would probably also break all, or
almost all existing code.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
==============================================================================
TOPIC: Is this a good reference-counting smart pointer class?
http://groups.google.com/group/comp.lang.c++/t/41558400ad1ce160?hl=en
==============================================================================
== 1 of 2 ==
Date: Sat, Mar 28 2009 12:32 am
From: Protoman
Is this a good reference-counting smart pointer class?
// begin code
-------------------------------------------------------------------------------------------------------------------
class SmrtPtrDB
{
public:
SmrtPtrDB(int status=1):num(status){}
SmrtPtrDB(const SmrtPtrDB& rhs):num(rhs.num){}
~SmrtPtrDB(){}
void add(){num++;}
void sub(){num--;}
int status(){return num;}
private:
int num;
};
class NullPtr{};
template<class T>
class SmrtPtr
{
public:
explicit SmrtPtr<T>(T* obj=0):ptr(obj),DataBase(new SmrtPtrDB){}
SmrtPtr<T>(const SmrtPtr<T>& rhs):ptr(rhs.ptr),DataBase(new
SmrtPtrDB(rhs.DataBase->status())) {DataBase->add();}
~SmrtPtr<T>()
{
DataBase->sub();
if(DataBase->status()==0)
{delete ptr; delete DataBase;}
else {delete DataBase;}
}
void operator=(T* val)
{
SmrtPtr<T> temp(val);
swap(temp);
}
SmrtPtr<T>& operator=(const SmrtPtr<T>& rhs)
{
SmrtPtr<T> temp(rhs);
swap(temp);
return *this;
}
bool operator==(const SmrtPtr<T>& rhs)const {if(ptr==rhs.ptr)return
true;else return false;}
bool operator!=(const SmrtPtr<T>& rhs)const {if(ptr!=rhs.ptr)return
true;else return false;}
bool operator<=(const SmrtPtr<T>& rhs)const {if(ptr<=rhs.ptr)return
true;else return false;}
bool operator>=(const SmrtPtr<T>& rhs)const {if(ptr>=rhs.ptr)return
true;else return false;}
int status(){return DataBase->status();}
T& operator*()const {if(ptr==0)throw NullPtr();else return *ptr;}
T* operator->()const {if(ptr==0)throw NullPtr();else return ptr;}
operator T*()const {if(ptr==0)throw NullPtr();else return ptr;}
private:
void swap(SmrtPtr<T>& rhs)
{
std::swap(DataBase,rhs.DataBase);
std::swap(ptr,rhs.ptr);
}
mutable SmrtPtrDB* DataBase;
T* ptr;
};
//end of code
---------------------------------------------------------------------------------------------------------------------------------
How do I improve this class? Is there anything "wrong" with it?
== 2 of 2 ==
Date: Sat, Mar 28 2009 1:12 am
From: Juha Nieminen
Protoman wrote:
> explicit SmrtPtr<T>(T* obj=0):ptr(obj),DataBase(new SmrtPtrDB){}
> SmrtPtr<T>(const SmrtPtr<T>& rhs):ptr(rhs.ptr),DataBase(new
> SmrtPtrDB(rhs.DataBase->status())) {DataBase->add();}
No, this definitely doesn't work.
You are *not* sharing the 'DataBase' instance between the 'SmrtPtr'
copies pointing to the same object. In other words, each instance of
'SmrtPtr' has its own instance of 'DataBase'. Basically there's no
difference between what you have done there and having a 'SmrtPtrDB'
instance directly as a member variable (rather than it being allocated
dynamically).
You are copying the reference count from 'rhs' to the newly-created
instance of 'DataBase' in the copy constructor. How do you think it's
going to notice if that other 'SmrtPtr' is destroyed? It retains no
connection to it whatsoever, so there's no way it can notice that it has
disappeared.
Moreover, that other 'SmrtPtr' instance is not going to notice that a
new 'SmrtPtr' instance was created to point to the same object. The
reference count of the former will be unmodified. Thus when the former
is destroyed, it will delete the object, and not the new 'SmrtPtr'
object will point to deleted memory.
==============================================================================
TOPIC: Nomenclature for interger size in C/C++
http://groups.google.com/group/comp.lang.c++/t/d94de8ebc4095151?hl=en
==============================================================================
== 1 of 9 ==
Date: Sat, Mar 28 2009 1:08 am
From: Giuliano Bertoletti
Hello,
I was just wondering if there's a standard nomenclature which forces any
C/C++ compiler to instantiate integer variables of a givens size.
For example suppose my program wishes to deal with a 64-bit integer.
Assuming that a platform/compiler supports it, how shall I instantiate a
variable of that size.
I usually typedef under MSVC++ something like:
typedef __int64 WORD64;
and then instntiate
WORD64 v;
but I would like to have such a definition on a standard header file
which won't forces me to #ifdef depending on the platform and most
importantly not use WORD64 but something recognized universally.
Is there such a definition somewhere ?
Regards,
Giuliano Bertoletti.
== 2 of 9 ==
Date: Sat, Mar 28 2009 1:24 am
From: Ian Collins
Giuliano Bertoletti wrote:
>
> Hello,
>
> I was just wondering if there's a standard nomenclature which forces any
> C/C++ compiler to instantiate integer variables of a givens size.
Use the widely supported C99 fixed width types (int64_t and friends)
from stdint.h.
--
Ian Collins
== 3 of 9 ==
Date: Sat, Mar 28 2009 2:41 am
From: Giuliano Bertoletti
Ian Collins ha scritto:
> Giuliano Bertoletti wrote:
>>
>> Hello,
>>
>> I was just wondering if there's a standard nomenclature which forces
>> any C/C++ compiler to instantiate integer variables of a givens size.
>
> Use the widely supported C99 fixed width types (int64_t and friends)
> from stdint.h.
>
Thanks.
My MSVC++6.0 compiler is older than 1999 and doesn't know anything about
stdint.h. Anyway I found a portable stdint.h so at least types are standard.
By the way, is the suffix i64 standard for the 64-bit integer constant ?
For example, should I expect this to compile everywhere ?
int64_t v;
...
v |= (1i64 << 48); // set bit 48
Regards,
Giuliano Bertoletti.
== 4 of 9 ==
Date: Sat, Mar 28 2009 2:55 am
From: Ian Collins
Giuliano Bertoletti wrote:
> Ian Collins ha scritto:
>> Giuliano Bertoletti wrote:
>>>
>>> Hello,
>>>
>>> I was just wondering if there's a standard nomenclature which forces
>>> any C/C++ compiler to instantiate integer variables of a givens size.
>>
>> Use the widely supported C99 fixed width types (int64_t and friends)
>> from stdint.h.
>>
>
> Thanks.
>
> My MSVC++6.0 compiler is older than 1999 and doesn't know anything about
> stdint.h. Anyway I found a portable stdint.h so at least types are
> standard.
It's older than C++98 as well. Well passed its use by date.
> By the way, is the suffix i64 standard for the 64-bit integer constant ?
No, the closest (again from C99) would be 'LL' (long long is at least 64
bits).
--
Ian Collins
== 5 of 9 ==
Date: Sat, Mar 28 2009 3:02 am
From: Arne Mertz
Ian Collins schrieb:
> Giuliano Bertoletti wrote:
>>
>> Hello,
>>
>> I was just wondering if there's a standard nomenclature which forces
>> any C/C++ compiler to instantiate integer variables of a givens size.
>
> Use the widely supported C99 fixed width types (int64_t and friends)
> from stdint.h.
>
Or use boost::integers that is designed to do the same job
"whithout resorting to undefined behaviour in terms of the 1998 C++
Standard."
http://www.boost.org/doc/libs/1_38_0/libs/integer/index.html
Arne
== 6 of 9 ==
Date: Sat, Mar 28 2009 5:17 am
From: Vaclav Haisman
Giuliano Bertoletti wrote, On 28.3.2009 10:41:
> Ian Collins ha scritto:
>> Giuliano Bertoletti wrote:
>>>
>>> Hello,
>>>
>>> I was just wondering if there's a standard nomenclature which forces
>>> any C/C++ compiler to instantiate integer variables of a givens size.
>>
>> Use the widely supported C99 fixed width types (int64_t and friends)
>> from stdint.h.
>>
>
> Thanks.
>
> My MSVC++6.0 compiler is older than 1999 and doesn't know anything about
Throw it away and burn it.
> stdint.h. Anyway I found a portable stdint.h so at least types are
> standard.
Boost ships with cstdint.hpp header that is basically reimplentation of C99
stdint.h in C++. It has very little dependencies on the rest of the Boost,
you should be able to use it nearly stand alone.
>
> By the way, is the suffix i64 standard for the 64-bit integer constant ?
No, it is not.
>
> For example, should I expect this to compile everywhere ?
>
> int64_t v;
> ...
> v |= (1i64 << 48); // set bit 48
No, you should not.
--
VH
== 7 of 9 ==
Date: Sat, Mar 28 2009 6:16 am
From: Giuliano Bertoletti
Vaclav Haisman ha scritto:
>>
>> My MSVC++6.0 compiler is older than 1999 and doesn't know anything about
> Throw it away and burn it.
>
I would but I cannot.
I've a lot of code which has been written with and for that compiler;
migrating it even to a new compiler of the same brand would mean a lot
of effort in re-compiling and testing.
Not to mention the time it takes to get you accustomed to the new
compiler/IDE interface.
Even new applications written from scratch benefit using my older
routines which have a lot of miles under their wheels and you know they
work fine.
Learning how to program a GUI is also a very expensive task in terms of
time and I would stick to Windows-MFC if possible, which is a good
compromise in availability, functionality, compatibility and resources
requirements (that's of course only my personal opinion, I know many of
you would argue otherwise).
However MFC is badly supported by new compilers that are oriented to
.NET framework.
Regards,
Giuliano Bertoletti.
== 8 of 9 ==
Date: Sat, Mar 28 2009 7:28 am
From: Victor Bazarov
Giuliano Bertoletti wrote:
> Vaclav Haisman ha scritto:
>
>>>
>>> My MSVC++6.0 compiler is older than 1999 and doesn't know anything about
>> Throw it away and burn it.
>>
>
> I would but I cannot.
>
> I've a lot of code which has been written with and for that compiler;
> migrating it even to a new compiler of the same brand would mean a lot
> of effort in re-compiling and testing.
>
> Not to mention the time it takes to get you accustomed to the new
> compiler/IDE interface.
So, instead of learning to drive and operate a new, clean, fast,
spacious, and otherwise modern vehicle, you'd rather drive the old,
smoldering, slow, rusty, falling apart, not to mention incapable of
fulfilling some of your requirements, clunker? Good for you. And the
users of your program. I am guessing you've not got many, and the ones
you do have, keep their balls in your capable hands (NTTIAWWT).
> Even new applications written from scratch benefit using my older
> routines which have a lot of miles under their wheels and you know they
> work fine.
If they work fine, they would work just as fine compiled with a more
modern compiler. Why would you thing they are going to start failing?
Is that because they are held together with a piece of old twine and a
prayer?
> Learning how to program a GUI is also a very expensive task in terms of
> time and I would stick to Windows-MFC if possible, which is a good
> compromise in availability, functionality, compatibility and resources
> requirements (that's of course only my personal opinion, I know many of
> you would argue otherwise).
Nope. Why argue with you? You seem to have formed your opinion way
before you came here, and are not going to change it no matter how
logical or sensible our argument can be.
MFC is still supported by the most modern of Visual C++ incarnations.
Most of older programs don't require much attention. Yes, you need to
port (to straighten out the code you had to write to overcome the
deficiencies of the pre-Standard compiler and its library), yes, you
need testing. Are you sure you don't need all that with any change
you're trying to squeeze into your code made in and for that severely
out of date compiler?
> However MFC is badly supported by new compilers that are oriented to
> .NET framework.
Nonsense. You've apparently not been keeping up, so your opinion can't
really count, can it? Post your questions/concerns to the newsgroup
'microsoft.public.vc.language' or 'microsoft.public.vc.mfc' and see what
reaction you get.
Good luck!
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
== 9 of 9 ==
Date: Sat, Mar 28 2009 7:29 am
From: Victor Bazarov
Arne Mertz wrote:
> Ian Collins schrieb:
>> Giuliano Bertoletti wrote:
>>>
>>> Hello,
>>>
>>> I was just wondering if there's a standard nomenclature which forces
>>> any C/C++ compiler to instantiate integer variables of a givens size.
>>
>> Use the widely supported C99 fixed width types (int64_t and friends)
>> from stdint.h.
>>
> Or use boost::integers that is designed to do the same job "whithout
> resorting to undefined behaviour in terms of the 1998 C++ Standard."
>
> http://www.boost.org/doc/libs/1_38_0/libs/integer/index.html
Boost still suports VC6? Wow... Those guys *are* generous.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
==============================================================================
TOPIC: Standard C++ way to generate a Jump Table ???
http://groups.google.com/group/comp.lang.c++/t/7686e7082cfac191?hl=en
==============================================================================
== 1 of 2 ==
Date: Sat, Mar 28 2009 1:42 am
From: "Ivan A. Kosarev"
Paavo Helde wrote:
> "Ivan A. Kosarev" <ik@unicals.com> kirjutas:
>> b) the set of values of the enumeration defined is not limited to values
>> of the enumerators specified. A enumeration is able to represent any
>> value from the range of values of its underlying type; see C++ 7.2 #6.
>
> Not exactly - the clause you cite talks about bitfields:
OK, good point. Let's make four more points then:
a) The wordings of the Standard about values of enumerations are
currently not self-consistent: the verse cited talks about bit fields
while 7.2 #5 requires all values of underlying type be preserved during
integral promotion; see issue #172 of Stroustrup;
> Thus, for the example in OP post the underlying type could well be some 32-
> bit int, whereas the valid values would be only those in range 0..7.
b) The underlying type of the enumeration can be a signed type so the
values of the bit field are, at least, in range -7...7;
c) The values that are out of the range are not valid nor invalid. They
are, being converted to the enumeration type, unspecified. That allows a
given implementation remain them unchanged during the conversion;
d) OP asks about things related to optimization so the current practice
does matter here. The current practice about enumeration values is that
the enumeration has a signed underlying type and the range of values of
the enumeration is at least is that of type int.
--
== 2 of 2 ==
Date: Sat, Mar 28 2009 6:10 am
From: "Peter Olcott"
"Ivan A. Kosarev" <ik@unicals.com> wrote in message
news:8qlzl.165151$de5.106668@newsfe10.ams2...
> Paavo Helde wrote:
>> "Ivan A. Kosarev" <ik@unicals.com> kirjutas:
>>> b) the set of values of the enumeration defined is not
>>> limited to values of the enumerators specified. A
>>> enumeration is able to represent any value from the
>>> range of values of its underlying type; see C++ 7.2 #6.
>>
>> Not exactly - the clause you cite talks about bitfields:
>
> OK, good point. Let's make four more points then:
>
> a) The wordings of the Standard about values of
> enumerations are currently not self-consistent: the verse
> cited talks about bit fields while 7.2 #5 requires all
> values of underlying type be preserved during integral
> promotion; see issue #172 of Stroustrup;
>
>> Thus, for the example in OP post the underlying type
>> could well be some 32-
>> bit int, whereas the valid values would be only those in
>> range 0..7.
>
> b) The underlying type of the enumeration can be a signed
> type so the values of the bit field are, at least, in
> range -7...7;
>
> c) The values that are out of the range are not valid nor
> invalid. They are, being converted to the enumeration
> type, unspecified. That allows a given implementation
> remain them unchanged during the conversion;
>
> d) OP asks about things related to optimization so the
> current practice does matter here. The current practice
> about enumeration values is that the enumeration has a
> signed underlying type and the range of values of the
> enumeration is at least is that of type int.
>
> --
The way that standard C++ could handle my issue without
having to resort to vendor specific extensions to the
language would be if all enumeration type values could only
be specified in terms of their enumeration names. Specifying
an enumeration value as any integer would be caught as a
syntax error.
The compiler would be free to map these names to a
contiguous set of integer values beginning with zero.
Whenever a switch statement would be specified using an
enumeration, the compiler would know that it would not have
to insert the extra code to test for out-of-range values,
because all out-of-range values would be reported as syntax
errors at compile time.
==============================================================================
TOPIC: Help understanding this function
http://groups.google.com/group/comp.lang.c++/t/69b739b156823692?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Mar 28 2009 2:47 am
From: Arne Mertz
Chris Saunders schrieb:
> I do not know the meaning of "*plonk*"
Try Wikipedia. Hint: it's not the wine.
==============================================================================
TOPIC: Question about reading from stream.
http://groups.google.com/group/comp.lang.c++/t/52af4ea746edf596?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Mar 28 2009 4:09 am
From: James Kanze
On Mar 27, 8:31 pm, c...@mailvault.com wrote:
> On Mar 27, 4:03 am, James Kanze <james.ka...@gmail.com> wrote:
> > On Mar 26, 8:44 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
> > [...]
> > It depends on the application. What if it's a compiler? Or a
> > Unix filter like grep or sed? For that matter, if clients share
> > no data directly, there are strong arguments for starting up a
> > new instance of a server for each connection;
> I think the arguments in favor of a long running server are
> stronger than those against it in the case of compilers.
> The design and implementation have to be such that separate
> requests do not interfere with each other. There are some
> steps that you can take that help in that area, but don't
> require anything like a new process and a completely fresh
> start. Besides the basic efficiencies afforded, there's
> a lot of basic information that doesn't change between
> requests. Why rescan/prepare for <vector> billions of
> times when it doesn't change one little bit? It surprises
> me that you question this given what I know of your
> background.
The contents of std::vector are data, not code, and don't
evolve. There's nothing wrong with having it cached somewhere,
maybe loaded by mmap, but just keeping a server up so that
compilations won't have to reread it seems a bit overkill.
(There's also the fact that formally, the effects of compiling
an include file depend on what macros are defined beforehand.
Even something like std::vector: the user doesn't have the right
to define any macros which might conflict, but most
implementations have two or more different versions, depending
on the settings of various macros.)
Anyway, my comments were, largely, based on the way things are,
rather than how they could be. I've not actually given the idea
of implementing a compiler as a server much thought, but today's
compilers are not implemented that way. I certainly don't want
to imply that things have to be like they are.
> > you don't want
> > start up time to be too long there, either.
> It has to done efficiently. Single-run compilers are a
> luxury that is fading. I harp on this, but gcc needs to
> be overhauled twice. First a rewrite in C++ and then a
> rewrite to be an on line compiler. The first phase of
> the on line part could be to simply run once and exit
> after each request. That though would have to be
> replaced by a real server approach that runs like a
> champ. They are so far away from this it isn't even
> funny.
So are most of the other compiler implementers, as far as I
know.
I'm not too sure what the server approach would by us in most
cases, as opposed, say, to decent pre-compiled headers and
caching. (If I were implementing a compiler today, it would
definitely make intensive use of caching; as you say, there's no
point in reparsing std::vector everytime you compile.)
> As far as I know all they are working on is
> C++0X support. Some of that is important, too, but
> they shouldn't keep ignoring these other matters.
> It may be that gcc has just become a dinosaur that
> can't adapt to the times. They certainly haven't
> done a good job keeping up in some respects. Where's
> the "gcc on line" page like some compilers have?
The "xxx on line" pages I know of for other compilers are just
front ends, which run the usual, batch mode compiler. It would
be trivial for someone to do this with g++---if Comeau wanted,
for example, I doubt that it would take Greg more than a half a
day to modify his page so you could use either his compiler or
g++ (for comparison purposes?).
I'm certainly in favor of making compilers accessible on-line,
but that's a different issue. No professional organization
would use such a compiler, except for test or comparison
purposes.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
==============================================================================
TOPIC: Do vector iterators remain valid after resize() if base pointer of
elements remains unchanged?
http://groups.google.com/group/comp.lang.c++/t/a2112c3799287ef5?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Mar 28 2009 4:19 am
From: James Kanze
On Mar 27, 9:56 pm, rep_movsd <rep.mo...@gmail.com> wrote:
> > Obviously, you aren't familiar with the Intel architecture.
> > > on 32 bit compilers sizeof(void*) == sizeof(int)
> > > I've never heard of 48 bit pointers.
> > And I've used them. On an Intel 80386.
> All Right, I heard of them now...
> > > The memory model for 32 bit protected mode from the
> > > application and compilers point of view is flat.
> > Only if the OS artificially chooses to restrict the users to
> > that.
> Well, considering that a 32 bit CPU can never address more than that
> anyway ( forget the 36 bit PAE shenanigans ),
Why? Modern Intel processors do have a 36 bit physical memory
bus. But that's not the point; different segments can be mapped
in different manners.
> I don't get how 48 bit addresses would be beneficial. Could
> you elaborate ( since you actually used them ) ?
In one case, there was no disk, so no virtual memory;
segmentation was the protection mechanism. In another, the "OS"
was MS-DOS, which at the time only ran in native, 16 bit mode;
with no support for virtual memory, again, segments were used to
go beyond the 1 MB supported by the OS.
> > > On 64 bit compilers this int/void* guarantee is broken...
> > > Loading an invalid address into a register will not trap!
> > It does on an Intel 80x86. I've actually seen it happen.
> Which instruction(s) specifically?
Any instruction which loads a segment register: LDS, LES, LFS,
LGS, and possibly some others. This goes back 25 or 30 years
ago, so I've forgotten the details. But the argument given in
the C committee for having just reading an invalide pointer be
undefined behavior was based on the Intel (and other machines at
the time which had "address" registers, but I've no experience
with those).
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
==============================================================================
TOPIC: Unignorable return value
http://groups.google.com/group/comp.lang.c++/t/3b14b8ccfba9854c?hl=en
==============================================================================
== 1 of 2 ==
Date: Sat, Mar 28 2009 4:53 am
From: gw7rib@aol.com
If I have a function returning int, then I am free to ignore that
return value. For instance:
int fun(void);
x = fun(); // valid
fun(); // valid
If I want the former form to be invalid, I can instead make the
function of type void:
void fun(void);
x = fun(); // invalid
fun(); // valid
But supose I have a function where I don't want the return value to be
ignored. Is there any way I can do this? For instance:
unignorable int fun(void);
x = fun(); // valid
fun(); // invalid
The reason I would like such a thing is this. I am writing a program
that has "notes", and there is an option to edit the properties of a
note. One thing that can be edited is that you can associate a file
with the note, so it shows the text of that file. If you associate a
file with a note for the first time, or change the file associated
with a note, then depending on the details the note may or may not
need repainting, as its text content has changed. But, in a new
modification, you can also have an image associated with a note, which
can optionally be shown instead of the text, and if you change the
image associated with a note, or change it from showing the image to
showing the text or vice versa, it again will need repainting. At
present the routine handling the change of file name will repaint the
note if necessary. But if the user makes both changes then this can
result in the note being repainted twice, the first time incorrectly
as it has not yet taken all the changes into account. So I am
considering moving the repaint up into the edit properties routine, so
that there will be one repaint afterwards if either or both of the
subroutines say it is necessary. Since the subroutines thus lose
direct control over whether the repaint happens, I would like to
ensure that their return value (indicating whether it is required) is
not ignored to make it harder for me to mess this up.
Any thoughts welcome!
Thanks.
Paul.
== 2 of 2 ==
Date: Sat, Mar 28 2009 7:10 am
From: Victor Bazarov
gw7rib@aol.com wrote:
> If I have a function returning int, then I am free to ignore that
> return value. For instance:
>
> int fun(void);
> x = fun(); // valid
> fun(); // valid
>
> If I want the former form to be invalid, I can instead make the
> function of type void:
>
> void fun(void);
> x = fun(); // invalid
> fun(); // valid
>
> But supose I have a function where I don't want the return value to be
> ignored. Is there any way I can do this? For instance:
>
> unignorable int fun(void);
> x = fun(); // valid
> fun(); // invalid
There is no way. Even if you force the caller of the function to get
the value, what makes you think the caller is going to do anything about
the value it gets?
int unignorable fun();
...
int dummy = fun();
// go on with our processing without paying attention to 'dummy'
> The reason I would like such a thing is this. I am writing a program
> that has "notes", and there is an option to edit the properties of a
> note. One thing that can be edited is that you can associate a file
> with the note, so it shows the text of that file. If you associate a
> file with a note for the first time, or change the file associated
> with a note, then depending on the details the note may or may not
> need repainting, as its text content has changed. But, in a new
> modification, you can also have an image associated with a note, which
> can optionally be shown instead of the text, and if you change the
> image associated with a note, or change it from showing the image to
> showing the text or vice versa, it again will need repainting. At
> present the routine handling the change of file name will repaint the
> note if necessary. But if the user makes both changes then this can
> result in the note being repainted twice, the first time incorrectly
> as it has not yet taken all the changes into account. So I am
> considering moving the repaint up into the edit properties routine, so
> that there will be one repaint afterwards if either or both of the
> subroutines say it is necessary. Since the subroutines thus lose
> direct control over whether the repaint happens, I would like to
> ensure that their return value (indicating whether it is required) is
> not ignored to make it harder for me to mess this up.
>
> Any thoughts welcome!
The paragraph above is too long for me to comprehend. But one thing I
get out of reading it (yes, I read it, just couldn't comprehend it):
you're going about it in a wrong way. You need to list the requirements
and then see what *you* can do about satisfying them, not the *user* of
your library.
It's like trying to force the user to deallocate the memory allocated in
the library. Give me the pointer, document the need to use 'delete' on
it, and some will still forget to do (or deliberately omit in some
cases) the deallocation. And even if you return 'std::auto_ptr', there
are still ways around the deallocation.
Don't force the user of your library into something. Provide a clear
mechanism, clear documentation, and a disclaimer, and hope they do The
Right Thing(tm).
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
==============================================================================
TOPIC: A question about a section in "Inside the C++ Object Model"
http://groups.google.com/group/comp.lang.c++/t/f0c8344a7742e492?hl=en
==============================================================================
== 1 of 2 ==
Date: Sat, Mar 28 2009 5:39 am
From: goodbyeera@gmail.com
My apology!
I am new to usenet, and I will try my best to be conforming to posting
guidelines in future.
Thank you for letting me know.
On Mar 28, 8:04 am, "Alf P. Steinbach" <al...@start.no> wrote:
> * goodbye...@gmail.com:
>
> > [Multi-posting]
>
> Don't.
>
> Please read the group's FAQ and some general info on multiposting etc.
>
> Cheers,
>
> - Alf
== 2 of 2 ==
Date: Sat, Mar 28 2009 7:18 am
From: "Fraser Ross"
Perhaps the example should involve a void* or a reinterpret_cast. There
are many other mistakes I've noticed in the code examples. The writing
isn't so bad.
Fraser.
==============================================================================
TOPIC: Hai ia am asha...
http://groups.google.com/group/comp.lang.c++/t/dcac4478fea117d0?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Mar 28 2009 6:02 am
From: asha1549@gmail.com
Hai i am asha...
Its my blog..
It is very useful....
So u see my blog....
==============================================================================
TOPIC: Hai i am asha...
http://groups.google.com/group/comp.lang.c++/t/ba63c7296445cfdd?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Mar 28 2009 6:05 am
From: asha1549@gmail.com
Hai i am asha...
its my blog...
it is very useful ....
so plz u see my blog....
==============================================================================
TOPIC: Hot sell jersey NFL NHL MLB NBA all star at China www.guoshitrade.com
wholesale freeshipping!!!
http://groups.google.com/group/comp.lang.c++/t/cab8867dad477410?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Mar 28 2009 6:18 am
From: jersey1234@126.com
FL Rugby Jersey 2009 SUPERBOWL,Pro bowl,Throwback Jersey
(www.guoshitrade.com)
NHL hockey Jersey 2009 100 year,100th All star, Winter Classic Jersey
(www.guoshitrade.com)
MLB Baseball Jersey 2009 new jersey(www.guoshitrade.com)
NBA Basketball jersey 2009 All star, Finals Jersey
(www.guoshitrade.com)
Discount Nike air jordans (www.guoshitrade.com)
Discount Nike Air Max 90 Sneakers (www.guoshitrade.com)
Discount Nike Air Max 91 Supplier (www.guoshitrade.com)
Discount Nike Air Max 95 Shoes Supplier (www.guoshitrade.com)
Discount Nike Air Max 97 Trainers (www.guoshitrade.com)
Discount Nike Air Max 2003 Wholesale (www.guoshitrade.com)
Discount Nike Air Max 2004 Shoes Wholesale
(www.guoshitrade.com)
Discount Nike Air Max 2005 Shop (www.guoshitrade.com)
Discount Nike Air Max 2006 Shoes Shop (www.guoshitrade.com)
Discount Nike Air Max 360 Catalogs (www.guoshitrade.com)
Discount Nike Air Max Ltd Shoes Catalogs (www.guoshitrade.com)
Discount Nike Air Max Tn Men's Shoes (www.guoshitrade.com)
Discount Nike Air Max Tn 2 Women's Shoes (www.guoshitrade.com)
Discount Nike Air Max Tn 3 Customize (www.guoshitrade.com)
Discount Nike Air Max Tn 4 Shoes Customize
( www.guoshitrade.com)
Discount Nike Air Max Tn 6 Supply (www.guoshitrade.com)
Discount Nike Shox NZ Shoes Supply (www.guoshitrade.com)
Discount Nike Shox OZ Sale (www.guoshitrade.com)
Discount Nike Shox TL Store (www.guoshitrade.com)
Discount Nike Shox TL 2 Shoes Store (www.guoshitrade.com)
Discount Nike Shox TL 3 Distributor (www.guoshitrade.com)
Discount Nike Shox Bmw Shoes Distributor (www.guoshitrade.com)
Discount Nike Shox Elite Shoes Manufacturer
(www.guoshitrade.com)
Discount Nike Shox Monster Manufacturer (www.guoshitrade.com)
Discount Nike Shox R4 Running Shoes (www.guoshitrade.com)
Discount Nike Shox R5 Mens Shoes (www.guoshitrade.com)
Discount Nike Shox Ride Womens Shoes (www.guoshitrade.com)
Discount Nike Shox Rival Shoes Wholesaler (www.guoshitrade.com)
Discount Nike Shox Energia Wholesaler (www.guoshitrade.com)
Discount Nike Shox LV Sneaker (www.guoshitrade.com)
Discount Nike Shox Turbo Suppliers (www.guoshitrade.com)
Discount Nike Shox Classic Shoes Suppliers
(www.guoshitrade.com)
Discount Nike Shox Dendara Trainer (www.guoshitrade.com)
Discount Nike Air Jordan 1 Seller (www.guoshitrade.com)
Discount Nike Air Jordan 2 Shoes Seller (www.guoshitrade.com)
Discount Nike Air Jordan 3 Collection (www.guoshitrade.com)
Discount Nike Air Jordan 4 Shoes Collection
(www.guoshitrade.com)
Discount Nike Air Jordan 5 Chaussure Shoes
(www.guoshitrade.com)
More detail land, address:www.guoshitrade.com www.guoshiaaa.com
www.guoshijerseys.com
==============================================================================
You received this message because you are subscribed to the Google Groups "comp.lang.c++"
group.
To post to this group, visit http://groups.google.com/group/comp.lang.c++?hl=en
To unsubscribe from this group, send email to comp.lang.c+++unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c++/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
No comments:
Post a Comment