If you could change the C or C++ or Java syntax, what would you like different?

[Juha Nieminen]

The first thing I would do is to get rid of "->". Srsly, if the dot operator
is applied on a pointer value p, it will be equivalent to "(*p).mem".

Wouldn't this cause a problem when trying to overload the operator
(eg. in smart pointers)?

 

[Stefan van Kessel]

One would need to be able to overload operator. for smart pointers.
However, then it might become cumbersome to write smart pointer
implementation itself. One should then add a .. operator or whatever, as a
"real dot operator". Coming to think about that, what's missing in the
current C++ is a non-overloadable -> operator, so that would be something I
would add to current C++ syntax.

Cheers
Paavo

Operator -> already is non-overloadable as a non member function. You
can apply the member version iff (if and only if) the operand is not a
pointer and the non-member version iff the operand is pointer. As long
as both a non-overloadable operator. and overloadable member operator->
are available I don't see what needs to be added. I for one am quite
happy with the operators . and -> the way they are now.

 

[Keith Thompson]

The compiler doesn't matter here. Most windows api functions accept '/'
nowadays (but not all). You're better off using '\' for the windows
platform, because there are still cases '/' won't work.

But then, it was Microsoft's awkward decision to use '\' as a path
separator with the rest of the world using '/'. It probably came back on
them the instant they built web functionality (browser, server) in their
OS.

My understanding is that early versions of MS-DOS didn't support
directories (or maybe it was CP/M). By the time they decided to
add directories, they were already using '/' as an option delimiter
(like '-' in Unix).

The Unix convention probably wasn't as widespread then as it is
now, so using '\' wasn't an obviously absurd choice at the time.
(VMS, for example, uses '.' to separate directory names.)

 

[Keith Thompson]

And how is typedef NOT declaring a new type? (in fact, it should say
"defining"!) Defining new types is always done by means of existing
types, in any language that allows type definitions.

Given, for example:

struct foo {
int data;
};

typedef struct foo foo_t;

the typedef really doesn't create a new type. All it does is create a
new name for an existing type. "struct foo" and "foo_t" are not merely
two different types with the same characteristics; they are quite
literally the same type.

By contrast, given:

struct foo {
int data;
};

struct bar {
int data;
};

"struct foo" and "struct bar" are two distinct types. Assigning a
value of type "pointer to struct foo" to an object of type "pointer
to struct bar" is a constraint violation, requiring a diagnostic.

Replace "pointer to struct bar" with "pointer to foo_t" in the above,
and there's no problem.

 

[Keith Thompson]

Perhaps, at least I didn't expect the placement of a little verb to have
a strong influence on understanding what I wrote. Was it wrongly placed
or just uncommon?

I don't think it's wrong, but it is unusual. Noticing that you post
from a ".de" domain helped me figure it out.

No criticism intended; your English is certainly far better than my
German.

 

[Martin Gregorie]

My understanding is that early versions of MS-DOS didn't support
directories (or maybe it was CP/M). By the time they decided to add
directories, they were already using '/' as an option delimiter (like
'-' in Unix).

Correct. MS-DOS 2.x introduced directories. Before that, MS-DOS, like the
other 8 bit OSen (FLEX, FLEX-09, CP/M, etc.), just had a flat list of
file names which was OK because few of its users could afford disks big
enough for the lack of directories to be a problem.

It looks as though MS-DOS inherited the A: drive letter convention from
CP/M, which in turn may have gotten it from the PDP-8 OSen such as RTOS:
the CP/M command language pretty much copied its syntax, command names
and file naming conventions.

 

[Jon]

What leads you to believe that I, or anyone for that matter, never
tried it?

In your case (not anyone else), because you don't know that it's not
practical.

 

[Felix Palmen]

And how is typedef NOT declaring a new type? (in fact, it should say
"defining"!) Defining new types is always done by means of existing
types, in any language that allows type definitions.

[...]
typedef struct foo foo_t;

