C, C++, VC++ Etc.
definition for invariant and class invariant
In the website [link] I found the
following definition for 'invariant'
Invariant(ComputerScience), an expression whose value doesn't change
during program execution.
For example, consider the following program:
using namespace std;
class Test
{
public:
explicit Test(int arg = 0);
following definition for 'invariant'
Invariant(ComputerScience), an expression whose value doesn't change
during program execution.
For example, consider the following program:
using namespace std;
class Test
{
public:
explicit Test(int arg = 0);
Re: void* argument to get the result of a function
* Pete Becker, on 30.07.2010 01:22:
Right, I didn't see that.
But there is already a known defect that sentence, namely direct contradiction
between its "Except that ..., the result ... is unspecified", and §9.2/17, "A
pointer to a POD-struct object, suitably converted using reinterpret_cast,
points to its initial member (or if that member is a bit-field, then to the unit
Right, I didn't see that.
But there is already a known defect that sentence, namely direct contradiction
between its "Except that ..., the result ... is unspecified", and §9.2/17, "A
pointer to a POD-struct object, suitably converted using reinterpret_cast,
points to its initial member (or if that member is a bit-field, then to the unit
Re: how to design a replacement for C++
No argument from me on that :-)
Myself, I have painful memories of getting combinations of jar files
from various projects to work. When Sun moved to SAX2, they didn't
freeze and deprecate the old SAX1 interfaces, rather, they just added
new methods to existing interfaces (Sun did that a lot.) In any
Myself, I have painful memories of getting combinations of jar files
from various projects to work. When Sun moved to SAX2, they didn't
freeze and deprecate the old SAX1 interfaces, rather, they just added
new methods to existing interfaces (Sun did that a lot.) In any
Re: void* argument to get the result of a function
5.2.10/7 (second sentence):
Except that converting an rvalue of type “pointer to T1” to the type
“pointer to T2”
(where T1 and T2 are object types and where the alignment requirements of T2
are no stricter than those of T1) and back to its original type yields
the original
pointer value, the result of such a pointer conversion is unspecified.
Except that converting an rvalue of type “pointer to T1” to the type
“pointer to T2”
(where T1 and T2 are object types and where the alignment requirements of T2
are no stricter than those of T1) and back to its original type yields
the original
pointer value, the result of such a pointer conversion is unspecified.
Re: void* argument to get the result of a function
* Pete Becker, on 29.07.2010 21:35:
A reinterpret_cast roundtrip conversion through void* is not unspecified, but is
guaranteed to yield the original pointer, by §5.2.10/7 (and §3.9.2/4).
Cheers & hth.,
- Alf
A reinterpret_cast roundtrip conversion through void* is not unspecified, but is
guaranteed to yield the original pointer, by §5.2.10/7 (and §3.9.2/4).
Cheers & hth.,
- Alf
Re: C vs. C++: non-trivial designated initializers not supported
Sorry, I overlooked that part.
Re: C vs. C++: non-trivial designated initializers not supported
"Francesco S. Carta" <entul...@gmail.com>
As Johannes stated in the part you cut out, that stuff goes to a const
segment sitting in ROM, so assignment does not play, only static init.
The part I don't get is why providing initializer for all struct members
(either literally, or better yet using a macro) is so painful. Such tables
As Johannes stated in the part you cut out, that stuff goes to a const
segment sitting in ROM, so assignment does not play, only static init.
The part I don't get is why providing initializer for all struct members
(either literally, or better yet using a macro) is so painful. Such tables
Re: C vs. C++: non-trivial designated initializers not supported
What is so ugly with the "no initialized + assignment" approach
suggested by Andrey?
This chunk of code isn't all that hard to type or to review, is valid
everywhere (within the context at hand) and, IIUIC, should also be
faster than the C99 version mentioned in the OP:
//-------
PODObject obj;
suggested by Andrey?
This chunk of code isn't all that hard to type or to review, is valid
everywhere (within the context at hand) and, IIUIC, should also be
faster than the C99 version mentioned in the OP:
//-------
PODObject obj;
Re: how to design a replacement for C++
Roughly:
Every module or library has (should have) a unique namespace. Add two
operations:
1) You can mark stuff as exported from namespace. That stuff is
interface of module.
2) When someone imports that modules namespace then he gets stuff
declared that the namespace did export without preprocessor involved.
Every module or library has (should have) a unique namespace. Add two
operations:
1) You can mark stuff as exported from namespace. That stuff is
interface of module.
2) When someone imports that modules namespace then he gets stuff
declared that the namespace did export without preprocessor involved.
Re: C vs. C++: non-trivial designated initializers not supported
The only other thing I can think of is to simply do this stuff in C
source and build that part of the tree with the C compiler :/
--Jonathan
source and build that part of the tree with the C compiler :/
--Jonathan
Re: Template classes with static members
If they were trivial functions I would inline them and throw
them in the header. But when they're not... it just seems
contrary to practice to do that. I guess it's a case of having
your cake and eating it, too.
It sounds like it. But a common base class with protected
members basically satisfies both. I guess that's about the
them in the header. But when they're not... it just seems
contrary to practice to do that. I guess it's a case of having
your cake and eating it, too.
It sounds like it. But a common base class with protected
members basically satisfies both. I guess that's about the
Re: C vs. C++: non-trivial designated initializers not supported
Am 29.07.2010 19:45, schrieb Andrey Tarasevich:
When I leave out the member "PointerValue" from the struct, it works
(since all are initialized then).
Well, it's not possible to change the order in my case (since the layout
of the struct is determined by hardware, not by me).
If I define PointerValue, like say to 0...
When I leave out the member "PointerValue" from the struct, it works
(since all are initialized then).
Well, it's not possible to change the order in my case (since the layout
of the struct is determined by hardware, not by me).
If I define PointerValue, like say to 0...
Re: C vs. C++: non-trivial designated initializers not supported
Am 29.07.2010 20:56, schrieb Richard:
Yes, I used the deprecated variant. Is there anything like this in C++?
Kind regards,
Johannes
Yes, I used the deprecated variant. Is there anything like this in C++?
Kind regards,
Johannes
Re: C vs. C++: non-trivial designated initializers not supported
Am 29.07.2010 19:38, schrieb Jonathan Lee:
That seems to suck, is there really no other way? I cannot change the
initializers at runtime as the struct needs to be laid out in advance
and is placed in ROM (actually Flash, but ROM for that purpose).
Maybe I'll just use C-code for that part (with the correct ".foo = bar"
That seems to suck, is there really no other way? I cannot change the
initializers at runtime as the struct needs to be laid out in advance
and is placed in ROM (actually Flash, but ROM for that purpose).
Maybe I'll just use C-code for that part (with the correct ".foo = bar"
Re: C vs. C++: non-trivial designated initializers not supported
Am 29.07.2010 19:53, schrieb Andrey Tarasevich:
This is not possible. The code is part of a IVT and therefore needs to
be laid out by the compiler to contain the function addresses of the ISRs.
No, see above.
Well, that's no real nice solution. The struct has around 150 actual ISR
handlers and I want to set some specific ones without having to know
This is not possible. The code is part of a IVT and therefore needs to
be laid out by the compiler to contain the function addresses of the ISRs.
No, see above.
Well, that's no real nice solution. The struct has around 150 actual ISR
handlers and I want to set some specific ones without having to know
Re: Template classes with static members
Looks like a candidate for a base class (or class template).
> So I've been pulling the code out into a
Not sure why you designate them "dummy", but OK.
> But *then* I figure this
Uh... You *figure* "this stuff doesn't belong in a header" - how do you
figure that? If you like everything in one header, then keep it there, no?
> So I've been pulling the code out into a
Not sure why you designate them "dummy", but OK.
> But *then* I figure this
Uh... You *figure* "this stuff doesn't belong in a header" - how do you
figure that? If you like everything in one header, then keep it there, no?
Re: how to design a replacement for C++
One reason is the output of a C++ build is the fully cooked application
where the output form Java compilation is like those part baked breads
supermarkets sell. The consumer has to take them home and finish the job!
True, but they also act as documentation of the interface. I often end
up creating an interface for a PHP class just so I can see all the
where the output form Java compilation is like those part baked breads
supermarkets sell. The consumer has to take them home and finish the job!
True, but they also act as documentation of the interface. I often end
up creating an interface for a PHP class just so I can see all the
Re: how to design a replacement for C++
At this point, those of us who have had to configure and maintain Tomcat
run screaming from the room!
I used to write all of the sever side code in my web applications in
PHP, but now all of the required library components, I've gone back to
using C++.
run screaming from the room!
I used to write all of the sever side code in my web applications in
PHP, but now all of the required library components, I've gone back to
using C++.
Re: Separate Template Definition I wrote class Data in header. The C++ Compiler compiled without errors. I decided to move all member functions into source code because they are for implementation. I do not like that they are placed in class body.
You can add many member functions in source code you like.
Don't add that line below.
I successfully resolved linkage failure. I fixed template class
specification in source code. Cast operator function is working
perfectly.
Add line below.
template
class Data< unsigned char >;
...Before...add many member functions.
Don't add that line below.
I successfully resolved linkage failure. I fixed template class
specification in source code. Cast operator function is working
perfectly.
Add line below.
template
class Data< unsigned char >;
...Before...add many member functions.
Re: void* argument to get the result of a function
Okay, so I muddled things with my automatic reaction that when someone
talks about guarantees they're contrasting with a C-style cast. You're
absolutely right, of course: the result of a round-trip conversion
through a reinterpert_cast<void*> is unspecified.
talks about guarantees they're contrasting with a C-style cast. You're
absolutely right, of course: the result of a round-trip conversion
through a reinterpert_cast<void*> is unspecified.
