Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > C/C++ question about dynamic "static struct"

Reply
Thread Tools

C/C++ question about dynamic "static struct"

 
 
Jorgen Grahn
Guest
Posts: n/a
 
      10-22-2012
On Mon, 2012-10-22, Rui Maciel wrote:
> Tobias Müller wrote:
>
>> Ian Collins <(E-Mail Removed)> wrote:
>>> If you work in a team on a new project, the team agrees which features to
>>> use.

>>
>> But as a C++ programmer I would never agree on using only the C subset of
>> C++.

>
> The point I made with the reference to C++'s C subset was that:
> - If C is considered good for memory management, then C++, as it includes a
> subset of C, is also good for memory management when limited to that subset.
> - If we add the remaining C++ features to C++'s C subset, the C++
> programming language doesn't become worse for memory management. It
> actually improves significantly, considering the addition of RAII.
>
> Therefore, C++ is patently not worse than C with regards to memory
> management.
>
>> The complexity of C++ makes it more difficult to agree on a common subset
>> of features, because the level of knowledge may vary more.

>
> It isn't that complex as you make it out to be. I know of a company in the
> telecom industry which explicitly banned the use of exceptions and the STL
> in one of their C++ projects, the later in favour of a set of custom memory
> pools. That policy was in the project's coding guidelines, and everyone who
> was added to the project was briefed about what was kosher and what was
> taboo. There was nothing difficult about that.


Well ... I think I might prefer using C to working in C++ without the
standard library. Unless its replacement was *really* good and
included drop-in replacements for things like iterators and algorithms.
And containers.

Weird guidelines aside, I have to partly agree with T.M. above -- it
/is/ harder to agree about C++. One guy wants it to be C, another
wants it to be Smalltalk, a third wants it to be 1980s C++, I want it
to be modern C++ ...

It's worth the effort, though.

>>> If you work on existing code, you get a free education...

>>
>> And it raises the possibility to make things even worse because you're not
>> understanding what you're reading.


What's so bad about not understanding everything? You go to the guy
who wrote it and ask him to explain. If he can't, you might want to
rewrite it. Not any different from not immediately understanding other
things in the project, like an interface, an algorithm, or a
requirement.

> You won't be reading idioms which were explicitly banned from a project.


And you won't be reading many things which were not. I've never seen
multiple inheritance -- not because it has been banned, but because
it's so rarely useful! I've never seen deep template meta-
programming, because I don't work with people who are into that stuff.
And so on.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
 
 
 
Öö Tiib
Guest
Posts: n/a
 
      10-22-2012
On Monday, 22 October 2012 23:52:35 UTC+3, Jorgen Grahn wrote:
> On Mon, 2012-10-22, Rui Maciel wrote:
> > Tobias M�ller wrote:
> >> The complexity of C++ makes it more difficult to agree on a common subset
> >> of features, because the level of knowledge may vary more.

> >
> > It isn't that complex as you make it out to be. I know of a company inthe
> > telecom industry which explicitly banned the use of exceptions and the STL
> > in one of their C++ projects, the later in favour of a set of custom memory
> > pools. That policy was in the project's coding guidelines, and everyone who
> > was added to the project was briefed about what was kosher and what was
> > taboo. There was nothing difficult about that.

>
> Well ... I think I might prefer using C to working in C++ without the
> standard library. Unless its replacement was *really* good and
> included drop-in replacements for things like iterators and algorithms.
> And containers.


You should try QT then. That framework really has choosen to have everything
of its own. Only thing that I do not see as very reasonable is that QString
is internally UTF-16 not UTF-8. Perhaps it is because Symbian and Windows (favorite OSs of Nokia) also favor UTF-16. Rest of it is quite well made and
also the development tools are quite nice.

> Weird guidelines aside, I have to partly agree with T.M. above -- it
> /is/ harder to agree about C++. One guy wants it to be C, another
> wants it to be Smalltalk, a third wants it to be 1980s C++, I want it
> to be modern C++ ...
>
> It's worth the effort, though.