the typedef really doesn't create a new type. All it does is create a
new name for an existing type. "struct foo" and "foo_t" are not merely
two different types with the same characteristics; they are quite
literally the same type.

Sure, that's because in your example, the definition of the type foo_t
is as simple as it could be: just another type. In this case, you could
also call it an alias. But in the general case, typedef will accept any
complex type expression to define the new type, so I'd say there is
absolutely nothing wrong with the name "typedef".

Regards,
Felix

 

[Felix Palmen]

But then, it was Microsoft's awkward decision to use '\' as a path
separator with the rest of the world using '/'. It probably came back on
them the instant they built web functionality (browser, server) in their
OS.

[early MS-DOS]
The Unix convention probably wasn't as widespread then as it is
now, so using '\' wasn't an obviously absurd choice at the time.
(VMS, for example, uses '.' to separate directory names.)

Maybe it wasn't too obvious back then that interoperability could matter
some day. But, (we're talking about 1980...) Unix was already used a
lot. Only 5 years later, AmigaOS had the "standard" path separator (and
also, to some extent, the concept of mounting devices).

Regards,
Felix

 

[Keith Thompson]

* Jon <[email protected]>:
Think of a new programmer. Is he likely to understand that typedef means
alias in reality or likely to think that it means declaration of a new
type? Therefore, "Alias" is better.

And how is typedef NOT declaring a new type? (in fact, it should say
"defining"!) Defining new types is always done by means of existing
types, in any language that allows type definitions.

[...]
typedef struct foo foo_t;

the typedef really doesn't create a new type. All it does is create a
new name for an existing type. "struct foo" and "foo_t" are not merely
two different types with the same characteristics; they are quite
literally the same type.

Sure, that's because in your example, the definition of the type foo_t
is as simple as it could be: just another type. In this case, you could
also call it an alias. But in the general case, typedef will accept any
complex type expression to define the new type, so I'd say there is
absolutely nothing wrong with the name "typedef".

Regardless of how complex the type is, a typedef does nothing more that
create an alias for the existing type. The definition is *always* "just
another type".

 

[Jon]

You're making an awful lot of assumptions about other peoples'
intuition
here.

Hardly. Note that a poster further down thought that typdef created a new
type. I remember thinking that long ago too. I'm sure many C programmers
think that today.

 

[Jon]

A #define is particularly bad for new programmers

The issue is not a define, but rather that "typedef" is a poor choice of
keyword for what it does in the C language. "alias" would have been much
better.

 

[Ben Bacarisse]

The issue is not a define,

I thought you were suggesting one.

but rather that "typedef" is a poor choice of
keyword for what it does in the C language. "alias" would have been much
better.

I'd prefer a keyword that included "type" in it because alias is a very
general word, but I agree that there might be a better word. I don't
agree (given the C language we have) that the #define you posted makes
anything better.

 

[Jon]

I thought you were suggesting one.

Pfft. I know better than to "suggest" a change to the ISO C standard in
this ng.

I'd prefer a keyword that included "type" in it because alias is a very
general word, but I agree that there might be a better word.

In the modern times of "programmer creates types", *especially* anything
with 'type' in it is bad. Suggest something better than 'alias' then.
'imposter'? I like 'alias'.

I don't
agree (given the C language we have) that the #define you posted makes
anything better.

Did you say that "just right"?

 

[Jon]

Since I'd used the other language for many years (having invented it),

I though Dennis Ritchie invented C!

 

[Jon]

After re-reading this particular branch of this discussion I have to
say that not only my reading
comprehension skills failed me miserably but that also my replies were
inappropriate. My apologies.

Stop lying: you're a "shoot-from-the-hip gunslinger". I know what you're
thinking:

"Did he fire six shots or only five?" Well, to tell you the truth, in all
this excitement I kind of lost track myself. But being as this is C, the
most powerful programming language in the world, and would blow your
finger clean off, you've got to ask yourself one question: "Do I feel
lucky?" Well, do ya, punk?

 

[ClassCastException]

Please provide an example of valid C code where the escape character can
be confused with what you describe as "dos/windows paths".

I can't think of any that would confuse *the compiler* or complicate its
design.

There's one way in which the collision can bother *the C coder*, though:
the backslash has to be escaped in string literals, unlike the forward
slash, and paths are commonplace string literals, so on systems that use
the backslash the coder may be inconvenienced by the need to do much more
escaping than on systems that use the forward slash path separator.

 

[Jon]

The usual. Please get a life beyond the boundaries of your
cubicle and your narrow working environment. Not only will you
be happier for it, you may become less of a twit.

I'm trying to mark this thread as read because I *am* interested in some
posts. As I go thru all of the posts, in cursory inspection, I find your
above blather. Can you and your mate take it pvt please and stop the
noise in the room? Wait, are onlookers supposed to save you or us from
you or other? Just get to the point please. Else, feel free to STFU. If
you want to banter like old women, go or create the old woman banter
room. Everything is not all the time and this room has a topic (yet to be
defined (?),. but certainly it is not old women bantering).

 

[Jon]

I am at this time marking this thread as read. No offense intended.

 

[ClassCastException]

* Juha Nieminen <[email protected]> [comp.lang.c]:
It's a too-overloaded token: dos/windows paths,

Did you know that you can use '/' to separate paths in dos/windows
as well? (Well, at least with all compilers I know.)

The compiler doesn't matter here. Most windows api functions accept
'/' nowadays (but not all). You're better off using '\' for the
windows platform, because there are still cases '/' won't work.

But then, it was Microsoft's awkward decision to use '\' as a path
separator with the rest of the world using '/'. It probably came back
on them the instant they built web functionality (browser, server) in
their OS.

My understanding is that early versions of MS-DOS didn't support
directories (or maybe it was CP/M). By the time they decided to add
directories, they were already using '/' as an option delimiter (like
'-' in Unix).

Correct. MS-DOS 2.x introduced directories. Before that, MS-DOS, like
the other 8 bit OSen (FLEX, FLEX-09, CP/M, etc.), just had a flat list
of file names which was OK because few of its users could afford disks
big enough for the lack of directories to be a problem.

It's about to happen again. In the mid-80s we reached the scaling limits
of flat file lists and went to hierarchical directories. Now we're
approaching the scaling limits of hierarchical directories. I haven't
seen a modern system that doesn't have some ludicrously long full-path-
names of files, highly deeply nested directory structures, and human
trouble navigating the wilderness of files and keeping track of what
files are for what purpose. Applications come with numerous files; on
Windows systems they tend to be bundled with it in Program Files (with
some libraries being elsewhere, or else duplicated wastefully); on Unix
systems all kinds of config and other files get scattered to the four
winds, /usr, /etc, /bin, and ~/.appname. Documents might end up anywhere,
at least on Windows machines.

Another tension is between organizing by program and organizing by higher
level task. Say someone's throwing together a report and presentation.
The report is made in Word, the presentation in PowerPoint, both using
data from an Excel spreadsheet, and some of the graphs were copied,
pasted into Photoshop, prettied up, and then embedded as .png files. Oh,
and the whole thing is also HTMLized using FrontPage and posted to the
company LAN as well as the PP presentation presented at the Friday
afternoon general staff meeting and the printed report handed to the boss
afterward in the hall outside the conference room. And the guys that
couldn't attend the meeting in person phone-conferenced with those that
were while consulting the copy on the LAN's internal website.

So you've got Photoshopped pngs along with xls, doc, pp, and other files,
that logically are part of one project. The user wants to file them as
"2010 2nd quarter budget report" or whatever, under "2010 budget
reports", under "budget reports", ideally; the programs all would like to
keep track of their own files, docs with docs, xlses with xlses; and
Windows itself would dearly love it if you'd just shove the whole mess in
"My Documents" along with every single other file the user ever creates,
thus turning back the clock to 1982 and flat file lists again.

Unix users get nearly the analogous treatment with ~/ substituting for
"My Documents" and the gimp for Photoshop and other more or less
straightforward substitutions.

Add to that how every kind of browser, file sharing tool, or similar
client for downloadable content ends up with its own preferred
directories for storing received files, plus iTunes, plus various sync
folders for your phone and laptop, and so on, and so forth, and we're
rapidly heading straight back into file management hell.

What's our savior going to be? I'm beginning to suspect we're going to
soon see a wave of new file management tools, at first appearing as third-
party "knowledge manager" programs and eventually superseding Explorer-
style shells as those have superseded the old C:\ prompt. These will
provide their own nonhierarchical, link-based file management ability,
probably with the ability to easily convert any subnetwork of stuff into
web pages, or even acting as a web site itself; a locally-hosted web app
that can easily adapt to make some stuff publishable remotely. Hyperlinks
will creep into everything and become easy to create via drag and drop;
no copying and pasting (or worse, memorizing and typing) long filenames.

We already see hints of this with the big commercial websites. When was
the last time you saw a human-readable URL at a major news or corporate
site instead of something like http://site.example.com/html/content/
cms/1.45.907/08102010/58120156-18856-ac78f9d107bb8088.htm or similarly.
Occasionally you might see something like that but with a -report-on-iraq-
casualties just before the .htm, but dollars to doughnuts you can delete
that from the url or replace it with -report-on-stolen-doughnuts and it
will still fetch the same page.

Filenames and paths are becoming a layer increasingly managed by
automation instead of manually, now by big website CMSes and soon by
Windows 8 and Gnome 2015 I expect. The user will not type paths or even
drill down through folders, he will follow hyperlinks.

And when he needs to make a nonlocal jump he will use search. Faster,
more incremental, and better search than we have so far.

Vista already has raised the bar. I use some Vista machines and almost
never click Programs after Start, unlike when forced to use an older XP
box. Programs is slow, balky, unwieldy, and has shoddy ergonomics. It
worked at first and didn't scale, despite being hierarchical. Vista's
start menu has a nice fat incremental search box at the bottom just
begging for your input, and you can find something like Calculator much
faster by typing "calc" into it and then clicking one of the few
remaining items above than by clicking Programs, then Accessories, etc.
and waiting for each level of menu to unfold. Vista also makes it easy to
tag photographs and search by tag, just by typing e.g. tagbudget OR
finance) into an Explorer window's upper-right-corner search box.

