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-l
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
pla
--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
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 inhe
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 o
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 cast
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.
>
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 someti
* 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 stor
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
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
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 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.
>
>
> "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
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 handli
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 grep
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=get&search=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;
// chan
20 matches
Mail list logo