That is anyway difficult but must be done when specialists of so very
different background have to coooperate. Usually there should be one
lead developer - architect type per team and others should be supporting
and assisting members. Several disagreeing leaders has disasterous result
independent of goal and tools.

> > You won't be reading idioms which were explicitly banned from a project..

>
> And you won't be reading many things which were not. I've never seen
> multiple inheritance -- not because it has been banned, but because
> it's so rarely useful! I've never seen deep template meta-
> programming, because I don't work with people who are into that stuff.
> And so on.


Every week I find something that i have never seen before. Past week example:

class Power
{
private:
// construct with factory methods
Power( std::string const& typeCode );
public:
// factory method
static Power fromValueAndUnitText( std::string const& text )
{
if ( text.size() < 2 )
{
// both value and unit can't fit
return false; //<--- i was here like WTF WTF WTF
}
// ...
// etc.
}
// ...
// etc.
};

Compiled without any warnings. I did not even know before that 'false'
converts so silently to 'std::string const&' on the compiler used in
that project.
 
Reply With Quote
 
 
 
 
Stuart
Guest
Posts: n/a
 
      10-23-2012
On 10/23/12 Öö Tiib wrote:
[snip]
> Every week I find something that i have never seen before. Past week example:
>
> class Power
> {
> private:
> // construct with factory methods
> Power( std::string const& typeCode );
> public:
> // factory method
> static Power fromValueAndUnitText( std::string const& text )
> {
> if ( text.size() < 2 )
> {
> // both value and unit can't fit
> return false; //<--- i was here like WTF WTF WTF
> }
> // ...
> // etc.
> }
> // ...
> // etc.
> };
>
> Compiled without any warnings. I did not even know before that 'false'
> converts so silently to 'std::string const&' on the compiler used in
> that project.


That's what I hate about C++, too. My favourite programming language,
Ada, would never allow such a thing to happen. It's a pity that implicit
conversions cannot be turned off using a pragma/compiler switch.

Regards,
Stuart

 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      10-23-2012
On Sun, 2012-10-21, Greg Martin wrote:
> On 12-10-21 12:33 PM, Jorgen Grahn wrote:
>> On Thu, 2012-10-18, William Ahern wrote:
>>> In comp.lang.c Stuart <(E-Mail Removed)> wrote:
>>>> On 10/18/12 James Kuyper wrote:
>>>> [snip]
>>>>> I'm primarily a C programmer, so I may be
>>>>> missing out some elegant C++ way of doing that, but the following
>>>>> inelegant (and untested) code should do the job:
>>>> [snip]
>>>
>>>> I'm intrigued. I have never ever met someone who described himself as a C
>>>> programmer. May I ask what kind of business you are in? My guess is your
>>>> line of work includes either device drivers, embedded devices, kernel code
>>>> or something else that forces you to write C instead of C++. In all these
>>>> years I have never met someone who used C instead of C++ unless he was
>>>> forced to do so.
>>>
>>> Well, you have now. I've worked in several shops (both small and billion
>>> dollar companies) which were C only by choice. The consensus was that the
>>> cost/benefit of C++ didn't pan out, particularly for backend, non-GUI work.

>>
>> I've worked in those places too. Unlike you I believe they are
>> misguided, but I agree they exist and aren't unusual.
>>

>
> What seems to be the real irony here is that it isn't 1992, though I'm
> getting a decided deja vu, but 2012 when this conversation should be
> taking place between C++ zealots and C# adherents (or maybe Java,
> Python, Ruby, erlang programmers et al).


I don't quite get your point here. It's obviously not "C should have
died some time after 1992".

(For what it's worth, if I had a time machine I'd go back to 1992 and
tell people to stay off C++ for a few more years until the standard
library was in place, and templates widely understood. I have a
feeling many bad practices and much bad reputation came in that time
frame.)

> I have worked on large scale projects in both C++ and C and prefer C
> however misguided you may feel that makes me.

....
> I'm quite fond of erlang for instance though
> I don't believe you should learn it as I'm sure you can accomplish what
> you need to do in C++


