On Wed, Aug 06, 2003 at 10:36:42AM -0400, MJM wrote:
On Wednesday 06 August 2003 01:02, Dave Carrigan wrote:
Language experts sure get their shorts knotted up over simple questions.
Because your question had to do with undefined and
implementation-dependent behavior.
I know that.
On Wednesday 06 August 2003 09:30, Sebastian Kapfer wrote:
They do. My app would be broken from the start if I could not rely on
this capability. This style of type conversion is covered in elementary
C++ books by Bjarne. It's not unusual.
Exactly where? I don't remember such casts from
On Tuesday 05 August 2003 14:02, Pigeon wrote:
On Tue, Aug 05, 2003 at 03:40:42AM +0200, Sebastian Kapfer wrote:
On Mon, 04 Aug 2003 05:00:12 +0200, MJM wrote:
// change the way it is accessed to prove a point int * p_b = (int *)
p_a;
// p_a and p_b point to the same block of dyn.
On Tue, Aug 05, 2003 at 03:40:42AM +0200, Sebastian Kapfer wrote:
On Mon, 04 Aug 2003 05:00:12 +0200, MJM wrote:
// change the way it is accessed to prove a point int * p_b = (int *)
p_a;
// p_a and p_b point to the same block of dyn. allocated memory;
Do they? Watch out for inheritance,
--jq0ap7NbKX2Kqbes
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Aug 06, 2003 at 10:36:42AM -0400, MJM wrote:
On Wednesday 06 August 2003 01:02, Dave Carrigan wrote:
?Language experts sure get their shorts knotted up
On Wed, 06 Aug 2003 19:00:11 +0200, MJM wrote:
I learned last night that there is a 3rd Ed. Evidently things have
changed and the complex language has gotten more complex -
Right.
trying to be all things to all people. If this continues, C++ will be
too complex for normal programmers.
On Mon, 04 Aug 2003 05:00:12 +0200, MJM wrote:
Will the free store be properly maintained when the following is
executed? // a simple object is defined typedef struct {
uint32_t a;
uint64_t b;
uint8_tc;
} t_my_type;
No typedef needed. This is C++.
struct t_my_type
{
Al == Al Davis [EMAIL PROTECTED] writes:
Al Since you didn't say what uint64_t is, let me make a diabolical
Al definition of it.
uint64_t is a type defined in C99, which is always a 64-bit unsigned
integer. Whether it is already in your C++ compiler depends pretty much on
platform, but
On Wed, 06 Aug 2003 06:00:11 +0200, MJM wrote:
On Monday 04 August 2003 21:40, Sebastian Kapfer wrote:
// change the way it is accessed to prove a point int * p_b = (int
*) p_a;
Ouch.
Try this in /usr/src/linux/kernel
$ grep *\) *.c
This is unfair. First, it's kernel-land code, and
On Tue, 05 Aug 2003 22:00:13 +0200, Pigeon wrote:
No. You have to delete the original pointer (with the original type).
Everything else is undefined behaviour, i.e. it could work, it could
leak memory (completely or partly), it could crash, or even print 42.
It might even work sometimes, and
* Pigeon ([EMAIL PROTECTED]) [030805 12:52]:
On Tue, Aug 05, 2003 at 03:40:42AM +0200, Sebastian Kapfer wrote:
On Mon, 04 Aug 2003 05:00:12 +0200, MJM wrote:
I think the free store will be maintained properly because there is a
control block attached to the allocated block of storage that
On Wednesday 06 August 2003 15:20, Sebastian Kapfer wrote:
You obviously don't understand the point of the new cast operators. They
don't take power away from you, in fact they give you more power than
before
I didn't _know_ about the new cast operators and yet things
are working very well
On Monday 04 August 2003 21:40, Sebastian Kapfer wrote:
// change the way it is accessed to prove a point int * p_b = (int *)
p_a;
Ouch.
Try this in /usr/src/linux/kernel
$ grep *\) *.c
// p_a and p_b point to the same block of dyn. allocated memory;
Do they?
They do. My app would be
On Tue, Aug 05, 2003 at 11:21:04PM -0400, MJM wrote:
On Monday 04 August 2003 21:40, Sebastian Kapfer wrote:
// change the way it is accessed to prove a point int * p_b = (int *)
p_a;
Ouch.
Try this in /usr/src/linux/kernel
$ grep *\) *.c
Well, C is not C++, so grepping C source
On Wednesday 06 August 2003 01:02, Dave Carrigan wrote:
Language experts sure get their shorts knotted up over simple questions.
Because your question had to do with undefined and
implementation-dependent behavior.
I know that. See my other posts. I asked a question about handling
MJM == MJM [EMAIL PROTECTED] writes:
MJM They do. My app would be broken from the start if I could not rely
MJM on this capability. This style of type conversion is covered in
MJM elementary C++ books by Bjarne. It's not unusual. You must be
MJM aware of what you are doing
On Wed, Aug 06, 2003 at 03:30:57PM +0200, Sebastian Kapfer wrote:
On Wed, 06 Aug 2003 06:00:11 +0200, MJM wrote:
That was way over the top. That stuff is for compiler writers, not
application programmers. I did not start a knowledge contest. If I did
inadvertently, then you win.
I don't
I think all of the responses are missing something very
important. Let me try
On Sunday 03 August 2003 08:57 pm, MJM wrote:
Will the free store be properly maintained when the following
is executed? // a simple object is defined
typedef struct
{
uint32_t a;
uint64_t b;
On Sun, Aug 03, 2003 at 10:57:21PM -0400, MJM wrote:
Will the free store be properly maintained when the following is executed?
Yes.
--
Pigeon
Be kind to pigeons
Get my GPG key here: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x21C61F7F
pgp0.pgp
Description: PGP signature
Will the free store be properly maintained when the following is executed?
// a simple object is defined
typedef struct
{
uint32_t a;
uint64_t b;
uint8_t c;
} t_my_type;
// allocate some memory for an instance of this object
t_my_type * p_a = (t_my_type) new t_my_type;
//
20 matches
Mail list logo