Two things still scale poorly: the searches aren't especially fast,
particularly on large tagged photo libraries, and photo tagging is itself
one tag at a time one image at a time with poor support for copy, paste,
or mass tagging (it would be nice to be able to select a large group of
images and assign a tag to the lot with one command).

The knowledge managers can beat Explorer by providing their own facility
for associating any imported object with metadata, including metadata,
and using suitable lightweight local database software to make it fast to
search. This allows tagging images that aren't JPEG or TIFF (so don't
have EXIF metadata) and tagging non-images, as well as doing so in a
uniform manner. (EXIF tags and other document-format-supported metadata,
like mp3 ID3 tags, could be imported when a file is first seen by the
system.) Metatagging is most important, of course, for nonverbal data
such as audio, still pictures, and video. (Advanced tools could
potentially attempt voice recognition on audio and OCR on stills and
video to extract what verbal content is in there, but fuzzy-matching
would have to be used for this to be searchable I expect, and even then
an unlabeled photo of an apple would not be found by searching for
"apple" without solving some hard problems in AI and machine vision.)

So your documents become much more searchable and you can link them into
a web of interrelatedness. Something like this almost HAS to replace
Explorer-style shells in the very near future, I'm thinking, if only
because of the stupendous explosion of user-generated audiovisual content
that has to be searchable and the general scaling problems happening with
users' documents nowadays.

As for what any of this has to do with the original topic: very little. I
guess that's Usenet for you. On the other hand all of this will have to
be implemented in some language, and it's a sure bet that it's gonna wind
up involving C code, C++ code, and/or code that runs on the JVM.