I just stated that I prefer C++ to C, not that C++ is better than all
other languages at everything!

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      10-23-2012
On Tue, 2012-10-23, Stuart wrote:
> On 10/23/12 Öö Tiib wrote:
> [snip]
>> Every week I find something that i have never seen before. Past
>> week example:
>>
>> class Power
>> {
>> private:
>> // construct with factory methods
>> Power( std::string const& typeCode );
>> public:
>> // factory method
>> static Power fromValueAndUnitText( std::string const& text )
>> {
>> if ( text.size() < 2 )
>> {
>> // both value and unit can't fit
>> return false; //<--- i was here like WTF WTF WTF
>> }
>> // ...
>> // etc.
>> }
>> // ...
>> // etc.
>> };
>>
>> Compiled without any warnings. I did not even know before that 'false'
>> converts so silently to 'std::string const&' on the compiler used in
>> that project.


Ugh. And I can't even get gcc to warn about it, when I apply all my
favorite warning options. I didn't expect that!

> That's what I hate about C++, too. My favourite programming language,
> Ada, would never allow such a thing to happen. It's a pity that implicit
> conversions cannot be turned off using a pragma/compiler switch.


It's not something you come across very often. Or at least I don't ...
In this case the first error is not to make Power:ower(const string&)
'explicit' -- so the "conversion" is a two step one.

I wouldn't mind a flag to warn about non-'explicit' constructors, and
like others have pointed out in the past, it would have been better if
the keyword had been 'implicit' instead and done the reverse job.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Dombo
Guest
Posts: n/a
 
      10-23-2012
Op 23-Oct-12 17:44, Jorgen Grahn schreef:
> On Sun, 2012-10-21, Greg Martin wrote:


>> What seems to be the real irony here is that it isn't 1992, though I'm
>> getting a decided deja vu, but 2012 when this conversation should be
>> taking place between C++ zealots and C# adherents (or maybe Java,
>> Python, Ruby, erlang programmers et al).

>
> I don't quite get your point here. It's obviously not "C should have
> died some time after 1992".
>
> (For what it's worth, if I had a time machine I'd go back to 1992 and
> tell people to stay off C++ for a few more years until the standard
> library was in place, and templates widely understood. I have a
> feeling many bad practices and much bad reputation came in that time
> frame.)


It would probably also have prevented many C++ libraries from
implementing their own string and container classes. This is one thing I
dislike about C++.

 
Reply With Quote
 
google@ianshome.com
Guest
Posts: n/a
 
      10-23-2012
On Monday, 22 October 2012 10:25:11 UTC+13, Les Cargill wrote:
> Ian Collins wrote:
>> On 10/22/12 07:31, Les Cargill wrote:
>>> Ian Collins wrote:
>>>> On 10/21/12 20:11, Les Cargill wrote:
>>>>> Ian Collins wrote:

>
> >>>>> C simply can't do RAII,
> >>>>
> >>>> Not in the specific manner Stoustrup used it, but it's
> >>>> perfectly easy to achieve the same goal.
> >>>
> >>> I'm sorry, but it isn't. RAII is one C++ feature that C can't do.
> >>>
> >>
> >> I respectfully submit that you haven't thought
> >> that though. I won't bore you with the sea stories...
> >> but it's been done...

> >
> > I certainly have thought it through. Please provide an example of RAII
> > in C.

>
> So we're talking RAII as modulo exceptions - unless longjmp() is alos an
> exception...
>
> So you *haven't* thought about it, then? It's not exactly rocket
> surgery. I am just enumerating my assumptions in responding to your
> post, not *accusing* you of anything.
>
> Essentially replace malloc()/free() with something that tracks
> allocation and provides instrumentation about the state of the heap.
> This is much simpler than it sounds...


So provide an example in standard C. It looks like all your **** and wind
is an attempt to cover up the fact that you can't.

RAII can be used in the context of any resource (hence its name!), not just
memory.

> Given all the rash about it, I am surprised 'C' doesn't offer this
> natively, and that there were never commercial products of the same
> stripe.


Which was my original point, thank you.

--
Ian.
 
Reply With Quote
 
Stuart
Guest
Posts: n/a
 
      10-24-2012
On 23-Oct-12 Jorgen Grahn wrote:
[snip]
>> (For what it's worth, if I had a time machine I'd go back to 1992 and
>> tell people to stay off C++ for a few more years until the standard
>> library was in place, and templates widely understood. I have a
>> feeling many bad practices and much bad reputation came in that time
>> frame.)


On 10/23/12 Dombo wrote:
> It would probably also have prevented many C++ libraries from
> implementing their own string and container classes. This is one thing I
> dislike about C++.


+1.

I took an immediate dislike to qt because it seemed as if they had to
reinvent the wheel not only once but many times. Later I realized that
they wanted to have a copy-on-write semantics for their strings, which
could not be achieved with std::string at that time.

Now that std::string supports copy-on-write, too, noone on the qt team
seems inclined to remove the superfluous qtString class.

Even Microsoft still uses CObject as base class for all classes of their
MFC library, even though the whole purpose of this class was to provide
run-time type information.

I guess that is just the way large projects are.

Regards,
Stuart


 
Reply With Quote
 
Dombo
Guest
Posts: n/a
 
      10-24-2012
Op 24-Oct-12 12:01, Stuart schreef:
> On 23-Oct-12 Jorgen Grahn wrote:
> [snip]
>>> (For what it's worth, if I had a time machine I'd go back to 1992 and
>>> tell people to stay off C++ for a few more years until the standard
>>> library was in place, and templates widely understood. I have a
>>> feeling many bad practices and much bad reputation came in that time
>>> frame.)

>
> On 10/23/12 Dombo wrote:
>> It would probably also have prevented many C++ libraries from
>> implementing their own string and container classes. This is one thing I
>> dislike about C++.

>
> +1.
>
> I took an immediate dislike to qt because it seemed as if they had to
> reinvent the wheel not only once but many times. Later I realized that
> they wanted to have a copy-on-write semantics for their strings, which
> could not be achieved with std::string at that time.
>
> Now that std::string supports copy-on-write, too, noone on the qt team
> seems inclined to remove the superfluous qtString class.
>
> Even Microsoft still uses CObject as base class for all classes of their
> MFC library, even though the whole purpose of this class was to provide
> run-time type information.


Though there were valid reasons at the time for libraries to provide
their own string and container classes, it is a shame many
C++programmers still have to deal with this unfortunate legacy.

The main thing I hate is that when you use multiple libraries each with
their own string and container classes (and naming conventions,
idioms...etc), you have to write code to convert between various
classes. This is a waste of both programmer- and execution time.

 
Reply With Quote
 
gwowen
Guest
Posts: n/a
 
      10-26-2012
On Oct 22, 12:43*pm, ptyxs <(E-Mail Removed)> wrote:
> Le 21/10/2012 19:54, Les Cargill a écrit :
> To badly> paraphrase Voltaire, "hell is other people's code*." The more of
> > it there is, the more bugs there are.

>
> You probably meant 'to paraphrase Jean-Paul Sartre'...
> Voltaire has nothing to do with that sentence...
> Ptyxs


Les was too busy correcting University Dons about category mistakes...
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Array question - How dynamic is dynamic? Ruby Student Ruby 4 04-09-2009 12:59 PM
Dynamic control on aspx page, dynamic location Chris Thunell ASP .Net 3 07-21-2004 04:52 PM
VPN between 2 Cisco routers (1 static, 1 dynamic) with access from stat --> dynamic over ISDN Hans-Peter Walter Cisco 3 01-21-2004 02:12 PM
Does Pix or cisco router support dynamic-to-dynamic IPSec VPN? c Cisco 2 01-13-2004 01:53 AM
Re: Dynamic Table with Dynamic LinkButtons Rick Glos ASP .Net 0 07-08-2003 01:09 PM



Advertisments